The level of shared context in our industry should be steadily increasing and we should carry these expectations with our industry partners.

A couple of specific notes on the key Meta products themselves:

• Muse Charm. In Analog, I wrote about my experience at Turner in having the responsibility of finding the person who knew the answer, extracting that knowledge, and getting it to someone who needed it. Wearables could move some of that capture closer to the moment the knowledge is being used. A superintendent explains why a sequence needs to change while looking at the work. Capturing that explanation alongside the field condition gives the next person considerably more to work with than a revised date in the schedule. This is the opportunity I see for companies like Hardline as wearables are a natural extension of their current offering. In providing the capability to capture the explanation alongside the event itself makes both more useful and contextually rich.

• Meta AI Glasses. The reality capture aspect of these are already well known in the space. What excites me about these today, compared to previous iterations, is the prospect of Muse embedded into the glasses. It’s surprising to me that these aren’t more widely adopted, given that construction already has an established place for this technology as every person on a construction site has to wear gloves, safety glasses and a hardhat. If done well, this wedge ought to be the first point of useful interaction between a field worker and industry software. This is a part of the mandate and opportunity of Ironsite.

• Connectors. Meta’s pitch to outside firms is straightforward and inviting, albeit slightly dangerous. They’re positioning the invite for you to bring your API while Muse brings the agent, the browser, and the person’s context. For construction, the implication extends beyond just connecting Procore to another platform. It’s clear that whoever controls the agent could increasingly determine where (and more importantly when) a field request goes, which software handles it, and who receives a given order.

  I have written before that headless software will define the next phase of software growth. Connectors make that direction tangible: a superintendent speaks into a device, and the agent moves information across the relevant systems without requiring someone to repeatedly enter it. The software still matters, but its interface becomes less central to getting work done. A platform could remain deeply embedded in a contractor’s business while losing influence over the future commercial activity. If the superintendent or PM asks an agent to resolve a shortage, that agent could check existing stock, surface suppliers, and sign a purchase order before the transaction is recorded in a PM or ERP system. The incumbent still holds the record, yes. But the commercial question is who gets to influence the decision that creates it and who owns the context of how the decision was made.

  • On a jobsite, I see three key applications.

    • Reporting. I remember as a project engineer sitting with superintendent’s to understand their problem, taking photos of field condition and tagging the photo to their respective positions within the drawing in Plangrid or Procore. An agent could prepare that package much faster than I ever could. Today, an agent could draft the RFI, attach the relevant footage, reference the drawing, and prepare it for review and submission in the PM software within seconds. The architect then receives a documented condition and a specific question (enhanced with the context of their existing relationship and previous experiences of working together). This won’t eliminate the time required to resolve the issue, but it’s clear how substantially compressed the work between identifying and surfacing will become.

    • Ordering. A carpenter who needs a box of Simpson hangers should be able to request it from a company phone or pick and pack device without navigating several catalogs or calling their foreman or superintendent first. An agent could check the internal warehouse first, then approved supply houses and retailers, matching the specified product and quantity to availability, pricing, the job’s cost code, and purchasing permissions based on role, project type, project requirements, etc. I see the opportunity to connect a need in the field directly to the process of fulfilling it. Suppliers that make their catalogs and inventory accessible to agents, as a data source, could become easier to buy from at the moment that need arises. There’s an entire ad platform to be created and built around this opportunity. An agent that knows what a project needs, when it needs it, and which products are preferred is an extremely valuable distribution channel for multiple parties. How this plays out and how paid placements interact with purchasing decisions deserves its own future article.

    • Directing. A little over a year ago, I wrote about the opportunity to create a shared context layer for construction robotics. Connectors could provide part of the infrastructure for that vision. Imagine an operator directing several autonomous or semi-autonomous devices through one agent: assigning a layout task, requesting a scan, and checking the progress of a drywall robot. Each device would expose its capabilities, context, and status through a common interface, with permissions governing what the agent could request. Safe execution and coordination would still require dedicated controls by the device provider, but the operator would have a common way to assign work and understand what happened. The shared context also has to explain what each machine accomplished, where it happened, and whether the result meets the requirements for the next activity. Otherwise, the operator still has to reconcile several incompatible versions of progress. That was central to my earlier argument: common access becomes much more valuable when the outputs can also be understood and verified.

• Where it all begins to get interesting in my opinion is when these capabilities are combined into single devices, much like we’ve seen in the defense space with EagleEye from Anduril. This a key part of my ideal future state in construction. A provider of safety rated headpieces that fuse sensing, communication, and an agent for one operator, built by a company that controls the agent platform behind the hardware, software, and data. The race is on to build both the capture device ecosystem and the requisite agent platform.

This finally brings me back to the idea of the modern construction trailer. A site deploying more wearables, local computing, and robotic equipment may need a different mix of connectivity, charging, maintenance space, and places for people to review exceptions together.

It also raises the stakes for purchasing and procurement departments. Selecting a device could mean selecting the agent platform through which field teams request materials, access software, and direct equipment. That decision would shape future purchasing behavior across the organization. Procurement will need to understand whose recommendations the platform prioritizes, what authority it receives, and whether the contractor can switch providers. The hardware purchase becomes the beginning of a much larger operating decision.

Inspired by a conversation with .

There’s a missing piece in the ambition and clarity of thought in calling it the differences between what’s broken today and needs to be fixed vs ideating what ought to be true tomorrow. 

This disconnect keeps showing itself downstream through minimal product innovation. Minimal risk taking. Minimal value creation. 

Clear vision is upstream of every iconic company in modern capitalism. 

So my advice is to stop trying to “fix” construction. Startup product roadmaps are continuously showing to be incremental because the future state is incremental in fixing. AI chatbots = fixing. Agent builder = fixing. Faster take-offs = fixing. 

Value capture will continue to remain constrained if your startup is limited to improving someone else’s business as opposed to also creating a new economic position for itself. 

For example, if the focus is centered in the idea that preconstruction is inefficient.

Then your product surface is naturally bounded by the existing definition of preconstruction. You improve estimating. Automate takeoffs. Build an AI chatbot. Add agents. Improve procurement workflows. Integrate more systems.

Compare to a new vision for precon: A building should be able to move from design intent to a verified physical outcome with progressively less human coordination.

Now you have to solve very different problems: verification, robotics, insurance, financing, contracting, responsibility, machine-readable design intent, autonomous procurement, physical execution.

The vision creates the problems worth solving.

That’s how your product surface area organically grows unbounded!

The important idea is that the problem statement and subsequent vision determine the boundary of the company.

What Moved Through

A contractor aggregates its subcontractors' pay applications, submits them to the owner, and keeps two to three points as that money crosses its balance sheet. A billion in contract volume is not a billion of anything the firm owns. So the ranking measures how much money moved through, not how much was actually even captured, or earned.

To illustrate this point, look at a few of the top firms on the rankings list. There’s an interesting mix of firms founded before the Depression sitting at the same revenue line as firms founded inside the last two generations. DPR (1990, roughly $10B 2026), Clayco (1984, ~$9B 2026), Suffolk (1982, ~$7.5B 2026), Hunter Roberts (2005, ~$3B 2026). The attributes that should enable a large, century-old firm stay large such as accumulated brand, capital, a trained permanent workforce, a client base with real switching cost, take decades to build and are not supposed to be cheap to rent. And yet, we have examples of this with DPR through advanced manufacturing fabs and data centers, Suffolk through healthcare and lab spaces, and Clayco on industrial and distribution, and data centers. Each of them grew by standing next to a client who was growing faster.

Contractor top line growth is rented growth.

During COVID, there was a massive boom in e-commerce and distribution warehouses. Many construction firms benefitted from this, including design-build firms like ARCO Construction Company. From 2019 - 2024, ARCO grew from ~$700M to roughly $6.5B in revenue. A 9x increase in scale. We’ve also seen their revenue + ranking decrease to roughly $4.7B in revenue in 2026 (reported and ENR confirmed). ARCO didn’t become a worse builder but it’s clear the clients they were building for stopped growing.

Subscribe now

The Fee Is the Loss Leader

In “The Scoreboard Is Lying” I argued that reported numbers hide the real state of construction businesses. Pass-through volume measures throughput, and throughput is set by the sector you’re attached to and the clients you serve, not by anything you own, and so nothing durable remains.

The scoreboard isn’t lying so much as it is unpriced.

In “The Fee Trap,” I showed how the market misjudges Turner's roughly $29B by over-assuming their generated fees and undervalues SourceBlue, xPL Offsite, and First Equipment Company as entities that earn revenue independent of the CM fee. Turner learned this lesson decades ago and we’re now seeing the dividends pay out. They’ve clearly internalized that the CM fee is the loss leader, and the ancillary services stack is the business. A firm charging zero CM with a full ancillary stack out-earns a GC firm charging 2.5% with none. This stacking of ancillary services to generate durable revenue is what leads to Turner being so valuable. Therefore, if you're building comps on construction companies, top line is the wrong input. Enterprise value tracks EBITDA dollars, and the CM fee produces almost none of them. Two and a half points on a billion, before G&A, is not a business a buyer pays a multiple for. It's a toll booth. Turner's $29B does not create Turner's value. SourceBlue, xPL Offsite, and First Equipment do. Those lines carry margin that survives the fee compression we’re seeing in the industry.

You can’t build durable enterprise value on a shrinking two points of other people’s money, even when you increase top line revenue. The only profit that lifts EV sits in ancillary lines that earn outside the fee.

What Renews

It’s important to note however, that not all ancillary revenue is equal. In “The Floor or The Ceiling”, we discussed how the floor get competed to commodity margin while the ceiling’s unbounded because they own a scarce input, the outcome. “The Captive Arbitrage” is an example I provided demonstrating GCs with captive insurance programs can turn risk the GC already carry into a durable, high-margin line revenue business. In another piece, “MEP Services Opportunity”, I shared another example for MEP equipment purchasing.

A test for evaluating ancillary business lines therefore becomes a question of does the capability add additional value more durably than a rival can rent growth? Especially as balance sheet is a proxy for durability, not the thing itself.

What Do You Own

The most common answer to “what do you own” is self-perform capabilities. Crews, equipment, capacity. Kiewit’s fleet alone is roughly $5.6B, but the labor to manage and utilize those fleets is fungible. Labor re-prices to the market in every cycle and is increasingly leaving for the highest bidder.

Hunter Roberts exists because a team and a set of relationships walked out of Turner on a Friday and started a competitor on Monday.

Large GCs are not only competing against themselves but also against their own trade partners. In the “Rise of the Super Subs”, I demonstrated how the same fungibility runs upstream. Limbach’s field crews became a durable business by moving into design and serving the lifecycle of equipment, not by relying on just providing labor. The labor was never the asset; what the labor enabled was the asset.

The Record Is the Asset

What self-perform actually produces that lasts is its data. Production rates by condition, real cost-to-install, the sequencing logic that priced the last several thousand installs. The crews are the instrument that generates it. The record of the task is increasingly becoming worth more than the task itself. The site work between two contractors excavating and grading is fungible. The structured history of ten million cubic yards is not. The honest objection is that construction data doesn't transfer. Every project is a one-off. That objection is correct at the project level and wrong at the portfolio level. The valuable piece of this work is the recording of the relationship between conditions and outcomes.

I believe one of the key indicators showing us to where the industry is heading is most recently evidenced by the partnership between Bedrock Robotics and Clayco and their partnership with Sundt. Bedrock Robotics has raised $350M to retrofit heavy site equipment that contractors already own. Contractors are responsible for winning the work, supplying the projects, owning and maintaining their fleet, and supplying labor while Bedrock is providing the mechanism to monetize the outputs of these efforts. And keeps the data to train their vision models. Task-execution data is becoming more value than the task completion itself.

The Record or the Ranking

The case for renting growth is stronger than it sounds. Riding a capex curve requires almost no invested capital, which means the return on what little goes in is enormous. DPR’s partners have done extremely well attaching to fabs and data centers without owning a fab or a data center. A firm that grew volume through the last decade distributed real money to real people. Renting isn’t a mistake.

So, two paths:

Path A keeps stacking volume. You hold your place on the ranking, you accept flat enterprise value, and you carry a rented position that gets priced to the downside the day macro shifts or a sale forces the real number. Cheap now but margin is exposed later.

Path B instruments execution. You convert throughput into an owned record, you accept slower top line and real systems cost, but you keep revenue defensible after a rival reaches the same volume. Expensive now but durable, because your ranking doesn’t walk out on a Friday.

They are mechanisms for coordinating people who possess it.

Folks in the industry love to reference their “secret sauce” when they describe a great GC. Then the same people will tell you, without noticing the contradiction, that their staff are fungible and their labor is elastic. If your people truly are interchangeable, then where exactly does the secret sauce live? Both statements are true. The highest-value knowledge still lives with individuals, even though fragments of it are scattered throughout the organization.

Contractors resemble guilds. A collection of individuals who each carry irreplaceable judgment, loosely federated under a corporate name that captures the margin but not the knowledge. The value is driven by the labor, and the labor is portable. The knowledge gained by a project manager’s thirty years doesn’t belong to the firm. It belongs to the project manager, who can take them to the competitor across town for a 20% raise and a company truck.

The firm is a coordination mechanism wearing a company costume.

This is the game on the field today for organizations. It’s a race to convert portable human judgment into durable organizational capital.

That race is being accelerated by two things. The first is AI, which for the first time makes the extraction technically plausible. You can capture the bid a PM chose to walk away from and the sub he refused to award despite the low number, and hold those in a form the organization owns rather than one that lives in his head. The second is the labor crisis. The workforce that holds the knowledge is aging out faster than it's being replaced. The enterprise extracts judgment from labor because the alternative is watching itself decay against its peers.

Consider the contradiction when describing labor + experience being fungible and yet irreplaceable as judgment at the same time. It’s a bit of forced cognitive dissonance. But consider this. If the project manager were irreplaceable as labor, you couldn’t build the org without him and you couldn’t ever capture what he knows. Because the organization can replace his role, the project continues towards substantial completion whenever the star PM leaves for another firm. Because his judgement is valuable, the org is desperate to capture what he knew before he leaves. The whole extraction race is in the gap between those two ideas.

I’ve written before about why the project manager’s judgment resists being modeled. Thousands of delayed feedback loops, attribution mistakes, supplier failures, weather events, owner conversations, and budget tradeoffs collapsed into intuition. He is, in effect, a walking dataset that took years and a few hundred million dollars of other client projects to refine. His salary was the annual rental fee to access that knowledge and expertise.

But here is the trap. Recording the decision is nearly solved. Grading it, knowing months or years on whether it was the right call once everything else is stripped away, is not. And the outcomes that would grade it are the exact thing that refined him in the first place. A firm can capture every decision he made and still not own the attribution mechanism that made those decisions correct.

So the strategic question every construction executive is facing is simple: where does their knowledge live and who controls the transfer.

From here, there are two possible outcomes.

The advantages go to the enterprise, if the firm builds the mechanism to capture judgment as it happens, encode it into systems the organization owns, and preserve decades of judgment before retirement. That organization compounds knowledge. The guild slowly becomes a company.

Or advantage stays with the individual, if the firm keeps treating knowledge as an HR/training problem and a retention bonus. That firm forever stays a guild. It will function. It will be awarded work, and yet it will not endure.

Historically, construction firms rented expertise. AI makes it possible to own it.

I don’t entirely agree.

The standard story is that construction knowledge is too deep, too tacit, too situational for a model to ever catch. The typical argument is that thirty years of a superintendent’s judgment can’t be compressed into weights. I think that story confuses a symptom for a cause. The knowledge isn’t captured because it’s deep. It’s uncaptured because the industry can’t produce the one thing a model needs to learn it: a clean signal that connects a decision to its consequence.

Start with what accuracy is worth. If your value to a customer is “I produce a more accurate takeoff,” then the day a better takeoff product exists, your customer’s switching cost is close to zero, and they have no incentive to stay on your platform. Those customers were never truly yours to begin with. They were renting accuracy, and accuracy is a commodity. If you believe that renting accuracy is a fine business until accuracy is free, then the only thing left to sell is the thing accuracy was standing in for, which is knowing what to do with the accuracy once you have it. That knowledge isn’t in the takeoff accuracy. It’s embedded in the person reading it.

I’ve argued before that most AI ROI in construction rarely shows up because providers sell the idea of an outcome instead of the artifact of that same outcome, and that frontier models have quietly abstracted away the skill that used to justify a provider’s margin. Both of those are symptoms.

So the real question isn’t whether scale beats encoded human knowledge. It’s when. At what point does raw data scale stop losing to the superintendent and start beating him? It appears the industry is assuming the answer is to capture a larger volume of data. Gather enough project history, financial, scheduling, etc. and the assumption is that that context + a model wins. However, I believe that’s the wrong axis.

From Richard Sutton’s, The Bitter Lesson, we learn of the observation that general methods trained on more data and more compute keep beating hand-crafted human knowledge. It assumes an environment capable of generating learnable feedback and attribution.

Read more

The appearance of capability is the cheapest thing AI now produces. When the AI can read every document on a project, it feels like the AI understands the project. When the AI can generate a quote response, it feels like the AI knows how to quote. That feeling is seductive, but it’s pulling an entire cohort of solution providers into a strategic error: they’re skipping from tools to outcomes without earning the right to make that leap based on the assumption that feeling of knowing is the same as understanding.

The model can ingest every document in a GC’s project. It still doesn’t understand that this particular superintendent ignores RFIs until the third follow-up. There’s contextual knowledge that is operational, relational, accumulated. No model has it. No model will have it. It has to be built through the actual work of solving problems alongside customers. Coverage isn’t comprehension. Reading every RFI, tracing it upstream to a submittal and downstream to a potential change order is not the same as knowing the unwritten rule. As humans, we understand this because we’ve personally experienced it in the field but we make the mistake of assuming the AI understands when it only knows.

The right to deliver outcomes is earned through the transfer of context from customer to provider. You earn it one of two ways. First-party experience: you’ve done the work yourself and can extrapolate that experience into software. Or observation: you capture insights alongside the customer and leverage them to deliver specific business outcomes. Claiming the ability to deliver outcomes without the earned context erodes trust, because it signals to the customer that the provider doesn’t understand what it doesn’t know.

This was always the arrangement. Customers owned the context; solution providers built better tooling so customers could solve their own problems. Through that work, providers learned to hold context, first intuitively, then natively inside their software. The desired outcome was never theirs to own, because the responsibility and the context stayed with the customer. What’s changed is that frontier model capabilities have abstracted away the requisite skill to deliver business results through better tooling, and providers are reading that abstraction as permission to migrate to the outcome layer. They’re still missing the core function of being in business: solving customer problems.

The failure mode isn’t just inability to deliver value. It’s inability to capture whatever value does get delivered. When you haven’t earned the context, you can’t price the outcome. You can’t defend the margin. You can’t retain the customer. Because the customer correctly perceives that your contribution is thin: you’re passing model capability through to them with a markup, and they’re not buying. The value capture problem is downstream of the context earning problem.

• using the “best” model is a weird statement

  • cost vs. capability vs. speed vs. accuracy vs. precision

• Gemini claimed major compute efficiency gains with a mixture of experts (MoE) as a highlighted architecture change.

  • If we really want to move the industry forward then not only is there an opportunity to create an industry approach to an approachable harness.

  • an expert is a (system prompt + tool set + retrieval source + verification rule).

  • it’s simply not feasible for any one of us to train our own MoE model, as that requires tens of millions of dollars, a large research team and wouldn’t give us an edge. however, what we can provide is information around context, routing, and verification based our knowledge.

  • think of this as instead of throwing every possible question into claude or chatgpt, you would first have a classifier based on your own context (internal + industry standards). and then you’d route to the appropriate expert (lead times, submittals, s-curve forecasting, etc.).

  • all of this is conditional to the question, what is your harness actually serving? if you can list five to eight things that people keep asking the system to do, then those are your experts.

• pretraining data is based on scraped internet data, and increasingly more offline data (rare books, etc.)

  • not only is there a decrease in novel information, there’s an increase of ai-generated content. the explosion and diffusion of ai-generated content will as dirty data in future pre-training runs. and so it’s important to figure out how to filter ai-generated content from non. specifically with a filter of “does this content carry information that is correct and that the model doesn’t already have.” you also have to hold in your head that it’s possible to have human-written content to be garbage while of synthetic content can also be excellent. plenty of frontier capability now comes from deliberately generated synthetic data: verified math and code solutions, distilled reasoning traces, textbook-style explanations. that synthetic data is good precisely because it’s filtered through a verifier, not because of who or what wrote it.

  • then, you’d have to run rigorous verification through your bench of industry experts based on each classifier.

Read more

An earlier version of this piece argued that gross revenue retention was likely being masked by price increases and that Procore wasn’t leading with it because it was weak. That was not entirely correct. Procore reported GRR at 95% directly in their earnings highlights. I misreported.

Having said that, the correct read is actually more pointed than what I wrote and the broader argument stands. The specific inference and conclusion it was meant to support, that the core is saturated and not growing, is supported more directly by the number itself.

Procore recently had their earnings call and it’s clear that they’re shoring up their defensive posture, and the [new] CFO’s recent positioning on the latest earnings call toward FCF per share further indicates that they’re transitioning to focusing on generating cash rather than product + revenue expansion. That’s roughly a 4-8x multiple business, which at roughly $1.5B in rev explains their ~$7B market cap. The pivot makes sense after the elevation of Tooey to chairman, but it also signals as a small white flag wave to the broader construction tech market, and to a lesser degree to Wall Street. Companies that are still figuring out how big they can become don’t pivot to optimizing FCF per share, they build the next product. Procore has stopped doing the second thing.

Post-earnings call, the wall street read is largely priced in. What’s interesting is that the construction tech market already intuitively knew this, even if wall street didn’t figure it out until now. The street is now recalibrating expectations around growth, with the expectation of Procore no longer solely chasing compounding logo growth, and are now pricing the multiple accordingly. That part is the less interesting half of the story. Again, the more interesting half is what this signals to everyone else in construction tech, the founders, the corp dev teams at Trimble, Autodesk, and Oracle. The signal to them is that the adjacencies of procurement, payments, equipment, insurance, prefab, are still very much wide open greenfield product territory, and that if you build there, Procore isn’t planning on coming for you as they’re focused on locking down the core. But the moment you touch their core business, they get very defensive. That’s a meaningful distinction for anyone deciding where to point a roadmap or a corp dev budget over the next three to five years.

The signal cuts the other way too, against Procore’s own core competitors. Trimble, Autodesk, and Oracle now have a green light to take the position of aggressive price reduction to capture Procore’s market share, and they’ll be able to do it for far longer than expected because they all have other meaningful business revenues that let them run construction project management as a loss leader. Procore doesn’t have that luxury. Even more so, the historical funding mechanism for project management software, the CM/GC fee passed through the GMP as a tech line item, is itself under pressure as GCs continue to compress fees and shift their economics toward ancillaries. So the funding source for Procore’s core revenue is shrinking at the same moment the competitive set is willing to price into it. That’s a hard place to defend from, hence the more defensive posturing.

One of the key questions for Procore is why a category leader with $1.5B in revenue, deep penetration across the ENR 400, and one of the largest, (presumably) cleanest datasets in construction has decided that the right move is to optimize the existing book rather than build the next product. To me, it reads as a capped ceiling.

The Ceiling Signal

Procore reported NRR of 95% on the call, and on the surface that’s a healthy number for a category-defining software business at their scale. The problem is what’s underneath it. NRR at this stage of maturity for a saturated install base is almost always being held up by price, not by genuine expansion, and the metric I actually want to see is GRR. The gap between the two tells you whether the base is growing organically or whether contractual price increases are masking churn at the edges. Procore doesn’t break it out cleanly. If GRR were strong on its own, they’d be leading with it. They’re not, which leads me to believe that NRR at 95% is not the profile of a company unlocking major new expansion vectors.

Juicing NRR via price increases is lazy, and it has a ceiling of its own. In this market, Procore faces two simultaneous pressures that make the price-increase strategy structurally hard to sustain. The first is the value justification problem. To continue raising prices on customers who are already at the top of the band, the kind of customers who are paying $X00K+ per year and represent the bulk of the ARR, Procore needs to deliver 5x more value per customer to justify the increase, and they’re forced to do it without meaningfully expanding the product surface area. Module expansion is not product expansion. Adding safety, financials, or quality on top of project management is selling more of the same thing to the same buyer out of the same budget line and funding source. It’s intra-account upsell dressed as net new product, and the sophisticated buyer sees through it eventually.

The second pressure is the competitive one, which I briefly touched on. Hilti, Trimble, Oracle, and Autodesk will decrease pricing to take market share, and they’ll do it for longer than the construction market expects because they can absorb the loss, given their existing other businesses. Construction project management is one line on a much larger P&L for both of them. For Procore it is the P&L.

Then there’s the saturation question. Procore has already captured the meaningful share of the ENR 400 install base that was ever going to buy this category of software. The TAM math at the top of the market is largely played out which implies the remaining greenfield in their core ICP are owners, the mid-market and the long tail, both of which have lower willingness to pay, higher churn, longer sales cycles relative to ACV, and structurally weaker unit economics. So the path to growing ARR within the existing product set is either price increases on a saturated base, which has a ceiling, or downmarket logo acquisition, which has worse economics. Neither of those is a growth story and yet both are management strategies, hence the focus on NRR at 95%.

This context also helps to explain the Datagrid acquisition. It’s a smart play toward an agentic future, and I don’t want to undersell it on the merits, the team is sharp and the product direction is right. But it’s a fundamentally defensive play. The strategic purpose is to provide additional AI-driven value to the existing install base so that the same customers who are absorbing price increases also have a harder time leaving, because the AI layer is now stitched into their workflow on top of the core project management product. That reduces churn but it doesn’t open a new market. It doesn’t create a new buyer and it doesn’t produce a new revenue line that compounds independently. It compounds defensively.

So when you look at NRR, GRR, ENR 400 saturation, the price-increase ceiling, the loss leader pressure from Trimble, Hilti, Oracle, Autodesk, and the defensive posture of the Datagrid acquisition together, it becomes increasingly clear that Procore is positioning and posturing themselves to Wall Street as a cash generation machine. In the short term, that aligns with where the business actually is. In the medium term, they face increasing pressure from competitors for their core revenue, and the Datagrid acquisition is the defensive answer. In the long term, I’m bearish, because they have not shown a demonstrated ability to build in adjacent product verticals, and the adjacencies are where the value capture in this industry is actually moving. What’s more interesting to me than any of the financial framing is the underlying question of why. Why is it that a company with this much data, this much capital, this much opportunity, and this much category position has not been able to organically perform in insurance, fintech, procurement, or any of the adjacent verticals they’ve tried?

The CM Fee Is the CAC

To understand why Procore is stuck, you have to first understand what business their customers are actually in. And the answer to that question is not what most software people, most investors, and apparently most of industry’s corp dev teams think it is.

Read more

Re-reading this, the question I should have asked more directly: why aren’t the top 50 GCs running their own capital desks? The answer I’ve come to accept is that the people who would have to build that capability don't have the pattern recognition for it, and the boards don't have the appetite to hire people who do. Building that capability requires admitting you're in the capital allocation business, not the construction business. Most boards aren't ready for that conversation.

Contractors need to look beyond their four walls and pay attention to the macro trends shaping the verticals they build for. Other industries do, but construction doesn’t. Two factors drive this blind spot. First, contractors are traditionally risk-averse, a posture reinforced by contracting types and their attendant dynamics. Second, by operating as a commodity business, they compete primarily on price. This combination has forced the industry into a tough spot. Changing industry contract types is a bridge too far. The next option is to creatively work around commodity business dynamics. I offer macro focus as the method.

Consider data center builders. Contractors ought to pay closer attention to the trends dictating which buildings are being built, where, how, and why.

Take Meta’s recent shift to using structural, air-tight tents to get compute online faster for model training. Contractors will build whatever the client wants and is willing to pay for, but they don’t understand why Meta would make this change.

That blind spot is the difference between being a service provider and being a strategic partner. The lack of knowledge leaves a contractor flatfooted in both upstream and downstream decisions that could actually differentiate their business, enabling them to stop competing as a commodity and consequently increase their profit margins.

To continue on this, more contractors ought to be building more pre-pricing capabilities. What do I mean by that? It’s not about guessing but rather about reading signals before they’re priced in the market. Every capital market has a divide between pre-pricing operators and post-pricing operators. The first group moves before conditions are priced in; the second reacts once the world has already adjusted.

Conviction vs. Flow.

Construction operates as the latter, but needs to build more pre-pricing muscles and treat macro intelligence as a key input to operations. What does pre-pricing muscle look like in practice? It means treating project data as market intelligence. When three separate data center campuses delay or accelerate work in the same quarter, that’s not three isolated situations but rather it’s a signal about something dynamic that needs to be investigated such as supplier constraints, changing data center architecture, or capital constraints. When RFIs spike on mechanical systems based on poor submittals, that’s advance warning of OEM and rep constraints. Construction firms already generate this data. They just generally don’t aggregate it, pattern-match it, or act on it before the broader market does. By increasing their decision making capabilities around leading indicators, direct and indirect, they can make more informed post-pricing decisions before their competitors do.

Many high-velocity industries already do this. Finance calls it forward guidance. Energy calls it capacity signaling. In construction, it looks like preemptive alignment of supply chains, speculative design partnerships, and financial engineering based on probabilistic outcomes.

Once a contractor builds this visibility, the nature of their business changes. They’re positioned to no longer behave like a service provider and start behaving like an allocator of scarce building capability.

As a corollary - in the early twentieth century, railroads were operational marvels but strategically blind. They built track wherever demand appeared, reacting to local booms (and subsequent busts). The firms that survived and thrived were the ones that learned to integrate ancillary products like finance and logistics. James J. Hill’s Great Northern Railway is the classic case of manufacturing demand. By creating economic functions that relied on his track to succeed, he was able to succeed when many other railroads went bust during the same period.

Contractors have the opportunity to do the same.

Manufacturing demand today might mean forging behind-the-meter power partnerships to help data centers bypass interconnect queues, or leveraging data to secure scarce OEM equipment before competitors can. It could mean steering capital formations in P3 arrangements. Activities all geared towards shaping the conditions that make clients need your services. But the highest expression of this strategy isn’t just adjacent construction services, it’s in becoming a capital partner to these firms.

It goes without saying, but I’m not writing this to be rude or disparaging of contractors but rather to offer a creative strategic playbook to become more profitable.

So what could this look like for a contractor to manufacture demand?

Take Meta, which is shifting from building data centers entirely off its balance sheet to selectively using debt structures. They’re doing this partially out of necessity to assuage Wall Street but mostly for capital efficiency. If the hyperscalers themselves are now open to third-party capital intermediation, why couldn’t Turner, Clayco, Suffolk or DPR step into the role of capital originator as a sponsor and not just a builder?

There is nothing stopping a top data center contractor from arranging project financing directly by packaging construction execution with capital certainty as a coupon attached to construction and conditioned upon completion, and then refinancing that asset post-C.O. into larger infrastructure funds, sovereigns, or hedge funds hungry for data center exposure and risk adjusted yield. Specifically, they could stand up an SPV, arrange senior debt, and back the loan with guaranteed completion covenants (derived from previous buildout data). So now then, a contractor can earn an origination fee (~1%), a completion incentive via the coupon (.75%), refinancing arbitrage (dependent on rates but assume ~3%), all while still earning their traditional 2.5% GMP margin + any other additional services. Macro intelligence only becomes leverage when it is expressed through capital. Financial engineering isn’t a separate function in this paradigm, it is simply macro translated into construction and the mechanics are straightforward once you see them.

This is what manufacturing demand through macro intelligence looks like.

it’s clear that turner at the time had some of the best and brightest but also had some of the most wide-ranging commercial work in the industry that the sheer breadth of knowledge was overwhelming. so much so that they created the knowledge management program in the mid-2010’s. i was hired into that group at the end of 2018 and served in that department until march 2020 before leaving to join upstart and create a knowledge management function there. during my time within the knowledge and learning group, we had a wide mandate of extracting and sharing the company’s knowledge throughout the enterprise. One of the ways we did that was through internal resumes and profiles. every employee had a semi-private resume that listed all of the projects they’d worked on during their time there and also their skills/expertise for those projects and overall career. we then paired that with an ask an expert service through a portal that i was responsible for managing. specifically, my job was to field questions as they came in and ideally answer them on my own, through my turner network (this is how i met so many leaders and people across the organization in such a short amount of time) across the enterprise. for those instances where i couldn’t easily answer/provide a response, i would then cross-reference our rolodex of internal relevant knowledge, reach out those listed individuals, and then either a.) retrieve the information myself and relay it back to the requestor, or b.) connect the two parties together and follow up with them separately to capture context for future work. a classic example of this is when someone was doing some work at the cincinnati zoo and wanted to learn about a super niche animal exhibit requirement from another pm/superintendent that had just completed some work at the san diego zoo. our team was responsible for this and many other knowledge and context sharing initiatives and was but one way that turner was able to rely on the expanse of the organization to better position itself against others.

however, given the work that llms have done over the past few years, it’s no surprise that that function no longer exists within turner. however, those experiences surprisingly do provide a great analog framework for how llms in construction work. i recently wrote about how/why chatgpt doesnt work that well with construction drawings. it’s almost a trope at this point in the industry to keep arguing this point but it’s necessary to perhaps explain a bit more. generally, when people upload a bunch of drawings/documents to claude/gpt/gemini/etc. they expect to get back an answer in one-shot. this almost never works and so they declare that claude in construction doesnt work. but you have to go a couple layers deeper and explore why this doesnt work. there are obviously many potential failure modes such as pre or post-training knowledge gaps, retrieval and augmentation, context windows, tabular and spatial reasoning, etc. some of these can and will be addressed by the foundational model providers, however, there still exists a gap in construction context to fully solve this issue. i suspect the most construction contextually important challenges to overcome are retrieval/ingestion, and pre & post training gaps. going back to my experience at turner. given the scale of the organization, it was a fair assumption that there was someone within the company that had existing knowledge and experience for any given submitted query and that it was our job to go retrieve that knowledge by searching for relevant context, knowing who held that knowledge in their head, extracting it and then presenting it back to the requestor. over time, i had to capture those lessons learned and use it to seed an early chatbot we created for the staff in the company. this process took anywhere from hours to weeks, depending on the nature of the request. super high-level, but is functionally how an llm works with multiple steps required to be successful in order achieve a positive, successful result from gpt. the reason i say that pre & post training gaps paired with retrieval/ingestion are the two biggest challenges is because i’ve lived the analog version and it’s hard to unsee it. it’s true that these llms are trained on the internet’s data, which is vast, but the construction industry was barely online until the last 10-15 years, and even assuming things were online, how much of that is good data (comprehensive, accurate, available, not behind a paywall, etc.). for the sake of this conversation, let’s assume the model providers were able to scrape the necessary context needed to include construction knowledge in the training run (pre-training) there still exists a gap in post-training whereby construction specific experts have by and large been ignored in grading the trained model to provide accurate responses on construction specific semantics and context for our industry, so it defaults to generalized, plausible outputs - i.e., failure. which is highly ironic given they’re all super constrained by construction as the bottleneck to access additional compute for training and inference.

this is also why leaders in the space rely on experience/years in industry as a proxy for knowledge, it takes years to start pattern matching.

nevertheless, let’s now assume anthropic/openai now have access to construction data and construction experts to train and grade these models before release, there’s still an incredibly hard underlying retrieval/ingestion problem to overcome. the reason this is so hard to solve is because you need to be able to strip away all of the unnecessary information about construction/the prompt in order to return the correct answer. a challenge which actually gets worse, not better, as context windows increase and people stuff more documents into a single prompt. when this happens, the model loses information in the middle of the context, which is a well-documented failure mode. and even when you sidestep that by using vector retrieval instead of stuffing context, the retrieval problem itself gets harder as the document corpus grows. an example of this dynamic playing out is when you have a construction project. before the project begins, you have to learn about the job. you have to learn about the client, what they care about, contract requirements, site conditions, the schedule, the drawings, the budget, the cost ledger, the critical path, o&m requirements, inspections, submittals, rfis, change orders, etc. it’s a lot of context for a team to know, but it’s the expectation. now, when the job starts and changes start happening, someone has to not only hold in their head what original versions of all of these things but also their respective changes, and not only that, but also how those changes are interconnected and also their downstream effects. because it’s too much to keep in your head, what people start doing is stripping away the non-relevant context of the project based on their role, function, experience, stage of the project, etc. then they figure out what are the top items to keep track of that could make the project successful or derail the project. that same process that the construction team is doing, is the same thing llms do through a process called chunking and embedding/vectorization. chunking is when information is broken down into smaller pieces and through embedding is assigned a numerical representation of that information while some systems also apply the clustering of those numbers to related concepts. whereas, retrieval is the process of finding previously assigned related information, ranking its relevance and then presenting that information back to users.

through these processes, you can start to more easily map the analog knowledge management experience i had at turner to understand my beliefs on where, why, and how llms are failing in the construction industry.

again, it’s true that some of these challenges could be solved by the foundational model companies including more construction data into their model development pipelines, but hope is not a strategy. it’s also clear that the foundational model providers won’t fix these issues because the construction industry isn’t their market. which is why you have companies in this space creating their “own models” to solve this problem. they’re not creating a new foundational model, they’re creating frameworks and ways of working to solve our industry specific challenges. given that, it also becomes clear that chatbots were never going to be the ai application to make construction data more useful. it’s a marginal improvement to the existing paradigm. in a future piece, i’ll share more of my thinking around what separates real scaffolding and useful frameworks to unlock ai as a use case in our industry from the noise in the space and how i evaluate those companies/efforts. that piece will require a paid subscription.

In 1204, the Crusaders sacked Constantinople, the city they were supposed to be defending. The allies did more structural damage than the original enemy. The Venetians negotiated themselves into the empire’s commercial arteries on preferential terms, extracting wealth while the host weakened.

The Ottoman Empire grew in the vacuum the Crusades created. Mehmed II captured Constantinople in 1453, but his real move was economic: he turned the Bosphorus into a toll booth before the siege even started. Then he built a governance system that lasted 400 years because it solved for coordination, not conversion.

Three patterns sit inside this history.

• Allies with misaligned incentives hollow out incumbents faster than external enemies.

• Whoever controls the chokepoint captures the economics of the network.

• The systems that last coordinate without demanding conversion.

I test these against what I see in construction and they hold up better than they should. GC margins haven’t moved despite a decade of technology adoption. The vendors who showed up to help ended up owning the data layer. Specialty contractors are filling territory that GCs vacated. I connect this to a couple of pieces I’ve written before.

Blog

I love history and geography and often look to those disciplines to find lessons that I can apply to the construction industry. I especially love studying defining moments in time with significant downstream implications.

In 1095, the Byzantine Emperor asked Rome for a few thousand mercenaries to push back the Seljuk Turks. He got 60,000 armed Crusaders with their own agenda instead. The mismatch between what was requested and what showed up, repeated itself across four Crusades over two centuries. But ironically, the event that changed everything was the Fourth Crusade in 1204, when the Crusaders sacked Constantinople itself.

The supposed protectors looted the city they were supposed to defend.

I’m convinced there’s a lesson in this in today’s landscape on the relationship between who builds, who sells the tools, and who funds the work. History has seen the pattern before. Let me show you where.

The Allies

The Crusaders contracted with Venice to build a fleet, couldn’t pay for it, and ended up in debt to the Venetian Doge, Enrico Dandolo, one of the most ruthless commercial operators of his century. Dandolo redirected the entire Crusade toward Constantinople, a city Venice had been trying to subordinate commercially for decades. because of misaligned incentives between the Crusaders and the financiers. The indebted Crusaders begrudgingly obliged. They stormed the city, looted it, and installed a puppet state that accomplished nothing.

When the Byzantines retook their capital in 1261, they took back a shell and the trade concessions Venice and Genoa extracted during the chaos meant Constantinople could no longer control its own commercial veins. The supposed allies had negotiated themselves into the empire’s markets on preferential terms.

Extracting wealth while the host weakened.

Construction technology arrived in the 2010s with a premise that sounded like help. Digitize the general contractor’s workflow. Reduce inefficiency. Improve margins. The pitch was the Crusader logic: we’re here to strengthen your position. Let us in.

What we’ve seen happen since was instead fragmentation. GCs adopted point solutions for project management, estimating, scheduling, document control, BIM coordination, RFIs, submittals, safety, quality, and field reporting. Each tool created its own data silo. Each vendor forcibly extracted concessions: multi-year contracts, proprietary data formats, integration fees. And the end result has been that the software companies ended up holding the structured data in their platform while the GC held the login credentials.

Venice didn’t conquer Byzantine territory. It negotiated preferential access to Byzantine markets, the flow of funds. Similarly, the first generation of construction software didn’t conquer GCs either. They negotiated preferential access to GC data and workflows and held them hostage and ransomed over 3 year contracts. The GC still holds the project. But the commercial arteries, the structured information about how work gets priced, sequenced, and coordinated, run through someone else’s infrastructure.

The industry knows and accepts that GC profit margins in commercial construction have averaged 2 to 5 percent for decades. Technology was supposed to move that number upwards and yet, it hasn’t. Not really. The efficiency gains accrued to the software vendors in the form of recurring revenue and, in some cases, to owners in the form of better project visibility. The GC absorbed the cost of implementation, the friction of fragmentation, and the risk of lock-in.

I don’t believe anyone had nefarious intentions and nobody planned this outcome.

The software companies didn’t set out to weaken general contractors any more than the Crusaders set out to sack Constantinople. But commercial incentives are directional. However, when the vendor’s revenue model depends on owning the workflow, and the GC’s value depends on controlling the workflow, the tension resolves in favor of whoever holds the data.

The crusaders who showed up to “help” ended up owning the commercial layer while the nominal sovereign lost control of the underlying infrastructure. That sentence describes Venice in 1204. It also describes the construction technology market in 2026.

The Vacuum

The Ottoman Empire grew in the specific vacuum the Fourth Crusade created. The dynasty established principality in the borderlands where Byzantine authority had collapsed, and within 150 years his successors controlled most of southeast Europe and were closing in on Constantinople from every direction. The lesson to be learned in this story is to not deliberately attack directly but rather to start on the fringes and then advance inwards.

In the case of the Crusaders, the allies did more structural damage than the original enemy did.

And so then, the question I keep asking is: who is brushing up on their history lessons right now in construction?

Large owners are building internal preconstruction and procurement capabilities. Last winter, I wrote a piece titled, “Rise of the Super Subs” that explored how specialty contractors are consolidating and moving up the value chain in firms like Limbach, Comfort Systems, etc. to fill the space that GCs are unable to service. And as technology companies that started as tools for GCs are repositioning as platforms that connect owners directly to trades we’re seeing each of these moves occupy territory the general contractor used to hold by default.

I’ve seen a top contractor lose a $50M project last year not to another GC, but to an owner who decided to self-perform the management scope. The owner’s logic was direct: if the GC’s value is coordination, and I already own the coordination tools, what am I paying 4% fee for?

That’s the vacuum question. When the incumbent’s structural advantage erodes, the surrounding players don’t wait. They fill the space. The Ottomans didn’t need to be exceptional. They needed the map to be empty.

The question is whether the GC community recognizes this as a pattern or treats each instance as an isolated loss. I don’t see it as isolated. The Byzantines didn’t lose Constantinople in 1453. They lost it in 1204, when they let the wrong allies inside the walls. The 250 years in between were the vacuum forming and that’s where we are today.

The Chokepoint

Later, in 1453, Mehmed II took Constantinople at age 21. Before the siege, he built a fortress on the European shore of the Bosphorus, directly across from an existing Ottoman fort on the Asian side. Together, the two forts turned the strait effectively into a toll booth. Any ship moving between the Black Sea and the Mediterranean faced cannons from both banks which allowed Mehmed to capture the economic function of the city before he captured the city itself.

To be clear, Mehmed didn’t care about Constantinople’s prestige or its theological debates. He cared about the strait. Twenty miles of water where everything had to pass through.

Every industry has a Bosphorus strait. The question is whether you can see it.

In construction, the chokepoint isn’t any single workflow or software category. It’s the structured data layer that sits underneath all of them. The information that connects design intent to product selection to pricing to logistics to installation. That information exists, but it’s scattered across PDFs, emails, phone calls, and the tribal knowledge of people who are retiring. None of it is structured. None of it is connected. And every major decision on a commercial construction project flows through it.

If you could structure that layer, the connective tissue between what gets specified, what gets priced, and what gets built, who pays for what - you wouldn’t control a software category. You’d control the strait. The place where information has to pass through regardless of who’s building, who’s supplying, or who’s financing.

That’s a different kind of position than selling a tool. It’s the difference between building a fortress on the Bosphorus and building a nicer ship. This is what Turner has figured out and the strategy they’re executing on. And we see this through their portfolio of offerings. A few other GCs are starting to see see this now, which is why so many offer self-perform, CCIPs, prefabrication, equipment procurement, etc. They’re being creative in how they’re filling the vacuum.

The Millet Question

Now back to the history lesson.

After the conquest, Mehmed did something that interests me even more than the siege itself. He built the millet system: a governance structure where Greek and Armenian Christians, Muslim Turks, and Jewish communities each retained internal self-governance while the Ottoman state controlled the infrastructure, the standards, and the economic layer underneath. The system lasted 400 years until it’s collapse in World War 1. It’s clear that the system worked because it asked people to operate within a framework, not to become something they weren’t.

Most construction technology runs the opposite playbook. A lot of folks say “we’re here to help, now do it our way.” They want you to adopt their workflows, enter your data in their format and integrate on their terms. The implicit demand is conversion: become a technology company, or at least act like one within our platform.

The millet model says something different. Keep your identity and keep your processes. The system doesn’t require you to change what you are. It requires you to operate within a framework that connects you to everyone else.

GCs don’t have to become tech companies. Subcontractors don’t need workflows forced on them by someone who has never pulled a permit. OEMs don’t need to abandon their rep networks by going direct to contractors.

The question is whether the connective layer gets built by someone who understands that coordination beats conversion and build that’s layer.

I’m constantly running that question against every piece of construction technology I evaluate, and the results are consistent. The tools that generate the most resistance are the ones making conversion demands. The tools that gain traction are the ones that meet each party where they already are and structure the connections between them.

Mehmed understood this at 21. Construction technology still hasn’t figured it out.

What I’m Carrying Forward

Three patterns from 900 years of history, and all three are playing out right now in an industry that doesn’t read enough history.

Allies with misaligned incentives hollow out an incumbent faster than any external enemy.

And what we’ve seen is that the industry’s technology partners have done exactly this.

The lesson to be learned is that whoever identifies and controls the chokepoint captures the economics of the entire network. The structured data layer underneath construction is that chokepoint. The systems that are going to last are the ones that coordinate without demanding conversion. The millet model scales. The Crusader model generates resentment.

The next time someone shows up offering to help your business, ask yourself a question that the Byzantine Emperor should have asked in 1095: what do they actually want? And by the time they get it, will your walls still mean anything?

Read history. Then look around.

This is the structural constraint of our industry.

This creates a choice about what to sell. Most construction technology companies choose to sell activity. This choice has institutional support. Horizontal SaaS playbooks from consumer software suggest neutrality wins. Investors pattern-match to companies like Salesforce, not to niche vertical software. The decision looks safe because it worked elsewhere. But construction is not elsewhere.

In construction, you can sell activity or you can sell outcomes.

If you sell activity, you charge for usage. Per seat. Per project. The customer pays as work is happening and the software makes that work easier to coordinate, document, or track. The software does not need to change whether the customer wins or loses. It just needs to be present when the work occurs.

The software can serve everyone. General contractors can use it, specialty contractors can use it, and owners can use it. No one is excluded by the software’s implicit assumptions about who should win or how margin should be distributed. The product is neutral but that’s actually not great.

Neutrality accelerates distribution so therefore uniformity and neutrality allows sales cycles to shorten as you are not asking anyone to make a structural bet on your business. You are asking them to coordinate better. Contractor objections are tactical, not strategic or structural. Adoption spreads horizontally across participants on a project and therefore revenue grows as long as construction activity on platform grows.

The business model is clean. Projects happen and the software gets used. You get paid because it doesn’t matter whether the contractor executing the project is profitable or not. The software is the infrastructure for activity and infrastructure gets paid simply for being there and charging a toll.

A durable floor. Revenue is predictable and churn is low because the software is embedded in how work gets done. The company grows with industry activity. Investors can model revenue with confidence and founders can minimize existential risk. The company becomes a utility.

The solution can’t command outcome-based pricing because success is not tied to outcomes. You can’t charge more when your customer wins a more profitable bid when your value prop is allow contractors to “document what happened on the last ten bids.” You can’t charge based on margin improvement because the software is not designed to improve contractor margin. It is designed to make activity visible and record decisions.

Pricing scales linearly. More seats = more revenue. More projects = more revenue. The relationship between customer growth and your revenue is one-to-one at best. Often it is less than one-to-one because as customers scale they want to negotiate volume discounts.

The software unintuitively depends on fragmentation with many buyers making independent purchasing decisions. The business model reinforces this—many small transactions instead of portfolio-level negotiations.

Fragmentation of software purchasing is also ending. Contractors are increasingly consolidating software spend at the enterprise level. What used to be hundreds of independent purchasing decisions across project teams is now fewer, centralized portfolio-level negotiations. Innovation, IT, software departments and operations leadership are standardizing toolsets to reduce redundant spend and improve data consistency across organizations. This software procurement consolidation accelerates pricing pressure on activity-based platforms. Volume buyers demand volume discounts while switching costs remain low. We see this in Procore's pricing concessions to Autodesk Construction Cloud users as a demonstration of this dynamic. Neutral platforms must compete on price because they cannot compete on outcomes.

As the industry consolidates software spend, this business model inherently weakens over time. Consolidation of purchasing within contractors means fewer buyers. Fewer buyers means fewer independent purchasing decisions. Larger customers mean portfolio-level negotiations. Portfolio-level negotiations mean pricing pressure.

In this world, customers must ask: does this software give us a structural advantage over our competitors? Does this software improve our margins, reduce our risk, accelerate our cash, or give us better control over portfolio outcomes?

If the software serves everyone, it is infrastructure. Infrastructure does not create competitive advantage for users. Infrastructure becomes table stakes. For solution providers, table stakes infrastructure compress pricing advantages to cost. Software that documents activity makes work more visible but it doesn't change the financial outcomes of that work, which means it can't provide structural advantage in winning, pricing, or executing.

At this point, the software loses leverage. The customer still needs it because work needs to be documented. But the customer does not value it the way they value systems that change their competitive position. The software is a cost center, not a growth driver, which means increasingly cost pressures internal to customers and therefore strategic relevance diminishes for the solution provider.

The software structurally can’t participate in value capture because it’s designed to observe value, not create it. It cannot move closer to money or risk or control because it is neutral about who wins and who loses. Activity scales linearly. But when buyers consolidate their purchases, this model breaks. Optimizing for the floor forecloses the ceiling. The product decisions that maximize horizontal adoption, like neutrality, breadth, and activity metrics are the same optimizations that prevent outcome alignment. You fundamentally can’t serve everyone and make specific customers structurally better. You must choose between charging for activity or charging for outcomes. The business model that minimizes early risk maximizes late-stage exposure to a capped ceiling. Path A is capped.

To sell outcomes, you must tie your revenue to customer improvement. You can’t charge for usage. You charge for margin expansion, risk reduction, cash acceleration, or portfolio optimization. You do not get paid because work happened. You get paid because the work you delivered produced better financial results for the customer.

You can only sell to customers who can actually want to use your solution to become structurally better. This means customers who are scaling (or have ambitions to scale), who are sophisticated enough to care about financial outcomes at a portfolio level, who are willing to integrate deeply because the payoff is competitive advantage.

The addressable market is narrower. You are not serving all contractors. You are serving contractors who are trying to build durable advantages in a commodity business. Contractors that care whether their margin on the next hundred projects is three percent vs ten percent because that difference determines whether they can grow or whether they stagnate.

GTM becomes selective. You optimize for depth with specific customers who can actually use what you build. Early adoption is slower because you are asking the customer to change how they operate. You are asking them to embed the software in decisions that really matter for their enterprises via revenue or profitability. Pricing decisions. Staffing and overhead decisions. Risk assessment. Cash management. The software must work at a level where failure is costly and visible and therefore valuable to solve.

Product decisions have to become opinionated because you are trying to make specific customers better. The solution must care whether the customer wins or loses. It must surface information that changes decisions. It must be designed around financial outcomes for customers, not around activity metrics.

You do not charge per seat. You charge based on value delivered. This only works if the software actually delivers real value. If it does not improve margins, if it does not reduce risk, if it does not accelerate cash, there is no fallback. You do not get paid for usage. You do not get paid for breadth and you are at risk for being exposed.

If the thesis is wrong, if the software does not make customers structurally better, the company fails. There is no durable revenue from activity. There is no wide adoption to point to. You picked specific customers. You tied your success to their financial outcomes. If they do not improve, you do not grow.

But if the software works, the ceiling is unbounded.

As the customer scales, the software's impact compounds. The absolute value delivered grows non-linearly as small per-project improvements aggregate into enterprise-level advantages. The software becomes embedded in how the company operates at a structural level because the aggregated value becomes irreplaceable.

And at the scale of contractors doing hundreds of millions in revenue to billions in revenue, this level of dependency is structural. Switching costs become prohibitive. Customers cannot easily replace the software because the software is now part of how they think about risk, how they price work, how they staff, and how they manage cash across the portfolio.

Pricing power increases when value delivered increases faster than the customer’s increase in activity. You’ve earned the right to move closer to money and control. These are the only defensible positions in a commodity business.

There’s a future in which the industry consolidates, and in this world, this ceiling-focused business model strengthens. Contractors aren’t looking for software that everyone uses. They are looking for an edge that makes them durably and structurally advantaged against their competitors.

Competitive advantage commands pricing power. Pricing power creates enterprise value. This is why Procore's ceiling exists where it does. Procore built infrastructure for a fragmented industry. It scaled to $1.3B+ in revenue by being everywhere. But its valuation multiple compressed from 25x revenue to 8x revenue as the market recognized it could not participate in the value concentration happening through consolidation. Procore documents activity for its customers. It does not make them structurally better than their competitors. That is the ceiling.

Building for outcomes instead of activity means accepting that you will not serve everyone. It means accepting an incredible amount of early friction, narrower markets, slower adoption, and higher expectations. It means accepting total exposure and failure if the thesis is wrong.

It also means participating in real value creation and real value capture instead of observing it. Customer alignment determines go-to-market, pricing, product, who you serve, who you exclude, and whether you digitize or change the industry.

Companies that choose Path A in a consolidating market face a specific failure mode: they become cost centers with compressing margins and weakening strategic relevance. They watch their largest customers demand enterprise-level advantages they cannot provide. They negotiate pricing down while switching costs continue to decrease. They remain venture-backable based on their growth patterns but they do not produce venture returns.

Companies that choose Path B face a different failure mode: total exposure if the thesis is wrong. If the software does not make customers structurally better, there is no fallback revenue. No breadth and therefore no floor. This is how you become legible to capital.

The choice is between two types of risk. Obvious failure fast, or subtle deterioration.

Activity is a floor. Outcomes are a ceiling.

If you got value from this, the best way to support my work is to share it with one person who’d find it useful.

if you disagree or agree with my take, send me a message: https://www.linkedin.com/in/victor-muchiri/

Traditionally, extracting this data meant a human reading a PDF, interpreting the table, and manually entering it into a spreadsheet or quoting tool. That process is slow, error-prone, and impossible to scale across hundreds of projects.

BuildVision replaces that manual process with an automated extraction pipeline. Raw construction documents go in. Structured, queryable product records come out. This is how it works.

The Pipeline: End to End

BuildVision processes construction documents through six distinct stages. Each stage builds on the previous one, transforming unstructured PDFs into actionable product intelligence.

Figure 1: The BuildVision extraction pipeline, from raw documents to structured output

Why ChatGPT Does Not Solve This

The first question everyone asks: why not just upload the drawings to ChatGPT?

The answer is that construction documents break every assumption general-purpose LLMs make about input data.

A typical plan set is 200+ pages. It contains a mix of floor plans, equipment schedules, piping diagrams, and written specifications. The schedules themselves use non-standard formatting, abbreviated manufacturer names, and implied column relationships. A model number like PSAH0BW14U means nothing without a product database that knows Ferguson’s ProSelect’s naming conventions.

Frontier models can read a single schedule image reasonably well. But they cannot process an entire drawing set with cross-page context. They cannot distinguish a mechanical schedule from a plumbing riser diagram. They cannot resolve an extracted model number to a real product with dimensional specs and airflow data. They can’t produce structured records.

BuildVision is not a model. It is a construction-specific harness that orchestrates models within a purpose-built data pipeline.

Figure 2: Where general-purpose LLMs fall short vs. the BuildVision construction harness

Stage 1: Document Intake and Classification

When a set of construction documents is uploaded, BuildVision first classifies every page. The classification engine uses visual and textual signals to assign document tags, and a single page can carry multiple tags. A sheet might contain both a floor plan and an embedded equipment schedule.

The system identifies mechanical plans, mechanical schedules, plumbing plans, electrical plans, specifications, equipment details, and more. Pages tagged as mechanical schedules are routed to the extraction pipeline. Pages tagged as specifications are parsed separately for basis-of-design data. The rest are indexed for cross-reference.

This classification step is what allows BuildVision to process full drawing sets rather than individual pages. The pipeline knows what it is looking at before it tries to read it.

Figure 3: Document classification separates schedules, specs, and plans for targeted processing

Stage 2: Schedule Detection and Extraction

Once a page is classified as a mechanical schedule, BuildVision identifies the table boundaries, reads the column headers, and extracts every cell into structured JSON. The vision model handles the inconsistent formatting, varied fonts, and visual noise typical of construction document scans.

Below is a real grilles, registers, diffusers, and louvers (GRDL) schedule from a commercial HVAC project, followed by the structured data the pipeline produces.

Figure 4: GRDL schedule from a mechanical plan set

From this single image, the extraction pipeline produces the following structured output:

Figure 5: Structured extraction output from the GRDL schedule

The extraction pipeline reads the schedule image and produces structured JSON. Each cell maps to a typed field. Manufacturer and model number are parsed into separate objects rather than stored as a flat string, which is what allows downstream matching against the product database.

Figure 6: Structured JSON extraction output from the GRDL schedule

Notice the model inherits the description from D1 for D2 (both are supply registers), it parses compound fields like manufacturer and model into a single cell, and it captures the OBD remark as a separate attribute. These are not random, trivial parsing decisions. They require understanding how construction schedules are formatted, where data is implied rather than stated, and how to handle the inconsistencies that appear across different engineering firms.

Stage 3: Normalization and Product Matching

Raw extraction is necessary but not sufficient. The text “ProSelect PSAH0BW14U” is a string. It becomes useful only when it resolves to a known product with real attributes: a 14x6 steel supply register with an opposed blade damper from a specific product family, with known airflow characteristics and dimensional specs.

BuildVision’s product ontology layer, Atlas, performs this resolution. Atlas maintains a structured database of 1,800+ manufacturers, their product families, component taxonomies, and equipment attributes. When the extraction pipeline produces a manufacturer name and model number, Atlas parses the model number against known naming conventions, matches it to a product family, and populates the full attribute set.

Figure 7: Atlas resolves raw extraction text into structured product records with 38+ attributes

“Dayton 2RB71” maps to a gravity roof ventilator in Dayton’s catalog with specific airflow and dimensional specs. “ProSelect PSAH45W2020” resolves to a 20x20 steel return air grille. Each record carries not just the data visible on the schedule, but the full product context that makes the data usable for procurement.

What Structured Data Makes Possible

Once equipment data is structured and matched, the schedule that used to sit as a static image in a plan set becomes a live dataset.

An HVAC manufacturer can see which competitors are specified on a project and map those specs to equivalent products in their own lineup. A rep firm can auto-populate a bid leveling sheet. A distributor can generate a quote. A general contractor can compare specified equipment across projects and identify procurement patterns.

None of that is possible when the data lives as text on a drawing. All of it becomes possible when the data lives as structured records in a database.

The Gap Has Always Been Human Labor

The information on a mechanical schedule has always been valuable. The problem was never the data itself. The problem was the cost and time required to move it from a drawing into a system where someone could act on it.

That gap has always been filled by human labor: estimators retyping values into spreadsheets, outside sales cross-referencing specs against schedules, procurement teams manually building equipment lists from plan sets.

BuildVision’s extraction pipeline closes that gap. Raw construction documents go in. Structured product intelligence comes out. The data that was always there becomes data that is finally usable, even across projects and across the enterprise.

i’ll walk through my perspective across three time horizons as the conviction required at each one is different.

something i don’t think most people in this industry realize: all of the gains we’ve seen from AI to date have come from existing data centers. every model, every app you’ve vibecoded, every product experience, all of it was trained on infrastructure that was built years ago when most of the construction industry wasn’t really paying attention to data centers. the announcements and starts dominating backlog reports right now won’t produce a trained model for years. openAI’s stargate campus in abilene broke ground early 2025, they won’t train there until at least 2029. the michigan facility broke ground in february. play that forward and that’s beyond 2030 before it hosts a completed training run.

construction alone takes 18 to 36 months for a hyperscale facility, then commissioning, network config, etc., then the training run itself which for a frontier model takes months and each generation takes longer as models get bigger. the supply everyone is calling a bubble hasn’t even entered the production function yet. meanwhile the demand side is absolutely on fire. construction and manufacturing firms that can support mission critical are turning away work because it’s hard to justify taking the incremental school project at 2.5% fee for 12 months when you can have guaranteed work for three years at a higher absolute dollar revenue. electrical subs are booked 18+ months out. so even if every hyperscaler paused tomorrow, work under contract sustains elevated activity in this sector through 2028. the labor constraint is the limiting factor before the demand constraint. in the near term, 1 to 3 years, i don’t believe there is a bust.

before getting to the medium term though, some context. people throw around “data center” like it’s singular thing with exact characteristics. it’s not. there are generally two buckets: storage and compute. and then within compute you have training and inference. each of these have different demand drivers, different power profiles, and different risk, and so lumping them together is like calling every building with a loading dock a warehouse.

training facilities are the headline grabbers. massive campuses, thousands of GPUs in parallel for months. you can’t pause a training run because the grid dipped so facilities these need nameplate, baseload power with zero interruption, which in practice means co-located natural gas generation running behind the meter. hence why those projects are always co-announced with power generation.

inference facilities handle the actual use of trained models. the load is demand responsive, much like electricity does, it spikes during the day and drops at night, so these tolerate hybrid power: gas plus BESS, grid connected with peaker backup, renewables in the right geography. inference is also very latency sensitive so these typically sit closer to population centers.

storage is the least discussed and the most durable. every piece of digital content ever created has to live somewhere and storage demand isn’t conditional on AI scaling laws. it’s conditional on people or things using the internet.

the profile for storage varies wildly and the easiest way to explain it is your recycling habits. if you throw a bunch of boxes, cardboard, cans into the bin without breaking anything down, it takes up a lot of space. that’s warm storage. now imagine you break down the boxes before putting them in the bin. same bin, more capacity. that’s cool. your apartment complex gathering everyone’s recycling and compacting it before shipping it away, that’s cold. the recycling plant compressing everything further into bales, that’s frozen. you see this every time you pull up Instagram and someone’s recent post loads instantly but when you scroll back to 2014 it takes a couple seconds. that photo was created, sorted by tier, and stored in a facility optimized for exactly that retrieval pattern. given the explosion of digital content from current AI capabilities alone, we’re probably still UNDERinvesting in storage and inference datacenters.

the 4 to 6 year horizon is where it gets murky and where the framing above actually matters.

scaling laws are the idea/concept where model performance improves predictably as you increase compute. double the training compute, and you get a measurable improvement. if scaling laws keep holding, training demand is functionally unbounded and the boom times roll on. if scaling laws break, training demand will change very rapidly because labs won’t spend billions on clusters that produce marginal gains and so then training data center (mega campus) construction slows. but remember, that’s only one type of data center.

if we see the headline that scaling laws are breaking, there will be a massive overcorrection. capital markets will try to halt all data center construction even though training is just one bucket. the market won’t distinguish between training datacenters and inference datacenters, let alone storage. everything data center related will sell off. construction firms, power developers, equipment manufacturers. that overcorrection, for anyone who understands the taxonomy, is latent opportunity.

inference and storage don’t depend on scaling laws. they depend on adoption. and most of society hasn’t really seen AI diffuse through everything yet. it’ll follow a similar curve to the internet spreading through devices, geos, industries over a decade. as that happens, it dramatically increases the need for inference and storage facilities. remember the earlier point: the capabilities we see today are based on existing, prior data centers. the new facilities outside of training will provide so much more capacity for inference and storage that the demand from current AI capabilities alone already exceeds what’s being built. i’m confident in non-training DC spend over the next 4 to 6 years regardless of what happens with scaling laws.

now where all of this gets built matters because every data center thesis bottlenecks at energy. training needs baseload nameplate power, consistent megawatts 24/7 for months. natural gas is the default because it’s dispatchable, dense, and can sit behind the meter. inference works with a broader mix but heavy inference still needs a gas backbone. storage cares about cooling efficiency and density more than raw compute.

what most people outside the Midwest don’t realize is how much dormant infrastructure exists in places like Ohio, Michigan, Pennsylvania. these are states where heavy industrial loads, steel mills, auto plants, uranium enrichment facilities, once pulled enormous power from a grid sized to serve them. that industrial base contracted over decades but the grid and infrastructure didn’t. the substations, transmission corridors, gas pipelines, right of way easements, all still in the ground. two weeks ago, the DOE announced a partnership to convert a former uranium plant in ohio into a 10gw data center campus. bechtel and kiewit are building it with softbank as the private partner.

the 7 to 10 year view is almost too conditional on scaling laws to predict with precision but the direction holds. by the mid-2030s i expect everything to be AI-enabled, AI-connected, much like the internet is everywhere now. autonomous vehicles will be running local inference, robots in warehouses and factories and eventually jobsites, phones running on-device models for real time tasks while routing complex reasoning back to a data center. all of that needs compute infrastructure. the question is where inference runs and that’s genuinely hard to predict. but the physical footprint of compute grows in every scenario, it just grows differently. however, given the power constraints for the various types of data centers, it begins to get easier to plan for where these will be located across the country.

betting on the future requires conviction in the present. i'm confident in the near term work. i believe the taxonomy separates who's positioned for the medium term from who gets caught in the overcorrection. and i have a view on what gets built when AI is everywhere, which is more than most people can say. i'm betting on American infrastructure.

i don’t believe theres a single product that abstracts away that much functionality, compute, or product capability into a single usable interface in the construction space. not like GPT, google or claude.

the canonical person to build for in construction is the PM. and as you look at PM’s role, they’re held responsible for deliverables through procore, bluebeam, SAP, email, excel, powerpoint, etc. the PM is the product. they’re the one that serves as the translation and abstraction layer between input and deliverable, agnostic of the software solution.

so to best serve this role, i’ve tried to work through marketmaps, venture portfolios, etc. and have yet to find a solution that has a single entry point, a la GPT or claude code, that can be the front door into the rest of the capability of a full end-to-end workflow in construction. let alone having built the product with potential to deliver and capture the exponential slope of product deliverables.

generally, workflows in construction aren’t linear. they’re concurrent, multi-party, and full of conditional logic that changes across companies, projects, etc. however, the fact that many of these are concurrent actually better allows for multiple agents to work in parallel vs. serial fashion, as most construction tech tools force their users to behave.

i believe the single entry point argument adds greater credence to my secondary argument of the slope of possibility. parallelizing agents to deliver value is the compounding mechanism to capture learnings as those learnings then begin to represent the breadth of capabilities to solve for. in turn, those newly surface capabilities lead to new products to build and that’s how you actually deliver against the exponential slope of product. this is why GPT and claude are so good. each interaction and capability influences the next with emergent understand within a single system, not across a portfolio of them. today, that’s the PM’s responsibility to hold of these in their head. but if their mental load is fragmented across tools, that also means there’s fragmented learning. and it’s the learnings that create the exponential slopes.

the analogy is google. by indexing the web and then enabling search, they learned the relationships between disparate ideas/sites/content + intent around that. then they created "learning harnesses" via products like maps/android/gmail/youtube/chrome/etc. the underlying concept is that you need compounding context to make the next iterative product capability and therefor product experience that much better.

the challenge with this modality is theres a dislocation today between how enterprises interact and buy product vs. the necessary capabilities required to move the industry forward via contextualized and aggregated learnings.

so people build feature factories to try and find the entry point to try and solve for this dynamic. the problem is that those feature factories lead to m.c. escher’s stairway to nowhere or even worse to a rube goldberg experience with contractors, where progress is observed but energy is wasted.

so if you’re going to build a product that consolidates a wide breadth of capability into a single entry point, you must do so in a way that allows for exponential learnings based on behavioral, temporal, and relational inputs.

The industry problem is that everyone assumes the path to the endgame for themselves or their organization is linear. And that’s fair, because it always has been. Because that’s how buildings get built. And most importantly, because linear, sequential logic is the mental model construction was built on.

However, the path forward is not linear. The correct path forward is exponential. Through this lens, it becomes more clear how the next few years, the middlegame, has to be played.

Skipping the middle

Many in this space are assuming the conditions of the endgame already exist. A few examples.

An argument is currently being made that AI will eliminate RFIs. The endgame crowd says AI will eliminate RFIs (wrong, the preconditions don't exist yet). The linear crowd says organize your data first, then deploy AI (wrong, too slow). The correct answer is to deploy AI against the messy data now, surface what matters, and let the structured data layer emerge from usage rather than from a two-year data governance initiative.

Many are also arguing that automation will compress closeout from twelve weeks to two. This assumes someone documented what got installed vs. specified. The reality though is closeout is a bear because as-built drawings are a fiction maintained by mutual consent between contractor and owner. The linear argument is to document everything but your project engineer probably didn’t. The correct answer for closeout is to have agents cross-reference submittals to progress photos, to completed RFIs, to BIM and create a turnover package to the owner with built-in O&M manuals. The documentation emerges from the process, not before it.

Another claim is that machine learning will predict schedule delays. The endgame crowd assumes structured data is flowing from a process that still runs on phone calls. The linear crowd says capture those calls with voice AI. That solves collection. It does not solve interpretation or action. The challenge is to question why a digital representation of reality is even needed within Autodesk Build/Forma, et al. or even the right goal. It feels right to disagree because it’s logical, it’s clean, and it’s correct in the old world. However, the fact that it’s true in the old world is what makes it so dangerous as a mental model in the new world.

These are endgame, future state dynamic environments grafted onto an industry that has barely played the opening sequence.

Turner’s in the middlegame and is playing a different game entirely, which I’ve previously written about. There are only handful of companies that will be able to compete with them within 5-10 years. And therefore the endgame solutions being pitched actually work for that segment of the market because the preconditions exist.

These are outliers and yet the construction technology market is building products as though every GC is Turner. They’re selling endgame software to opening-game companies and wondering why adoption keeps stalling with pilots.

The exponential trap

Here is where the linear mental model does real damage.

A startup building for the linear world optimizes existing workflows. Faster submittals. AI-powered estimating. The pitch is efficiency, the pricing is per-seat, and the customer conversation is about time savings. These companies look successful for 18-48 months. They close deals with VPs of Preconstruction who have an AI budget and need to show their CEO they’re doing something.

And then the floor collapses. Because the workflows they optimized stop existing in their current form. When a project engineer or project manager can do the work that currently requires three people, “faster submittals” is not a product category worth buying, or investing, anymore. In parallel, Todd Saunders and Cory LaChance recently showed how industry expertise is more valuable than technical expertise in the age of the exponential, which is exactly this dynamic playing out in real time. Cory used his 15+ years of experience + Claude Code and created a working application that reads piping isometric drawings and automatically extracts every weld count, every material spec, every commodity code.

But the startups that understand the exponential path have a different problem. They look slow. Their growth curves are flat early. They’re building infrastructure, data layers, structured ontologies, transaction networks. A linear (or momentum) investor sees a startup that can’t show ARR traction in year two. An exponential investor sees a loading spring.

This is where patience becomes the differentiator.

The data still has to get structured. The approval chain still has to get documented. The procurement process still has to exist before the payment network can sit on top of it. But the exponential middlegame builds that infrastructure through usage, not before it. The AI surfaces the data, the system captures the workflow, and the foundation emerges from solving real problems rather than from a two-year data clean up initiative that never gets finished. This work does not demo well. It doesn’t make it easy for a principal to argue for an investment in Monday’s investment committee meeting. But it is the only path to the curve.

The danger is that companies doing this work will compare themselves against linearly progressing peers, see someone else ahead on a metric that doesn’t matter in 36 months, and panic. They’ll abandon the middlegame to chase short-term traction. They’ll ship endgame features before the preconditions exist. And they’ll end up exactly where the skip-the-middle companies end up: building castles on sand.

The filter

There is a sorting mechanism forming in this industry. It works on executives, investors, managers, and founders.

Are you maximally AI-pilled or not? Have you updated your priors about what is possible, and are your decisions reflecting that update?

More importantly, the secondary filter to that question is judging if you believe the world is changing exponentially. If so, you also need the discipline to do the middlegame work that makes the exponential payoff possible.

A GC executive who passes this filter is asking what their org chart looks like when a 200-person company has the cognitive output of a 600-person company.

An investor who passes this filter is underwriting middlegame patience at exponential conviction.

I’m not convinced most have adjusted.

Two paths, same destination, different math

Everyone in construction is headed for the same endgame. The question is the math of how they get there and where they actually end up.

Path one assumes linear progress. You buy AI tools, deploy them, measure the ROI, and iterate. Each year is a little better than the last. This path is comfortable because it fits the mental model. It is measurable, sequential, and familiar. It produces reasonable results at a reasonable pace. And it will leave you standing still while the exponential companies pull away.

Path two assumes exponential progress with middlegame patience. The early years look indistinguishable from path one, maybe worse. The growth is flat. The foundational work is invisible. The scoreboard says you’re behind. But the infrastructure is compounding underneath, and when the curve hits, it hits all at once.

The companies, investors, and executives on path two will outperform in the long run, but they must be willing to be wrong for a while.

The endgame will arrive. It will not arrive because someone simulated it convincingly enough. It will arrive because companies did the patient, foundational, middlegame work of building the infrastructure that makes it possible. And they did it with the conviction that the curve was coming, even when the scoreboard said otherwise.

You cannot rush the middlegame just because you see the endgame. But you also can’t play the middlegame with linear assumptions.

The Soviet Union’s approach to industrialization was, by any narrow measure, staggeringly effective. They built factories, dams, railroads, and cities at a pace that no democracy could match. And they built housing at a scale that remains difficult to comprehend. The vehicle for this housing revolution was the Khrushchyovka, a prefabricated concrete apartment block designed in the mid-1950s under Nikita Khrushchev’s directive to solve the Soviet Union’s catastrophic housing shortage. The design was brilliant in its ruthless efficiency. Five stories, because that was the maximum height that did not require an elevator.

The system worked. Hundreds of millions of square meters of housing were constructed across the Soviet Union between 1956 and the mid-1970s. Entire neighborhoods materialized in months. The program housed millions of families who had previously lived in communal apartments, wooden barracks, or wartime temporary structures. By the metric the system was designed to optimize, units of housing produced per year, the Khrushchyovka program was one of the most successful construction initiatives in human history.

The problem was that the metric was wrong.

The Soviet housing system optimized for production volume. It did not optimize for livability, durability, adaptability, or the long-term needs of the people who would inhabit these buildings for decades. There was no market signal to tell the system that kitchens were too small, that sound insulation between units was inadequate, that building the same design in Leningrad and Tashkent regardless of climate was producing structures poorly suited to either location. The system had no feedback mechanism. It could produce. It could not learn.

Ernst May, the German architect who had helped design Soviet socialist cities in the 1930s, visited the USSR in 1959 and described what he saw: a massive building program driven by “revolutionary measures” but characterized by hopeless monotony, with no attempt to enliven the new districts, and insufficient consideration of natural and climatic conditions. The same housing series were being built in regions where they made no sense. Central planning required standardization. Standardization required uniformity. Uniformity meant the system could not respond to information about what was actually working and what was not.

The Soviet Union knew this was a problem. By the mid-1960s, Soviet economists were openly writing about the limitations of centralized planning for a complex modern economy. The diagnosis was clear; and yet, the system was structurally incapable of acting on it.

The American model of postwar industrialization operated under a fundamentally different logic. It was messy, decentralized, and often wasteful. It also had feedback loops built into every layer.

When the Levitt brothers built Levittown in 1947, they applied assembly-line principles to housing construction. They broke the building process into 27 discrete steps, specialized crews for each step, and built 30 houses per day at peak production. The output was not architecturally distinguished. But within five years, homeowners were renovating, expanding, and customizing their Levittown houses in ways the builders never anticipated. Buyers added second stories, converted carports to enclosed garages, swapped exterior siding. Within a generation, American suburbs had more variety in their housing stock than the entire Soviet Union.

The American institutional structure created channels for information to flow from users back to producers. Changes communicated consumer preferences to builders. And as competition forced adaptation, pricing reflected those changes and adaptations. The buyer who chose one house over another sent a signal that propagated through the entire system. The system was imperfect, but it allowed for true progress based on confirmation loops.

When an industrial system lacks feedback loops, it optimizes in the wrong direction. It gets better and better at producing things nobody wants, or things that are adequate today but cannot adapt to tomorrow. Many Khrushchyovkas were structurally sound and yet the housing stock decayed because the system that built them could not learn from what happened after construction was complete. There was no mechanism for post-occupancy reality to influence pre-construction decisions.

The construction industry in 2026 is not the Soviet Union. But the pattern of technology adoption currently underway has more in common with Soviet industrial logic than most people in the industry would be comfortable admitting.

Consider the current wave of enthusiasm around prefabrication and modular construction. The global modular construction market is valued at roughly $90 billion and projected to reach $155 billion by 2033. Venture capital has poured billions into modular startups. The pitch is consistent across all of them: construction is inefficient, factory production is more controlled, therefore move construction into factories. This logic is correct as far as it goes. It is also incomplete in the way Soviet housing logic was incomplete.

The most instructive recent case is Katerra. Katerra’s vision was to control the entire value chain from design through manufacturing through assembly. It was, in structural terms, a miniature Gosplan for construction: centralized planning, standardized production, vertical integration, and an explicit goal of replacing the messy, fragmented existing system with something more rational and efficient.

Katerra filed for bankruptcy in June 2021. The failure was spectacular. Katerra optimized for production efficiency but it hadn’t built feedback loops to the people who would actually use and pay for its products. The demand and feedback signal was missing. As Tom Hardiman of the Modular Building Institute put it, Katerra “tried to integrate the entire process too rapidly and serve a large geographic territory, not fully understanding that each state treats modular and off-site construction a little differently.”

I believe Katerra is the canary in the coal mine. Across the modular and prefab sector, companies are scaling production capacity before solving the demand signal problem. They are building factories before they have confirmed that the output of those factories matches what the market actually can bear, at the specifications the market requires, in the locations where the market will absorb it. This is the Soviet sequence: build the production apparatus first, and then assume demand will conform to supply.

The same dynamic is playing out with AI adoption in construction. The dominant model today is to take existing workflows and accelerate them. Use AI to generate estimates faster. Use machine learning to optimize schedules within existing parameters. Use computer vision to monitor jobsite progress against existing plans. Each of these applications delivers real value and yet none of them changes the underlying logic of how construction operates. They make the current system faster. They do not make it smarter.

The Soviet Union was extraordinarily fast at building housing. Speed was not the problem. The problem was that speed without feedback produced a system that couldn’t adapt, couldn’t improve its outputs over time, and couldn’t respond to changing conditions. The American system was slower and messier, but it compounded improvements over time because information flowed in both directions.

The construction industry’s version of the Soviet trap has a specific mechanism.

When a general contractor uses AI to accelerate estimating, the AI learns to produce estimates that match historical patterns. It gets faster at replicating what the estimating team has always done. If the historical estimating approach systematically underprices certain risk categories or overprices certain material classes, the AI will replicate those errors at greater speed and with higher confidence. The system optimizes for the metric it is given, which is typically speed and consistency with past practice, not accuracy against actual outcomes. Most usage of AI in construction is accelerating existing behaviors, not challenging those same behaviors or creating new ones.

The feedback loop that would correct this, comparing AI-generated estimates against actual project costs and feeding that data back into the model, rarely exists in practice. Most GCs do not have clean, structured data connecting their estimates to final project costs at a WBS or cost-code line-item level. The data infrastructure for learning rarely exists. So the AI accelerates the existing process without improving it.

The alternative is the American model: technology deployed within a system that has feedback loops, that allows information to flow from outcomes back to decisions, and that creates the conditions for the system to learn and adapt over time.

What would this look like in construction? It would look like an AI estimating system that is connected to a structured database of actual project outcomes, and that updates its models based on the variance between predicted and actual costs on every completed project. It would look like a prefabrication operation that tracks post-installation performance data, warranty claims, occupant satisfaction, energy performance, and feeds that data back into the design and manufacturing process. What is missing is the institutional commitment to build the feedback infrastructure.

This is the choice the Cold War provides us. The Soviet Union and the United States both had access to prefabrication technology, industrial manufacturing processes, and centralized production planning. The technology was not the differentiator. The information architecture was. The Soviets built a system optimized for production. The Americans, more by accident than design, built a system optimized for learning.

The alternative path requires building data infrastructure before, or at least alongside, deploying AI tools. It requires investing in the boring, unglamorous work of structuring project outcome data so that predictive systems can be calibrated against reality. It requires procurement systems that capture not just transaction data but performance data. It requires estimating systems that are connected to cost-at-completion databases. It requires a fundamentally different relationship between operations, technology, and information, one where technology isn’t just a tool for doing things faster but a mechanism for learning what to do differently.

The modular and prefab sector faces the same fork. Companies that build factory capacity and then search for demand are running the Soviet playbook. Companies that start with demand signals, that build relationships with end users, that track post-installation signals, and that feed those inputs back into their manufacturing process are running the American playbook. The first approach can produce impressive short-term output numbers. The second approach compounds over time.

The cost advantage of factory production is not automatic. It emerges only when the factory is connected to reliable demand signals and can iterate its processes based on real performance data. Without those feedback loops, factory production just moves the inefficiencies indoors.

We must do better than this. And we can. The factories and infrastructure are already being built. The question is who they’re listening to.

The industry is not growing. Infrastructure, AI and data centers as categories are growing, and everything else is contracting around it.

Turner is subtly showing everyone what happens when you stop treating the CM fee as the core business model. Turner did $29.2 billion in revenue in 2025, a 40% increase from 2024, with a $44.3 billion future backlog. Data centers represent 37% of that backlog. Turner is riding the same wave as everyone else through mission critical work but the difference is what Turner built as they’re riding the wave.

If you just want to see the model, skip to the bottom.

The data center mask

According to the Dodge Momentum Index, the industry grew 0.9% in April 2025. Without data centers, it would have dropped 3%. That’s a concerning drop in planning/momentum.

This is the construction industry’s version of the “magnificent seven” problem in equities. A small number of projects in a single asset class are carrying the entire market’s growth statistics. The ENR Top 400 reported $600 billion in total revenue for 2024, up 7.9%. Median firm revenue was flat with only 64.8% of firms reporting revenue growth, down from 77.3% the prior year. A quarter of firms said their backlogs shrank.

The firms posting outsized growth are the ones with data center exposure: Holder jumped from No. 30 to No. 15. HITT leapt from No. 26 to No. 10. Turner stayed at No. 1 and widened its lead. Barton Malow dropped from No. 19 to No. 35. The top of the ENR list is increasingly a ranking of who has the most hyperscaler relationships, not who is the best builder.

This concentration has a shelf life. Hyperscaler capex grew roughly 60% in 2025, and consensus expects that to decelerate to 20% in 2027, though Goldman Sachs has noted that consensus has underestimated actual spend by more than 30 percentage points in each of the last two years. The boom will continue to peak. But when it slows, the correction will land harder than the market expects, because the baseline expectation reset. A 20% deceleration off $660 billion is not the same as a 20% deceleration off $300 billion. The construction pipeline downstream of these commitments doesn't adjust at the same speed as a capex line item on an earnings call. Explicitly, the concerning part is that contractor backlog gets worked off faster than new projects enter the pipeline.

This is identical to what happened in manufacturing construction. Starts peaked in 2022 and 2023. Spending peaked in Summer 2023. Now manufacturing spending is declining ~5%% annually and the taper has just begun. The same pattern will eventually hit data centers. The only question is when.

The fee problem nobody wants to discuss

When the cycle turns, here is what every GC in the ENR Top 100 will face: the same amount of overhead spread across fewer projects, competing for work against firms that can afford to bid lower because their P&L does not depend on the CM fee.

A traditional GC on a $500 million project can earn a 2.5% CM fee ($12.5 million), converting maybe 25% to EBITDA ($3.1 million), and that’s the bulk of business. The fee is the margin. However, the margin is thin. And when backlogs shrink, fees compress as every GC with capacity is chasing the same shrinking pool of work.

The counterposition Turner just demonstrated is a wildly different model. In its 2025 earnings release, the company named six integrated services businesses:

• SourceBlue (procurement, 300 people, 20+ years of OEM relationships)

• xPL Offsite (prefabrication, 200,000 square foot factory in Alabama)

• Self-Perform Operations (2,500 tradespeople, 35 regional offices)

• First Equipment Company (equipment rental, launched January 2026, serving 40,000 trade contractors)

• Turner Accelerated Payment Program (supply chain finance through Billd, Turner absorbs late-pay risk)

• Turner Engineering Group

On the same $500 million project, these services would generate an estimated $23.5 million in ancillary revenue at a blended 38% EBITDA margin, producing roughly $9 million in EBITDA. That is ~2.6 times the EBITDA from the CM fee alone.

The implication that should keep GC executives awake: Turner has the option to bid 0% on the CM fee and still generate $5.8 million more EBITDA on the project than a traditional GC earns at just 2.5%.

Read that again. Zero percent fee. More profit.

This is a structural problem, not a cyclical one

In a rising market, fee compression is annoying but survivable. You lose a point on fee, but you make it up in volume, so the absolute dollar value increases. In a declining market, fee compression is existential, because you lose the point on fee and you lose the volume.

Turner’s ancillary services model inverts this dynamic. When the market contracts, Turner has two options that most GC’s can’t match. First, it can hold its CM fee steady and earn ancillary revenue on top, using the surplus to invest in capacity while competitors retrench. Second, it can cut the fee to zero, win every project it wants, and still maintain attractive margins on the ancillary services that flow through its platform.

This is the 1990s defense contractor consolidation playbook applied to construction. After the Cold War drawdown, the number of prime defense contractors fell from 51 to 5. If you were a company that already provided integration capabilities (systems engineering, logistics, maintenance contracts) and sold services around those capabilities, you were well positioned for the drawdown. That inversion of revenue generation from projects to services applies to construction.

By 2030, I’d expect the construction industry to have 50 large GCs where 5 will dominate and have optionality, and more importantly, agency of their future.

The AI capex dependency

The catalyst of change will be AI scaling laws affecting capex commitments from hyperscalers and foundational model companies.

AI-related business investment accounted for roughly half of inflation-adjusted GDP growth in the first half of 2025. Hyperscaler capex is projected at ~$600-660 billion for 2026. BCA Research’s chief global strategist has said that without the AI boom, the economy would plausibly already be in recession. Deutsche Bank notes that private business investment outside of AI-related categories is flat.

The construction industry’s exposure to this single variable is staggering. Data center construction hit a $45 billion annual rate in December 2025. Relatively small, but it is the only category with sustained growth and growing momentum. The pipeline of future work, outside of data centers and infrastructure, is contracting based on AIA starts and the Architecture Billings Index.

If AI scaling laws encounter diminishing returns, if hyperscaler revenue growth fails to justify the capex, if interest rates stay elevated or if debt-funded data center builds slow down, the construction industry loses its only growth engine. And firms that over-indexed on mission critical work that jumped 15 spots on the ENR list in a single year will face the sharpest reversals.

To be clear, Turner will face revenue pressure too. 37% of its backlog is data centers. But Turner’s ancillary services platform means its per-project profitability does not depend on the sector mix. Whether it is building a data center, a hospital, a stadium, or a pharmaceutical facility, the same SourceBlue procurement engine, the same xPL prefabrication capability, the same FEC equipment rental, the same Accelerated Payment Program all generate margin on top of whatever fee Turner negotiates.

So why isn’t anyone concerned?

Three reasons.

First, backlogs are still high. The ENR Top 400 is running on work sold in 2024 and 2025, when the market was stronger. It takes 18 to 24 months for a backlog decline to show up in revenue. The pain has not arrived yet, so it does not feel real.

Second, the industry does not think in terms of business model risk like the financial or insurance industries. Construction executives typically think about project risk, labor risk, material risk. The idea that your business model itself is a vulnerability, that the CM fee structure is a trap, is foreign to an industry that has operated the same way for decades. I’ve yet to see a BuiltWorlds or ENR Top 400 conference session about ancillary revenue diversification. They are talking about BIM, lean, AI, and safety culture.

Third, Turner is quiet about this, as they should be. Even the earnings release buries the integrated services narrative in a single paragraph. The strategy is visible only if you map the subsidiaries, model the economics, and compare the resulting P&L to a traditional GC’s. Turner has no incentive to advertise the fact that it can underprice every competitor and still make more money.

The omission is the signal though.

What this means for GCs

If you run a general contracting firm and your core margin comes from the CM fee, you have a defined window to build ancillary revenue capability before the cycle turns. That window is open now, while backlogs are still healthy and you have the cash flow to invest. It will close when backlog declines force you to cut overhead instead of building new capability.

The services Turner built did not appear overnight. SourceBlue launched in 2001. The Accelerated Payment Program started in 2014. Self-Perform Operations has been scaling for years. xPL Offsite formalized in May 2025 after two decades of prefabrication experience. First Equipment Company launched in January 2026 after piloting on large projects. This is a 20-year strategy that is now reaching critical mass at exactly the moment when the market is about to test it.

Every GC with ~$1 billion or more in revenue should be asking three questions right now.

• What percentage of my EBITDA comes from services other than the CM fee?

• If I had to bid at 1% fee to win a major project, would I still be profitable?

• And if the answer to that second question is no: what am I going to do about it before Turner bids 0% on my best client’s next project?
  

Turner doesn't publish segment economics, so I built a model using industry benchmarks for each service category to model this out.

At the same time, the AI economy is pouring an estimated $600 billion into AI capital expenditure in 2026 alone. That money is flowing into data centers, AI infrastructure, foundation models, and related software. Almost none of it is oriented toward an industry that literally builds the physical infrastructure every other industry depends on.

This mismatch should alarm anyone who cares about American economic competitiveness. You cannot have a functioning economy if the sector that constructs its hospitals, highways, power plants, and housing simply runs out of people and never finds a technological substitute.

But alarm is not a strategy.

The question is: how does a $2T industry that has chronically underinvested in technology, that operates through deeply fragmented local markets, and that is losing its most experienced workers to retirement actually close the gap?

History offers a surprisingly useful answer. From China.

The Humiliation Problem

In 1842, the Qing Dynasty signed the Treaty of Nanking after losing the First Opium War to the British. It was a defining moment of national humiliation. The most powerful empire in East Asia had been defeated by a smaller nation with superior industrial technology. The treaty ceded Hong Kong, opened five ports to foreign trade, and forced China to pay war indemnities. But the deeper wound was psychological. China’s leadership class had to confront the fact that they were technologically behind, and that the gap was widening on the global scale.

What followed was nearly 150 years of false starts. The Self-Strengthening Movement of the 1860s tried to graft Western technology onto Chinese institutions without changing the underlying system. It produced some modern arsenals and shipyards but collapsed when those surface-level upgrades met the stress of actual conflict. The Republic era brought political fragmentation. The Mao years brought ideological rigidity. Each period recognized the core problem but failed to build the institutional infrastructure necessary to solve it.

The construction industry has its own version of this story. For at least two decades, the industry has known it was falling behind. Productivity growth in construction has been flat since the 1990s while nearly every other major sector has compounded gains. The technology gap is widely acknowledged. Conference keynotes repeat it. Industry reports quantify it. Everyone in a leadership position at a major general contractor or specialty trade can describe the problem with precision.

And yet the institutional response has largely mirrored China’s Self-Strengthening Movement: adopt some new tools, layer them on top of existing workflows, and hope the gap closes. BIM was supposed to be the revolution. Then it was cloud-based project management. Then drones, VR, and reality capture. Each technology delivered real but incremental value. None fundamentally changed the industry’s productive capacity. The underlying system remained untouched.

Why? When an industry operates through thousands of independent firms competing on local relationships, bonding capacity, and labor availability, there is no natural mechanism to coordinate a technology transition at scale. Every company optimizes for its own operations. Nobody optimizes for the industry.

Local Maximum, Global Minimum

This is the core problem, and it is worth stating plainly. The construction industry has been finding local maxima for decades. Each firm runs its own pilots, builds its own internal tools, protects its own workflows, and guards its own competitive advantages. From the perspective of any individual company, this is rational. From the perspective of the industry, this is catastrophic.

Consider what this looks like in reality. A top-50 general contractor invests in a robotics pilot. They test it on a few projects. It shows promise. They keep it internal. Across town, another contractor is running a nearly identical pilot with a different vendor, learning the same lessons, making the same mistakes, reaching the same conclusions. Multiply this across 50 firms and a decade, and you have an industry that has spent billions on R&D and produced almost no compounding returns.

This is the problem China faced before Deng Xiaoping’s reforms. In the late 1970s, China was growing into its industrial ambition. Every province had some version of an industrial development plan. But these plans were uncoordinated, redundant, and subscale. Each province was finding its own local maximum. The national result was stagnation.

Deng’s insight was that you could not reform the entire system at once, but you could create a concentrated zone where new rules applied, where investment was directed, where learning could compound, and where the results could then permeate outward to the rest of the country. That zone was Shenzhen.

What Shenzhen Actually Was

It is easy to romanticize Shenzhen as a story of free-market magic. It was not. It was intentional. It was an act of deliberate institutional design.

In 1980, Shenzhen was a fishing village of roughly 30,000 people across the border from Hong Kong. The Chinese government designated it as one of four Special Economic Zones with a specific set of structural advantages: tax incentives for foreign and domestic investment, relaxed regulatory requirements, special trade rules, and concentrated infrastructure spending. The government did not simply declare Shenzhen open for business. Rather, they built the physical and institutional infrastructure that made business possible at scale.

The result was not immediate. Shenzhen started at the low-end of manufacturing: textiles, simple assembly, basic electronics. The early output was not impressive by global standards. But the structure of the SEZ meant that learning compounded. Suppliers clustered around manufacturers. Workers developed specialized industrial skills. The infrastructure around these operations improved. Foreign and domestic capital flowed in. And critically, the knowledge generated inside the zone flowed back to the rest of the country.

Shenzhen did not stay a low-end textile hub. Within two decades, it became the electronics manufacturing capital of the world. Then it became a center for telecommunications, biotechnology, and advanced hardware. The mechanism was the same throughout: geographic concentration of talent and capital, regulatory flexibility, and a structure designed to move up the value chain over time.

Today, Shenzhen is a city of 18 million people with a GDP larger than most European countries. It is home to Huawei, Tencent, BYD, and DJI. The fishing village became the proof of concept for the most significant industrial transformation in modern history.

Construction Needs Its Own Shenzhen

The American construction industry cannot replicate the Chinese SEZ model directly. The political, economic, and institutional contexts are too different. But the underlying logic still holds.

The industry needs a physical location where the top general contractors, specialty trades, equipment manufacturers, robotics companies, and AI firms can colocate. A place where pre-competitive R&D happens in shared facilities, where robotics and prefabrication lines operate at scale, where AI systems are trained on real project data from real projects and operations, where the lessons learned flow back to each company’s home operations.

St. Louis makes the most geographic sense. It sits in the center of the country, connected to every major construction market by a day’s drive or a short flight. Cost of living is a fraction of the coastal tech hubs that have absorbed most technology investment. The surrounding region has significant ongoing construction activity that provides a natural testing ground. And the symbolic value matters of building in the heartland matters - this can’t be another coastal technology initiative. This ought to be the construction industry building something for itself, in the middle of the country, in its own weird way.

Picture the top 50 general contractors each maintaining an office and manufacturing presence in this zone. Shared robotics labs. Shared prefabrication facilities. Shared data infrastructure for training AI models on estimating, scheduling, and logistics. Each company retains its competitive differentiation in culture, execution, client relationships, and project delivery. But the foundational technology layer becomes shared infrastructure, the same way semiconductor companies share TSMC’s fabrication capacity while competing fiercely on chip design.

My economic argument for Construction’s Shenzhen is based on the idea that the construction industry cannot afford to have 50 companies independently solving the same technology problems at subscale. The math does not work. The timeline does not work. The workforce crisis will arrive faster than any single company’s innovation pipeline can respond to it.

The Workforce Clock

The urgency of this proposal becomes clear when you examine the demographic math.

The construction workforce skews older than nearly any other major sector. The median age of a construction worker in the US is 42, and in the skilled trades, the concentration at the upper end of the age range is more severe. The industry needs to attract roughly 500,000 new workers per year just to keep pace with demand and retirements. It has consistently fallen short of that number, with limited signs of relief in the near future.

In previous eras, when American industries faced labor shortages, the answer was offshoring. Manufacturing went to Mexico, then China, then Southeast Asia. Call centers went to India. Software development distributed globally. But construction is fundamentally place-bound. You cannot offshore the construction of a hospital in Houston or a data center in Virginia. The work has to happen where the building is.

This means the construction industry’s version of a “cheaper labor pool” has to be synthetic. AI and robotics must be the default enhancements to construction productivity. They are the replacement workforce. Without them, the industry will contract as workers retire, and 7% of GDP gradually hollows out.

China faced an analogous challenge in the late 1970s, though the direction was reversed. China had abundant low-cost labor but lacked the industrial infrastructure and technical knowledge to deploy it productively. The SEZ model solved this by creating the conditions for rapid capability building. Concentrated investment. Concentrated talent. Regulatory flexibility. Feedback loops that allowed the system to learn and improve continuously.

Construction’s workforce problem is the mirror image, abundant work but shrinking labor, yet the structural solution is the same. You need a concentrated environment where the next generation of construction capability, whether that is autonomous equipment, AI-driven scheduling, or advanced prefabrication, can develop at a pace that matches the urgency of the workforce decline.

Why the Current Approach Fails

The construction industry’s current approach to technology adoption is failing because the adoption model is structurally incapable of producing results at the necessary speed and scale.

Here is how it works today. A large general contractor identifies a technology need. They evaluate vendors. They select one. They run a pilot on a project or a few. The pilot produces mixed results because the technology is being tested in a live production environment with minimal integration support. The pilot gets written up internally. Some lessons are learned. The company decides whether to expand or not. This process takes 6 to 18 months per technology, per company.

Meanwhile, the AI industry is operating on a fundamentally different clock speed. Foundation models are improving on a quarterly cadence. New capabilities emerge monthly. The gap between what is technologically possible and what the construction industry is actually deploying widens every quarter.

The SEZ model addresses this by changing the unit of technology adoption from the individual firm to the industry. When 50 companies share a development environment, the cycle time compresses dramatically. A robotics system that fails in one application gets retested in another within days or weeks, not years. An AI model that produces useful results for estimating and preconstruction gets immediately tested on scheduling, logistics, and procurement. The compounding effect throughout the industry is the entire point.

Shenzhen did not produce one successful company. It produced an ecosystem where thousands of companies could iterate simultaneously, feeding off each other’s progress. That ecosystem effect is what construction lacks and exactly what a concentrated physical zone could provide.

The Investment Case

To be clear, this is an investment thesis.

The US construction market produces approximately $2T in annual output. Even a 5% improvement in productivity, well within the range of what concentrated AI and robotics deployment could deliver, represents $100 billion in annual value creation. Against the cost of establishing and operating a construction SEZ, even at a scale of several billion dollars in initial investment, the returns are compelling.

But the investment case extends beyond direct productivity. A construction technology zone of the type described here would attract an unprecedented amount of risk capital (venture, private equity, etc.), corporate R&D spending, and federal infrastructure investment that currently has no natural home. The $600 billion in AI capex flowing into the economy in 2026 alone is looking for high-impact deployment targets. An industry that represents 7% of GDP and directly builds the physical infrastructure for AI (data centers, power plants, transmission lines) is a natural candidate, if it can present a credible vehicle for technology adoption.

Today, that vehicle does not exist. The construction industry’s fragmentation makes it nearly impossible for large-scale technology investors to deploy capital efficiently at this scale. There is no single point of entry. No shared infrastructure. No coordinated demand signal. A construction SEZ solves this by creating the institutional structure that capital requires.

China understood this implicitly. The SEZ was not just a place for companies to operate. The SEZ became a signal to global capital that China was serious about industrial transformation. Foreign direct investment poured into Shenzhen because the institutional structure communicated intent and reduced risk. The construction industry needs to send the same signal.

Studying the Peer

There is a cultural resistance in the American construction industry, and in American business more broadly, to studying China as a source of strategic insight. This resistance is understandable given the geopolitical context. It is also a luxury that we as an industry facing a structural crisis cannot afford.

China solved an industrialization problem that looks structurally identical to the one the construction industry faces today. They started from a position of acknowledged technological inferiority. They lacked the institutional infrastructure to adopt foreign technology at scale. They faced a workforce that needed to be rapidly upskilled. And they operated in a fragmented institutional landscape where coordination was the binding constraint.

Their answer was geographic and regulatory concentration, massive directed investment, and a willingness to iterate rapidly based on results rather than ideology. The specific policies were Chinese. The structural logic is universal.

The sooner the construction industry treats China’s industrial transformation as a case study worth rigorous analysis rather than a geopolitical talking point, the sooner it can develop playbooks for its own transformation. The parallels are structural. And the clock is ticking.

The Choice

The American construction industry is going to transform over the next two decades. That much is certain. The workforce demographics alone guarantee it. The question is whether that transformation is deliberate and concentrated, or whether it happens through slow attrition as companies individually scramble to replace retiring workers with whatever technology happens to be available.

The first path requires something the construction industry has never built: a shared institution for pre-competitive technology development. A physical place. Real capital. Serious commitment from the companies that collectively define the industry. It requires the same logic that turned a fishing village into the manufacturing capital of the world.

The second path is the default. It is what happens when an industry that represents 7% of GDP continues to treat technology adoption as an internal initiative rather than a collective infrastructure problem. It is the path of continued fragmentation, continued subscale investment, and a continued widening of the gap between what is possible and what is deployed.

We have the historical precedent. We have the economic rationale. We have the urgency. The question is whether the construction industry has the institutional will to build its Shenzhen, or whether it will spend another two decades finding local maxima while the rest of the economy moves on.

The window for deliberate, concentrated action is open. It will not stay open forever.

We have the urgency, the question is whether we have the agency.

That’s effectively an underwriting submission. The GC has already done the work that an insurance carrier would need to do to price the risk. But in the current structure, that data sits in a prequal database, or worse, a shared drive somewhere, completely disconnected from the insurance program that prices the exact same risk.

The carrier writing the CCIP has almost none of this information at the individual sub level. They’re typically pricing the insurance wrap based on the GC’s aggregate loss history, the project type, the geography, and maybe the total sub cost breakdown by trade. They’re not underwriting each sub’s risk profile the way the GC’s prequal team already has.

The GC is paying a premium on insurance coverage that reflects the carrier’s uncertainty. That uncertainty is something the GC already resolved internally with prequalification.

What’s a Captive?

A captive is a licensed insurance company owned by its parent. If the captive is domiciled in a jurisdiction that permits the relevant lines of business and is adequately capitalized, it can underwrite GL (general liability), workers comp, builder’s risk, and CCIP/OCIP wraps on its own projects. Many of the largest GCs already operate captives. Zurich, Chubb, The Hartford, and other major construction program carriers know that their most sophisticated clients are either running captives today or evaluating them.

To be clear, this only works when the GC has enough premium volume, strong loss history, and the operational discipline to manage claims.

Stand up the captive in a favorable domicile. Start with the lines where the GC has the most data advantage and the most premium volume, typically GL and workers comp through CCIP structures. Build the actuarial track record over two to three years. Then expand into additional lines as the captive’s surplus grows and the reinsurance market gets comfortable with the program, and you will need reinsurance.

The Data Advantage

A captive flips the information asymmetry. The GC’s prequal data becomes the underwriting engine. You know which mechanical sub has a 0.6 EMR and pristine financials versus which concrete sub is thinly capitalized with a rising DART and incident rate. You can price CCIP enrollment accordingly, or more importantly, you can make better decisions about risk retention levels. Keep more risk on the subs you’ve already vetted as strong. Buy reinsurance for the tail exposure or the trades where loss frequency is harder to predict.

Then layer in the real-time project data. During execution, the GC’s field teams generate daily logs, safety observations, schedule updates, and RFI volumes. All of these are leading indicators of a loss. Pair that with existing and historical data from past projects and now you have an early underwriting engine. A sub falling three weeks behind schedule burning through twice the number of RFIs might be in over their head technically and could require additional insurance products like trade insurance. PMs and PXs know this. Carriers don’t.

None of this data flows to an insurance carrier today. In a captive structure, it can feed directly into reserving and risk management decisions.

The GC running a CCIP through its own captive is now capable of building a unified risk view across the entire project. The CCIP covers the casualty exposure from the sub’s work. The prequal data and project execution data give you the leading indicators that an external carrier can’t access. A captive structure lets you price that correlation properly.

Right now in the model, insurance brokerage is positioned as a commission business. The captive argument is that a GC should be capturing the underwriting margin, not just the brokerage commission. The SDI line already assumes the GC is retaining subcontractor default risk at a 35% underwriting margin after claims reserves. That's the captive in action. The CCIP insurance and SDI lines together add $2.5M in revenue at blended EBITDA margins north of 45%. That's an incremental $1.1M in EBITDA from risk the GC is already managing operationally.

Every one of these ancillary lines exists because the GC sits at the center of the project's information and cash flows.

Why You Can’t Also Be a Broker

You can’t be a broker and run a captive without introducing serious conflicts.

A broker’s value proposition is built on independence. They shop the market on behalf of the insured, comparing coverage and pricing across carriers. The moment a broker also operates as an MGA or MGU, they’ve introduced a conflict.

The same logic applies to brokers who manage GC captives. If a broker is advising a GC on their insurance program and also administering that GC’s captive, they’re earning fees on both sides. They’re consulting on risk retention levels (how much goes into the captive vs. the commercial market) while simultaneously earning administration fees from the captive entity. Every dollar that stays in the captive is a dollar the broker didn’t place in the open market, but it’s also a dollar generating captive management fees. The incentives don’t cleanly align in either direction, which is almost worse than a clear conflict because it makes the bias harder to identify.

For a GC evaluating a captive, this means the decision about how much risk to retain is a capital allocation decision, not an insurance decision. It depends on the GC’s balance sheet strength, cash flow predictability, project mix, geographic concentration, and tolerance for volatility. A broker who also runs the captive has a hard time giving disinterested advice on those capital allocation tradeoffs.

Group Captives

The single-entity captive is the obvious move for a top GC with >=$1B+ in annual revenue. But the more interesting structural play is the group captive, where multiple GCs pool risk into a shared vehicle.

A single GC running $30M in annual construction insurance premium through a captive has a concentrated book. One bad project year, a crane collapse or a multi-fatality incident, can blow through reserves and force a capital call from the parent. A group captive with four or five large GCs writing $120-150M in combined premium creates diversification. Different project types, different geographies, different trade mixes. The reinsurance market prices that pool differently than it prices any individual GC’s book, and the rates reflect it.

The harder question is competitive dynamics. GCs compete for the same projects, often with the same subcontractors. Sharing prequal data through a group captive means your rival can see which subs you’ve vetted, how you’ve scored them, and implicitly, which ones you trust enough to carry risk on.

But look at what the credit card networks figured out decades ago. Visa and Mastercard are owned by banks that compete fiercely for customers. Those same banks share fraud data, transaction risk scores, and default information through the network because the shared infrastructure makes everyone’s individual book more profitable. The competitive advantage moved up the stack, from “who has better data” to “who uses the shared data more effectively in their own operations.”

The same logic applies here. If four top-50 GCs standardize their prequal frameworks and pool subcontractor performance data into a group captive, the result is something that doesn’t exist anywhere in construction today: an industry-level credit bureau for trade partners. Every GC in the pool benefits from a normalized view of subcontractor financial health, safety performance, and operational capacity. The competitive differentiation shifts from “who has decent prequal data” (everyone does) to “who acts on it best in pricing, project staffing, and risk retention decisions.”

Administration is the practical bottleneck for this type of product. Someone has to run the captive, and it can’t be any of the participating GCs without reintroducing the conflicts described above. A third-party captive manager with no brokerage or placement business is the clean structure. The captive board would include risk officers from each participating GC, with actuarial and claims functions outsourced to specialists. Group captives exist in healthcare, transportation, and energy. Construction is just late to the model.

The trigger that makes this happen is a hard insurance market when commercial carriers tighten capacity and raise rates on construction programs (which happens cyclically and is happening now in certain casualty lines). This also happens when the economic case for retained risk through a group captive becomes impossible for CFOs to ignore. The GCs that have already built the data infrastructure and prequal standardization should be able to stand up a group captive in 12-18 months for GL, workers comp, and SDI.

Compounding Advantages

Two to three years of loss data underwritten with superior information creates a performance history that reinsurers will price favorably.

This new entity owns the actuarial track record. Two to three years of loss data underwritten with superior information creates a performance history that reinsurers will price favorably. That pricing advantage compounds. Every year the captive operates with better-than-market loss ratios, the reinsurance terms improve, which widens the cost gap between the captive GC and competitors still buying coverage at market rates.

It owns the data asset. Structured prequal data linked to actual project outcomes (safety incidents, schedule performance, claims history) is the training set for underwriting models that get better over time. GCs building this have a two to three year head start that no amount of capital can compress.

And it changes the talent equation. The best project executives and risk managers will want to work at the GC where their operational discipline directly improves the company’s financial performance through the captive. A safety director whose programs reduce captive losses is visibly contributing to the bottom line in a way that’s impossible when insurance is just a line item managed by an external broker.

Don’t wait to watch insurance costs rise with the market while your competitors’ costs decline with their own performance. In a 2-3% margin business, that spread is the difference between winning work and subsidizing someone else’s risk pool.