Design-build is the direction a lot of Indian studios drift toward without ever quite deciding to, right, you start as a design practice, a client asks "can you also just execute it", the margin looks good, you say yes, and two years later you're running designers, site engineers, your own carpenters and a vendor network, and the systems that ran a design studio are visibly cracking under a construction business. This piece is about managing that hybrid animal properly, what actually changes when you take on execution, what you must document, and how to keep drawings, site and money joined up instead of living in three different worlds.
What actually changes when you add "build" to "design"
The romantic answer is "you control quality end to end". The operational answer is that you've added three businesses to your one business. You're now a procurement company (buying at scale, managing vendors, carrying delivery risk), a labour contractor (site teams, daily productivity, safety), and a working-capital business (you pay vendors and labour before the client's next milestone lands). Design margins are fee margins, build margins are execution margins minus every leak on site, and the leaks are legion.
The deeper shift is where risk sits. A design-only practice hands a drawing over and execution risk belongs to someone else. In design-build, every gap between the drawing and the site is yours, there's no contractor to blame, which is exactly the trade-off clients pay you for. So the management question becomes: how do you make the drawing-to-site-to-money pipeline so tight that the risk you've absorbed stays priced-in rather than surprise-shaped? I've compared the two underlying disciplines in interior vs architecture project management, and design-build is what happens when both sets of problems move into one office.
The three joins that make or break the firm
Join one: drawings to site. The site must always build from the current drawing, and site reality must flow back to the drawing team fast. That means construction drawings living in a system with pins, a site engineer flags a clash by pinning it on the drawing with a photo, the design team resolves it, the revision is what site sees next morning. The version-drift disaster (site building from an outdated print) is fatal in design-build because the rework cost is entirely yours.
Join two: approvals to procurement. The client approved a spec at a rate, the PO must go out against exactly that approval, the vendor bill must reconcile against exactly that PO. In design-build volumes this chain runs hundreds of times per project, and each unreconciled link is your margin, not a contractor's.
Join three: site progress to money. Milestone billing must track actual site progress, and your outflows (vendor payments, labour) must be visible against project budgets in real time, because design-build cash flow is a river with big inflows and continuous outflows, and firms drown in the timing gap, profitable on paper, gasping in the bank.
| Join | Failure mode | The record that prevents it |
|---|---|---|
| Drawings to site | Building from stale versions | One live drawing set with pinned issues |
| Approvals to procurement | Rate drift, unchecked vendor bills | Spec → PO → bill reconciliation chain |
| Progress to money | Cash-flow whiplash, invisible overruns | Milestone billing + live budget vs actuals |
The documentation load, honestly
Design-build documentation is heavier than either parent discipline, and pretending otherwise is how firms get hurt. You need the design records (versions, approvals, revisions), the construction records (site updates, snags, measurements, handover), and the commercial records (quotes, POs, vendor bills, payment approvals, GST invoices) all cross-referenced. I've written the full inventory in project documentation every studio should keep, and for design-build I'd underline one addition: the payment-approval trail. When your own team raises vendor payments, an approval workflow (site requests, principal approves, accounts pays, ledger records) is the difference between control and leakage, because in design-build the person spending and the person accountable are inside the same firm, and informality gets expensive.
Why the toolstack matters more here than anywhere
A design-only studio can survive on stitched tools, painfully, because the volumes are modest. Design-build cannot, because every gap between tools is a join failing at volume. The drawing tool that doesn't know the snag list, the PO spreadsheet that doesn't know the approved spec, the invoice tool that doesn't know site progress, each gap is a full-time coordination job you're paying someone to do badly. This is the strongest version of the argument I make in why one connected system beats five disconnected tools: in design-build, connection isn't convenience, it's the control system.
Concretely, in Designa the whole pipeline runs joined: room-by-room specs with live costs, client approvals in a branded portal (unlimited free client logins), construction drawings with pins, site updates and snag tracking, purchase requests through PO to delivery with bill reconciliation, payment approvals, milestone billing that turns approved quotes into compliant GST invoices with Razorpay collection, budget versus actuals per project, and an org-wide transactions ledger with Tally and Zoho Books sync. One flat founding price for the whole studio, billed in rupees, which matters when your team spans designers and site engineers, because per-seat pricing punishes exactly the headcount design-build needs.
That last bar deserves a sentence: in design-build, client-requested variations get absorbed informally at a shocking rate, the site just does it, nobody raises the variation, the firm eats it. A recorded approval flow turns variations back into billable scope.
Structure and standards
Two organisational notes from firms that do this well. First, separate the commercial gate from the site gate: whoever approves POs and payments should not be the person under daily site pressure, that separation alone catches most over-billing. Second, borrow the professions' own discipline: the Council of Architecture tradition of staged, documented services and the practice standards bodies like the Institute of Indian Interior Designers promote are exactly the skeleton a design-build firm needs, formalised stages, written approvals, certified progress, applied at interior design decision density. If you're choosing the system to run this on, work through how to choose studio software: a buyer's guide for India with design-build eyes, and the architecture-side comparison in project management software for architecture firms in India fills in the long-arc requirements.
The design-build control checklist
- One live drawing set, site issues pinned with photos, no stale prints
- Every PO raised against a client-approved spec, every bill reconciled against its PO
- Payment approvals separated from site pressure, all outflows in one ledger
- Variations recorded and billed through the approval flow, never absorbed informally
- Budget versus actuals reviewed weekly per project, not discovered at close
Frequently asked questions
What makes managing a design-build firm harder than a design studio?
You absorb execution risk: procurement at scale, site labour and working-capital timing all become yours, and every gap between drawings, site and money is your margin rather than a contractor's problem.
What should a design-build firm document?
All three trails: design (versions, approvals), construction (site updates, snags, handover) and commercial (specs to POs to bills, payment approvals, GST invoices), cross-referenced in one system.
How do design-build firms lose margin most often?
Procurement rate drift and unchecked vendor bills, rework from drawing-version drift, idle labour from delivery slips, and client variations absorbed informally without being billed.
Can Designa run both the design and build sides?
Yes, specs, portal approvals, drawings with pins, snags, procurement with PO reconciliation, payment approvals, GST invoicing with Razorpay, and live budget versus actuals, in one connected workspace at one flat rupee price for the whole team.
The bottom line
Design-build is a wonderful business run on tight joins and a dangerous one run on WhatsApp. Join the drawings to the site, the approvals to the purchasing, and the progress to the money, in one system with one ledger, and the risk you absorbed becomes the margin you were promised. See the joined-up pipeline at demo.designa.work, and the founding offer is at go.designa.work.