Why $13 Trillion in Construction Still Runs on 1997 Software — And Why Better Software Alone Won't Fix It

a16z and KP Reddy both wrote important pieces this week about the future of construction technology. Both are right about critical things. And both stop short of the most important conclusion.

The Conversation

Two important pieces about construction technology landed this week that I believe merit engaging with seriously.

a16z published "Every Building You've Ever Been In Was Designed By Software Built in 1997". It's a sharp analysis of the $13 trillion AEC industry and the opportunity for AI to disrupt it. Within hours, KP Reddy responded with "We Already Ran This Experiment", which is an equally sharp rebuttal drawing on his industry experience and 15 years of BIM adoption data to argue that better software alone doesn't produce better project outcomes.

Both are worth reading. Both are right about important things. And both stop short of the most important conclusion.

Let me explain.

What a16z Gets Right

a16z's research is solid. The industry runs on tools from the late 1990s. 85% of projects exceed their budgets. The average construction dispute in North America is worth $60 million. AI creates genuinely new capability to automate rule-based work, parse building metadata, and address the talent shortage. All accurate.

Their strongest insight is near the end: the real opportunity isn't traditional per-seat software pricing, it's outcome-based pricing tied to measurable outcomes.

That insight is correct. It's also where the thesis starts to unravel.

What KP Reddy Gets Right

KP Reddy explains why.

He walked the BIM adoption wave from the beginning. He wrote the first practitioner book on BIM for building owners in 2012. His case study is the most important evidence a16z didn't include: billions invested in BIM. Firm-level coordination improved measurably. And the numbers for project-level waste barely moved. He notes that the 85% budget overrun rate a16z cites today was circulating in the same form in 2010.

KP's diagnosis is precise: every party in the delivery chain is economically structured to optimize for their own position, not for project outcomes. The architect's fee is fixed at schematic design. The GC's margin comes from managing change orders, not eliminating them. The MEP consultant bills hours. Speed and accuracy work against their invoice, not for it.

Better software gave each firm a better tool for doing exactly that.

This is the most important pattern in construction technology. Four waves, CAD, BIM, Cloud PM, and now AI, each produced firm-level efficiency gains that got competed away in lower fees, not retained as project outcome improvement.

KP is right that the mechanism is the accountability structure, not the toolset.

The Missing Protagonist

But here's where both pieces stop short.

a16z identifies three ways to attack the market: replace Revit, build around Revit, go after the services budget. All three are excellent firm-side plays. And that's the problem. They're all firm-side. The entire thesis is structured around optimizing workflows for the companies doing the design and construction.

The owner appears exactly once in the essay: as the party who "funds the project and sets the brief."

Think about that. The owner is the entity who controls 100% of construction spend. The owner occupies and operates the asset for up to 40 years or more. Who pays for the energy, maintenance, and capital improvements. Who bears the full lifecycle cost of every design decision. Who absorbs the litigation when systems fail. Who funded the project and had to live with an outcome that fell short of their vision and operator intent.

And yet the entire tech investment thesis is structured around AEC firms.

This is not a new oversight. It's the reason every technology wave in this industry has produced the same result: firm-level efficiency gains that don't translate to better project outcomes.

KP understands and names this problem but stops at "owner education and contracting." He doesn't describe what the solution actually looks like — what platform, what process, what enforcement mechanism gives owners the information parity and outcome accountability he correctly identifies as necessary.

It's Not a Technology Problem

I've spent my entire career studying the problem and the last eight years building the answer to that question.

It's not a technology problem. It's a data stewardship problem and an owner capability problem.

Every owner has a goal of achieving intelligent operations. However, every intelligent operations initiative — digital twins, predictive maintenance, augmented analytics — requires data that was captured, contextualized, harmonized, and governed during the capital program that generated it. Equipment specifications. Maintenance requirements. Operational scenarios. System integration dependencies. Training records. Trial and simulation results.

This data has a window. It's generated during the capital program. And that window closes at handover. If no one is stewarding it — capturing it as it's generated, enriching it with operational context, structuring it so it can flow into asset management systems, digital twins, and analytics platforms — then every downstream AI initiative starts with a data hunting and cleanup project instead of data utilization.

The Function No One Is Talking About

There is exactly one function in every infrastructure project that has continuous visibility across both the delivery lifecycle and the operating rhythm: the operational readiness, activation & transition team.

In aviation and transit, this function is called ORAT — the structured discipline of preparing an environment and its people to operate new infrastructure. ORAT teams are involved from the earliest project stages when requirements are being defined, so they understand design intent and more importantly operator intent. They're highly engaged and present during construction and commissioning, so they see what's actually built versus what was planned. They run integrated systems tests, trials and simulations, so they understand how systems perform in real operational scenarios. They manage familiarization and training, so they know what people need to know. And they orchestrate the transition to operations, so they understand the operational context that gives all of this data its meaning.

No other function touches all of these data-generating moments. Not the program manager. Not the contractor. Not the engineer. Not the IT department. Not the asset management team.

This isn't unique to aviation. In healthcare, it's activation and transition. In oil & gas, it's operational readiness assurance. In data centers and other industries, it's activation. Whatever the label, this function is the bridge between what was built and how it needs to work and be consumed. And it's the function uniquely positioned to serve as data steward — capturing, harmonizing, contextualizing, and governing operational data so it arrives AI-ready.

We call this Checkpoint 0: the discipline of ensuring capital program data is born AI-ready, contextualized, harmonized, governed, and connected to the operational systems that need it. It's the missing prerequisite that determines whether owners' capital project investments achieve maximum ROI and whether their intelligent operations investments succeed or fail.

And the discipline that executes Checkpoint 0 has a name.

Owner Scope Management

Owner Scope Management is the structured practice of orchestrating owner-specific scope and responsibilities required to successfully open and operate a new or remodeled capital asset — including stakeholder alignment; operational procedures; familiarization & training; systems integration testing; operational impact mitigation; operational trials & simulations; and transition governance — all while simultaneously stewarding the data that powers the owner's future.

It is not project management. Project management governs the contractor's scope: build it on time, on budget, to spec. Owner Scope Management governs the owner's scope: ensure the people, processes, information, and assets are ready to operate, that the project achieves operator intent, and that the data generated along the way is captured in a form that operations and their intelligent operations systems can actually use.

These are fundamentally different jobs. And until now, the owner's job hasn't had purpose-built technology.

The Owner Scope Management Category Blueprint: a Governance Layer (data harmonization, analytics, observability & control), an Execution Layer (capital asset planning & development, operations enablement, ecosystem operations network), an Integration Bus connecting to existing systems, and a Domain-Specific Agentic AI Intelligence Layer across the entire stack.

AI for the Owner Changes Everything

At Citiri, we've been building that technology for eight years.

We helped SFO deliver its $2.4 billion Terminal 1 program — including relocating 31 airlines with a problem-free opening. We helped Port of Seattle's North Satellite program return $30 million in contingency savings. And just last week, we helped Sound Transit operationalize the world's first light rail to cross a floating bridge. In fact, we've helped owners successfully operationalize more than $200 billion in critical infrastructure projects.

The method works. The evidence is there. And we've now deployed domain-specific agentic AI, purpose-built for owners and operational readiness. It gives owners 24/7 risk analysis, evidence generation, and decision-grade intelligence across every phase of the process.

This is AI deployed for the owner. Not for the architect. Not for the GC. Not for the MEP consultant. For the entity paying for and operating the asset.

And that changes everything about the historical pattern KP calls out. When AI operates on the owner's side, measuring what the owner needs measured and surfacing what delivery firms have no incentive to surface, the information asymmetry that defined every previous technology cycle breaks.

Outcome-Based Pricing Requires Execution Rules

a16z is right about the pricing model. Outcome-based pricing tied to results is the future. We offer it today.

But here's what they don't address: outcome-based pricing doesn't exist in a vacuum. It requires execution rules, structured to enforce consistent alignment between the owner and their delivery partners. Without those rules, the owner loses predictability and control of outcomes. The contract has to be part of the product.

KP is right about that too. He just doesn't describe what the execution structure looks like in practice. We've been operating it for eight years.

The Real Opportunity

The $100 billion-plus opportunity a16z describes is real. I agree with the scale. I agree with the urgency.

But it won't be captured by building better tools for firms whose incentives are misaligned with the owner's outcomes. It won't be captured by automating the production of drawings that still get coordinated too late because no one in the delivery chain has a financial reason to surface problems early.

It will be captured by giving owners the platform, the intelligence, and the execution structure they've never had. By making Owner Scope Management, and the data stewardship it enables, a first-class discipline in every owner's capital program.

The built world deserves infrastructure that opens on time, operates with confidence, and runs on trusted data.

That's what we build.

N. Ortez Gude is CEO of Citiri, the Owner Scope Management platform for operational readiness. Citiri has helped owners successfully operationalize more than $200 billion in critical infrastructure projects.