A private equity firm was running due diligence on a SaaS company. Standard process: evaluate the product, the market position, and the technical defensibility. But this time, the consulting team added a new step. They took the target company’s core product and asked an AI coding assistant to replicate it. In days, they had a working prototype that reproduced the core workflow. The bidder walked away. The prototype wasn’t production-grade, and it didn’t need to be; it proved the product could be reproduced faster than the acquisition could close.
That story came from a Financial Times report on Bain & Company, which has adopted AI-assisted replication as a due diligence tool for PE clients. It landed in my inbox the same week Retool published their 2026 Build vs. Buy Report. Retool’s headline finding: 35% of enterprise teams have already replaced at least one SaaS tool with a custom build, and 78% expect to build more this year.
For CTOs paying attention, the signal is clear. The economics that made “buy” the safe default for two decades have shifted. But they didn’t shift uniformly, and they didn’t shift completely. The organizations getting this right are the ones that understand both what changed and what didn’t.
Ownership is everything that happens after the first deployment: security patching, compliance audits, incident response, onboarding engineers who weren’t there when the code was written, and keeping the system legible as it evolves. That cost doesn’t appear on the build estimate.
What shifted
Start with the model economics. As of mid-2026, open-weight models run roughly 10 to 12 times cheaper than frontier SaaS for a growing set of common workloads: summarization, classification, code generation, data extraction. The per-transaction math that made SaaS the obvious choice for anything below enterprise scale has eroded.
Development timelines compressed at the same time. What used to take a quarter can now be scaffolded in days, and a capable engineer with Claude Code, Github Copilot, Kiro or Codex can produce a working internal tool in the time it used to take just to complete vendor procurement. The build duration that historically justified the “buy” premium shrank by an order of magnitude for certain workload types.
Then the markets repriced the risk. In February 2026, over $285 billion in SaaS market capitalization evaporated in a single week of panic selling that analysts dubbed the “SaaSocalypse.” Thomson Reuters dropped 15.8%, LegalZoom fell 19.7%. The repricing was about future defensibility: if your core product can be replicated in days by a consulting team running a coding agent, what exactly is the buyer paying for?
Cheaper models made building viable, faster development made it practical, and the repricing made the conversation urgent enough to reach the board.
What didn’t shift
Here is where most of the “build everything” enthusiasm goes wrong.
Eric Hawkins, CTO at Ontra, put it precisely: “The build vs. buy math changed. The maintenance math didn’t.” A capable engineer can scaffold in a few days what used to take a quarter, and then you still need operational teams, security patching, and someone who understands what the code does six months from now.
What AI commoditized was the act of producing software, not software itself. The competitive advantage moved from the ability to build toward the ability to own, operate, and evolve what you built.
Total cost of ownership for custom software still includes maintenance, security updates, compliance audits, onboarding new team members, handling edge cases the original builder didn’t anticipate, and the cognitive load of understanding code that was produced at AI speed. That last cost has a name now: comprehension debt. When nobody on the team can explain why a system works the way it does, because it was generated faster than institutional knowledge could form, you have traded vendor dependency for internal opacity.
The Retool report buried the most important finding in a secondary chart: of the teams that replaced SaaS with custom builds, 41% reported spending more engineering time on maintenance than they anticipated. The surprises were not exotic: security patching the vendor used to absorb, edge cases that only surface at scale, engineers joining after the initial build with no mental model of why the system works the way it does. If your organization lacks the governance discipline to maintain what it builds, cheaper to build turns into more expensive to own.
The new decision framework
The mistake is assuming AI changed every build-vs-buy decision equally. It didn’t. The disruption is real but uneven, and where a workload falls determines the answer.
A research paper from earlier this year, “The Buy-or-Build Decision, Revisited,” published on arXiv and now circulating in enterprise strategy circles, analyzed the market repricing thesis across enterprise software categories and found the same unevenness. Three groupings emerge, and they map cleanly to what I see in practice.
Commodity workloads are utilities where the vendor adds no differentiation: internal dashboards, notification pipelines, data transformation workflows, simple CRUD applications. These are the strongest build candidates in 2026. The SaaS vendor was always charging a margin for hosting and maintaining something your team could have built; the difference is that now your team actually can, in days instead of months. If the tool’s value is purely functional, moving data from A to B or sending alerts when thresholds cross, the build case is compelling.
Strategic workloads are the differentiating applications where competitive advantage lives: CRM customizations that encode your sales process, analytics pipelines that produce proprietary insights, customer-facing tools that define your product experience. These were always the strongest build cases in theory, and the problem was that building them took too long and cost too much. AI collapsed both constraints. This is where the repricing thesis holds hardest, because if your competitive edge lives inside a vendor’s platform, the vendor owns your differentiation. The economics now let you reclaim it.
Regulated workloads are the mission-critical systems carrying a high compliance burden: ERP, core banking, electronic health records, identity management. Evidence consistently points to these remaining predominantly in the buy domain, and not because building them is impossible. The compliance, certification, and audit infrastructure around these systems is a cost that doesn’t compress with AI. Regulatory requirements don’t get cheaper because your coding agent is faster, and the governance overhead of owning these systems often exceeds the licensing cost of buying them.
What most “build everything” advocates miss is that the categories aren’t fixed. A commodity dashboard acquires a compliance burden the moment it starts feeding a regulatory report, so the decision has to be revisited as a system’s role changes.
The governance prerequisite
AI also collapsed the experimentation cost. A team can now prototype internally in two to three weeks and compare the result against the SaaS alternative, turning “commit to build or commit to buy” into “test whether building this is viable, at low cost, before deciding.” But cheaper experiments only matter if you can evaluate what you built, and evaluating what you built requires the discipline to maintain it.
Here is where this argument connects to something I’ve been writing about for two years: the organizations positioned to benefit from the build-vs-buy shift are the ones with the governance muscle to maintain what they build. Cheap access to AI coding tools is close to universal by now, so it decides nothing.
The Bain PE story cuts both ways. The bidder walked away because the target’s product could be replicated, and that same bidder would have walked away from a company that built everything with AI and couldn’t explain how any of it worked. Defensibility now means being able to maintain it, extend it, secure it, and explain it under audit, which is a claim about the organization rather than about the code.
Teams without structured development discipline will build faster but own worse: comprehension debt accumulates, architecture reviews get skipped, and what worked in a demo fails under real load.
This is why I wrote in an earlier post that governance-ready organizations will adopt AI-driven development first. The same thesis applies to the build-vs-buy shift: the organizations with existing governance muscle (change management processes, architecture review practices, security-as-constraint discipline, structured quality gates) are the ones who can actually capture the value of cheaper building. Everyone else will build faster and regret it at the same speed.
What this means in practice
The audit comes first. Walk the current vendor portfolio and sort it: which tools are commodity utilities where the vendor adds nothing beyond hosting, which encode competitive differentiation the organization should own, and which carry compliance obligations that make ownership more expensive than licensing.
Then replace one commodity tool, not five. Prove the team can build it and maintain it, and measure total cost of ownership over six months rather than at the end of the initial build phase. If maintenance costs exceed the subscription it replaced, either the categorization was wrong or the team doesn’t yet have the discipline to own custom software.
The maintenance infrastructure should be in place before the building starts, and this is the part nobody puts on a slide: architecture review practices, code comprehension rituals, security scanning as a development constraint, documentation discipline, onboarding procedures for people who join after the build.
Buy also stays the right answer for a significant share of the portfolio. The goal is to stop defaulting in either direction: stop defaulting to buy for workloads where building is now cheaper and strategically superior, and stop defaulting to build for workloads where compliance and maintenance make ownership more expensive than the license.
Neither panic nor dismissal
The market anxiety of early 2026 produced wrong reactions in both directions. Some CTOs panicked and started replacing everything with custom builds, then discovered that cheaper building doesn’t mean cheaper owning. Others dismissed the shift entirely, insisting “SaaS is fine” while their teams quietly built shadow applications because the sanctioned tools were inadequate.
What the moment calls for is slower and less dramatic: a category-by-category reassessment of where build now beats buy, paired with an honest evaluation of whether your organization can own what it builds. The economics moved. Whether your methodology moved with them is the part you still control.
The advantage goes to organizations that know exactly what deserves to be owned.
Ricardo
