The AEC industry has spent 30 years trying to fix construction. Better software. Better processes. Better contracts. Better procurement. And somehow, project performance keeps declining while costs keep rising.

That should make us wonder: what if we’ve been solving the wrong problems?

Solutions in search of a problem

Here’s a pattern that repeats itself constantly in this industry. Someone identifies a pain point (too many RFIs, coordination conflicts in the field, slow drawing production) and builds a solution for it. The solution gets sold to hundreds of firms. The industry congratulates itself on innovation.

Meanwhile, the projects keep running over budget. The owners keep absorbing cost growth they didn’t plan for. The gap between what was promised and what was delivered keeps staying right about where it always was.

The pain points being solved are real. But they’re symptoms, not causes. Treating symptoms can reduce discomfort without addressing what’s actually wrong.

Architects, contractors, and owners see completely different projects

A point that deserves more direct acknowledgment: everyone on a project is having a fundamentally different experience.

The architect is managing a design process, a creative and technical endeavor with its own internal logic.

The contractor is managing a production problem: labor, materials, sequencing, subcontractors.

The owner is trying to deliver a business outcome. A hospital wants to open on time to serve patients. A developer wants to open a building to generate returns. A manufacturer wants a facility to produce products.

These three perspectives rarely get fully reconciled. Each discipline has built its tools and workflows to optimize for its own experience. The integrating layer, the one that would ensure all three are actually working toward the same outcomes, mostly doesn’t exist.

The root cause hiding in plain sight

When you talk to enough owners about why their projects struggled, a pattern emerges. It’s rarely “the contractor made mistakes” or “the architect designed the wrong thing.” It’s almost always some version of: “We didn’t know what we didn’t know early enough.”

Scope wasn’t clear at the start. The owner didn’t have the information or the tools to understand what they were buying before committing to a budget. Design proceeded on assumptions that didn’t match reality. By the time the mismatch surfaced, there was no leverage left.

The problem isn’t execution. It’s inception. Projects get set up to fail before the first drawing is produced.

Fix inception and you fix a remarkable proportion of downstream problems. But inception is where the fewest tools exist and the least attention gets paid, because it’s less visible than fieldwork and less measurable than drawing production.

A different question

The useful question isn’t “how do we make the current process more efficient?” It’s “why does the process produce the outcomes it produces, and what would have to be different for it to produce better ones?”

That question tends to surface answers the industry would prefer to avoid. It surfaces the information asymmetries that let projects drift out of scope. It reveals the contract structures that create perverse incentives. It exposes the fact that owners often don’t have the knowledge to challenge what they’re being sold.

Those aren’t problems that any single piece of software solves. They’re problems that require rethinking what the industry is actually trying to optimize for.

Right now, the answer is: efficiency within the existing process. The harder answer, the one that leads to actually better outcomes, is clarity before commitment. Owners knowing what they’re building before they’re locked in.

That’s the problem worth solving.