Coding agents are letting enterprises build software capabilities they would previously have bought. That changes enterprise AI build vs buy: the vendor’s most dangerous competitor may now be the customer.
For two decades, the enterprise software build-versus-buy question had a familiar answer: buy the commodity, build the differentiator, and let the boundary between the two drift slowly in the buyer’s favor. That boundary deserves a name. Omega Venture Partners calls it the build line: the moving edge between what a company builds for itself and what it pays a vendor to supply.
The line has moved. In McKinsey’s State of AI survey, published August 25, 2026, 32 percent of organizations said they had decided against buying at least one software product or feature because agentic coding tools let them build the functionality internally.
As code gets cheaper to reproduce, durable enterprise software value shifts toward assets a buyer cannot economically recreate within the relevant decision horizon: origin data, standing proof, absorbed liability, network state and maintained truth. Omega calls this the Rebuild Test.
Enterprise AI build vs buy: where the line moved
McKinsey fielded its survey from May 4 to June 8, 2026, across 1,719 respondents in 97 nations. The build-versus-buy finding is not evenly distributed. Among organizations McKinsey classifies as AI high performers, nearly half declined at least one software purchase in favor of an in-house build, compared with 31 percent of other respondents. The decisions were most commonly reported in technology and healthcare, followed by professional services and energy and materials.
The result cuts against a common enterprise software assumption. The lighthouse logos vendors chase as reference customers are also the buyers most capable of reproducing a bounded feature.
Our read is that capability, more than thrift, drives the difference. Companies that have already redesigned workflows around AI and staffed engineering around agents have more of the operating muscle needed to rebuild software internally. McKinsey shows the correlation; the causal explanation is ours.
Retool’s 2026 Build vs. Buy Report points in the same direction. Released February 17, 2026, it found that 35 percent of teams had replaced at least one SaaS tool with custom-built software. The report surveyed 817 Retool customers and builders in late 2025. Because the sample consists of Retool customers and builders rather than a general enterprise sample, Omega treats it as supporting evidence rather than a market-wide estimate.
What did not move: enterprise software spending
Every few years someone announces that SaaS is finished, and the claim keeps failing. It fails here too. Gartner’s July 27, 2026 forecast puts worldwide software spending at $1.468 trillion in 2026, up 15.5 percent from $1.271 trillion in 2025. That growth rate exceeds Gartner’s 14.2 percent forecast for total IT spending.
There is no contradiction: software budgets can rise even as individual purchases disappear. Gartner measures the overall software market; McKinsey and Retool capture substitution at the level of specific products and features.
The build line did not move around the entire market. It moved through the middle of it. Bounded features, internal tools, reporting surfaces and integration glue are more exposed when the customer already owns the inputs and a small team can define the scope.
The Rebuild Test for enterprise AI build vs buy
Omega Venture Partners applies one test to enterprise AI build vs buy: what could this customer not economically originate or reproduce within the relevant decision horizon? Coding agents can write more software. They cannot manufacture years of operating history, other customers’ participation, inaccessible data, a balance sheet willing to absorb liability, or external truth that must be kept current.
The test applies to the asset actually possessed, not the label attached to it. Each category must be demonstrably costly, slow or impossible for the customer or a credible competitor to reproduce within the relevant decision horizon.
- Origin data. A corpus the customer cannot generate from its own operations because it is cross-customer, longitudinal, licensed or observed from a vantage point the customer does not occupy. Calling data “proprietary” is not enough. If an equivalent corpus can be readily scraped, licensed or reconstructed, it is not origin data for purposes of the Rebuild Test.
- Standing proof. Certification, audit history, actuarial evidence, clinical validation or other evidence whose value genuinely compounds through recognized operating history. A generic compliance badge is not automatically a moat. The proof must become materially harder, slower or riskier for a replacement vendor to recreate. Omega’s earlier argument that accountability is becoming vertical AI’s durable moat is the same asset viewed from the buyer’s side.
- Absorbed liability. The vendor is contractually and financially answerable for an outcome in a way that creates economically meaningful risk transfer. The label does not matter if contractual caps or exclusions make the vendor’s exposure trivial relative to the risk. An internal build keeps that exposure inside the enterprise.
- Network state. Value that depends on other customers or counterparties participating: benchmarks, matching, interoperability, supplier graphs or threat graphs. The relevant question is whether an internal replacement would face a genuine cold-start problem, not whether the vendor merely describes its product as a network.
- Maintained truth. An external knowledge surface that decays without continuous upkeep: tax rules, payer rules, regulatory filings, threat intelligence, entity records or supplier data. The build may take a quarter. The maintenance obligation does not end.
These assets can compound. Network state paired with maintained truth, for example, forces a replacement to solve both a cold-start problem and a permanent upkeep obligation. The combined rebuild barrier can therefore be greater than either asset creates alone.
The Rebuild Test remains useful as coding agents improve because its hardest categories are not code-bound. Better agents lower the cost of producing code, but they do not compress years of operating history, create outside participation, originate inaccessible data, assume legal exposure or eliminate continuous external maintenance. In that sense, these moats are agent-capability-invariant: cheaper code does not erase the barrier.
Enterprise AI build vs buy economics: the Rebuild Cost Ratio
A test that cannot be priced is an opinion. Omega converts the Rebuild Test into a diligence metric: the Rebuild Cost Ratio, defined as the customer’s fully loaded three-year cost to build and operate an equivalent capability divided by the three-year contract value.
The numerator should use the best agent-assisted build path available at the decision date and be refreshed as capabilities change. It should not assume a static pre-agent development process. That keeps the ratio conservative without speculating about future model progress.
Consider a contract worth $180,000 a year, or $540,000 across three years. For illustration, assume a fully loaded U.S. enterprise engineer—salary, benefits and overhead included—costs $250,000 a year; a reader should substitute their own cost structure. Two engineers for four months equal two-thirds of an engineer-year, or about $167,000. Maintenance at four-tenths of an engineer-year for each of three years adds $300,000.
The baseline rebuild cost is therefore $467,000, producing a Rebuild Cost Ratio of 0.86 before any environment-specific QA, rework, security, governance or non-originable-asset costs are added.
AI-assisted development does not eliminate QA or maintenance. A 2026 arXiv preprint, analyzing 304,362 verified AI-authored commits across 6,275 public GitHub repositories, found that more than 15 percent of commits from every assistant examined introduced at least one issue. It also found that 24.2 percent of tracked AI-introduced issues remained in the repository’s latest revision. Because this is a public-repository study and a preprint—not an enterprise cost study—Omega does not translate those findings into a universal rework surcharge. Teams should price their own QA, security, governance and maintenance burden.
At a ratio below 1.0, cost alone does not justify the purchase. The vendor must earn its premium through non-originable assets or a material advantage in time, risk or operating burden. Omega’s working screen in this framework is a Rebuild Cost Ratio of 3.0 or better before giving additional credit for non-originable assets. The 3.0 level is a conservative underwriting threshold, not an empirical law; it leaves room for estimation error, improving tooling and omitted operating costs.
What the new build line changes for management teams
For management teams, the competitive set in an enterprise deal now includes a build that never appears in the bake-off. Some deals die in a planning meeting the vendor never attends. Management teams should position and price against rebuild cost, put non-originable assets at the front of the pitch, and make the business case in the customer’s own cost structure.
For investors and allocators, growth and retention assumptions written before agentic coding tools existed carry a hidden term. Some of what companies used to buy can now be supplied internally, and the risk is greatest where the customer is most capable.
Two questions now belong in enterprise AI diligence. What is this company’s Rebuild Cost Ratio at its median contract? And how much of its revenue rests on an asset the customer cannot economically reproduce within the relevant decision horizon?
Omega’s enterprise AI underwriting implication
The Rebuild Test extends a line of thinking Omega has published for years. In our Forbes work, we treated AI as a general-purpose technology while separating technical novelty from durable business value. At Stanford Graduate School of Business, we emphasized defensible data assets, real-world applications and measurable ROI. Agentic coding changes the cost of producing software; the underlying underwriting question remains: what stays hard to reproduce?
We also see the issue from the buyer side through Omega’s Strategic Partner Network, a bespoke network of advisors and enterprise customers designed to help accelerate portfolio companies and provide access to enterprise decision-makers. Those decision-makers make or influence the choice at the heart of this article: contract, internal build, or no budget. That buyer perspective is the other half of the Rebuild Test—technical defensibility matters only if customers will keep paying for it.
For founders, the product roadmap should strengthen the assets that matter more as code gets cheaper: origin data, standing proof, absorbed liability, network state and maintained truth. For investors, the task is to distinguish temporary feature advantage from software that remains expensive to replace even when code gets cheaper.
The most durable enterprise AI companies will be the ones customers cannot economically recreate as a system, even when they can reproduce the code. That is the build line Omega is underwriting.
Sources
- McKinsey & Company, The State of AI in 2026: On the Road to ROI, published August 25, 2026; survey fielded May 4 to June 8, 2026, with 1,719 respondents in 97 nations.
- Retool, The Build vs. Buy Shift: How Vibe Coding and Shadow IT Have Reshaped Enterprise Software, released February 17, 2026; 817 Retool customers and builders surveyed in late 2025.
- Gartner, Gartner Forecasts Worldwide IT Spending to Grow 14.2% in 2026, Totaling $6.37 Trillion, July 27, 2026.
- Liu, Widyasari, Zhao, Irsan and Lo, Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild, arXiv:2603.28592, 2026; accessed August 30, 2026.