Every party on a construction project has gotten better at its own job over the last decade. The builder’s schedule is tighter. The architect’s document control is cleaner. The Owner’s cost reporting is sharper. Nearly every firm on a project has adopted technology that made its own operation more efficient.
And yet projects still run late, still go over budget and still produce friction between parties who are each running a better shop than they were ten years ago. That gap tells us something about what all that technology actually did. It solved for the silo. It did not solve for the seam between silos, which is where most project outcomes are won or lost.
Design-build is the one delivery method built around that seam. That is why I think technology behaves differently on a design-build project, and why the efficiency it produces there is the kind a team can actually keep.
The Efficiency You Can’t Keep
Here is a pattern I have watched play out across the industry. A firm adopts a tool that cuts a week off its estimating cycle or automates half its submittal review. For a while, that firm wins work on the savings. Then a competitor adopts the same tool, the price floor resets and the gain dissolves into the new baseline. The efficiency was real. It just flowed to the market rather than to the firm or the project.
Under a hard-bid model, this is the whole story. Each party captures its own gains, and each party’s gains get competed away. The Owner ends up with a lower number and the same coordination problems.
Design-build changes what happens to the gain. When the designer and builder share one contract and one outcome, a week saved in the design office is not a margin play for one firm. It is a week the builder can use to lock in procurement, test a constructability question or pull a long-lead item forward. The savings stay inside the project because the contract already points everyone at the same finish line.
What I Saw When the Tools Were Pointed at the Wrong Seam
Earlier this month, I spent a day at Stanford’s Center for Integrated Facility Engineering sitting through deep-dive demos from eight construction technology companies. The tools were impressive. Nearly all of them were built for one party, usually the general contractor, and most were focused on preconstruction plan review: what changed between drawing sets, what conflicts exist, how to generate an RFI faster.
When I asked how a tool helped when the Owner’s actual problem was on the table, the answers thinned out. The software could tell you what changed. It struggled to tell you what that change meant to the schedule, the budget or the trade partner who had already ordered material. And almost none of it was designed to be used by the designer and the builder at the same time looking at the same question.
That is a fine set of tools for a delivery method where the designer and builder meet at bid day. It is a poor fit for design-build, where the whole point is that they never have to meet at bid day because they have been in the room together since the pursuit.
Where the Tools Should Point in Design-Build
A few months back I watched a superintendent with thirty years in the field enter the same daily information four times: the log, the scheduler, the RFI platform and a text to the project manager because he knew the PM would not check the other three. He did not build that process. He lives in it. That is the cost of technology built for one party’s system of record.
On a design-build team, the more useful question is not “how do we fill out our forms faster?” but “how do we shorten the loop between a design decision and its field consequence?” Some practical places to start:
- Shared models with phasing, not static handoffs. One civil firm I have followed took the design data it was already producing and put it on a map-style viewer with a time slider, so the Owner and field staff could step through construction sequencing phase by phase rather than flip through fifteen PDF sheets. In a design-build setting, that same view lets the builder pressure-test the sequence while the design is still moving.
- Decision traceability across both halves of the team. When a design change is made, the builder should see the downstream cost and schedule effect before the change is issued, not after the sub has procured. AI is getting good at reading drawings and specs; the design-build opportunity is to point it at the impact question rather than the “what changed” question.
- Choose tools like you choose a trade partner. Most firms should not be building AI. They should get sharp about selecting two or three tools that solve real problems on real jobs, pilot them together as a designer-build team and hold them accountable to project outcomes rather than to one firm’s internal metrics.
The Outcome the Owner is Buying
The Owner is not purchasing the sum of everyone’s individual efficiency. The Owner is purchasing a building delivered as promised, without the surprises that come from parties working past each other rather than with each other.
Two decades of technology adoption made every party stronger on its own. The next gain available to this industry is at the connective layer between them. Design-build already puts the right people in the room with the right incentives. The teams that win from here will be the ones that point their technology at that room instead of back at their own walls.
KP Reddy, Founder, Zero RFI
KP Reddy is the founder of Zero RFI, launched in March 2026 with a $13.8M seed round led by General Catalyst to transform the Owner’s representative model using AI. A second-generation civil engineer with 25+ years as a founder, operator and investor across AEC, AI, robotics and automation, KP has founded and exited three companies and leads Shadow Ventures, a VC firm focused on the built environment. Where others see a $10 trillion industry with 60 years of declining productivity, KP sees the greatest technology opportunity of our generation, and he’s building it.
