The full paper is on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6617321. A companion paper on near-term labor-displacement forecasts is in preparation.

In the first week of February 2026 the market lost more than a trillion dollars in enterprise software stocks, three hundred billion of it on February 4 alone. The narrative was that AI was about to replace Software-as-a-Service. Conviction was high and PowerPoint was abundant. The promised savior was an in-house software build, done with AI by a small clever team, for less than the SaaS vendor's invoice.

I am sympathetic to the people who sold their stock that week. I am less sympathetic to the people who told them to. The selloff was a bet on the oldest decision in enterprise software, build-versus-buy, with a fresh thumb on the build side because AI looked like it had made building easier. In a paper I posted to SSRN this week, I argue that AI does not meaningfully change the math of build-versus-buy. The apparent speed of the initial AI build does, however, force the enterprise that tries it to itemize a SaaS bundle the subscription had been quietly carrying.

The argument is correct, in roughly the way a casino is generous

That narrative, simplified, runs as follows: SaaS vendors charge a lot of money because building software is hard, AI makes building software easier, therefore enterprises will build their own software with AI and stop paying SaaS vendors. Q.E.D., short the software ETF.

Each step is correct, in roughly the way a casino is correct that any individual game is winnable. The conclusion is a separate leap, carried mostly by the vibe that building has become easier.

The build is a different buy

Put plainly, AI in current delivery form is itself SaaS. It is delivered by a vendor, priced on consumption, run on the vendor's infrastructure, and governed by contracts that, when you read them, turn out to be structurally weaker on liability, compliance, and indemnification than the SaaS contracts an enterprise already holds. The build, in other words, is a different buy.

There are three plausible build paths an enterprise can take in this horizon, and all three tend to land back at SaaS. Direct API access is consumption-priced SaaS with weaker contracts than the SaaS it replaces. Code written with AI coding tools creates a maintenance dependency on those tools, which are themselves SaaS. Open-weight model deployment at enterprise throughput typically uses managed hosting on a cloud provider's AI platform or a specialist open-weight host, which restores the SaaS pattern with the enterprise choosing the model. The escape routes from buy mostly lead back to a different buy.

All three build paths transfer the bundle from the SaaS vendor to the enterprise.

Five line items not on the API token invoice

The build-versus-buy comparison treats each of these as negligible.

Liability for bad output. SaaS contracts negotiate which bad outputs the vendor covers. AI vendor contracts disclaim output warranties and cap liability at fees paid; a bad answer that costs money is the enterprise's problem.

Compliance generation. A SaaS vendor's SOC 2 covers a fixed application the enterprise can largely inherit. An AI-built application is generated, so the attestations are generated alongside it, by the enterprise, on its calendar.

Single-tenant cost concentration. SaaS pricing amortizes engineering cost across the vendor's full customer base. Direct AI consumption is single-tenant: engineering, hosting, and maintenance fall entirely on the enterprise.

The expertise-and-maintenance loop. A SaaS vendor employs the engineers who understand the product. An in-house AI application concentrates that knowledge in two to five engineers, on a maintenance loop that runs on AI tooling that is itself SaaS.

Integration and data responsibility. The SaaS vendor owns the data model, schema migrations, and the ongoing job of keeping behavior consistent. An AI application built on the enterprise's data inherits its data quality, including the parts nobody has cleaned up.

Spending four thousand dollars to avoid spending ninety-nine a month

Two weeks ago I built SKIFF and saved myself a bundle. The $4,115 inference bill (API-equivalent; I pay through an AI subscription) spared me a ninety-nine-dollar-a-month container-management subscription that would have covered a license for a small company.

On the first turn the AI estimated ten minutes and a hundred lines of code. Six calendar days of half-attention work later: 69,000 lines, 484 rounds of me asking it to fix what it had just confidently produced, still incomplete. Roughly 100x on time, 700x on code, completion pending; I would say the AI lied, but I think it genuinely believed itself, which is worse.

The $4,115 is inference only, already 3.5 years of the SaaS subscription, and excludes my labor; in my own lab the labor was free, but it would not be at an employer's.

None of this is new. The road to hell is paved with good intentions; in software, with thousands of lines of code nobody looks at again until something breaks. The hard part of software has rarely been the writing. It has been the maintenance, the security posture, and the long quiet years of keeping the thing alive. AI makes the writing closer to free; the rest of the work stays exactly where it was. What the SaaS subscription was actually selling, it turns out, was headache-removal at ninety-nine dollars a month. I paid four thousand to keep the headache, plus the software as a bonus.

The bundle, now visible

For the 2026 to 2030 procurement horizon, the enterprise that swaps a mature SaaS application for an internal AI build is unlikely to save money. It gets a clearer view of what the SaaS bundle was carrying. AI raises the value of SaaS by making visible the work the vendor was quietly absorbing.

AI will mostly sit alongside the SaaS application and handle the parts SaaS is weakest at: drafting, summarizing, translating between systems, automating the hand-typing. The SaaS vendor will charge for it, because the vendor is doing it on the enterprise's behalf and carrying the asymmetries. Or the enterprise can build it, and run the same experiment I just did at whatever scale they prefer.

Links