20 min read

The year software got cheap to build and expensive to own

Posted on November 26, 2025 · Updated August 14, 2026

In early February 2026, a trader at Jefferies watching enterprise software stocks come apart wrote the word SaaSpocalypse into a client note, and it stuck. The selling was, in his description, get-me-out selling, the kind of language nobody had used about software since 2008. Roughly $285 billion evaporated from software valuations inside forty-eight hours. Thomson Reuters had its worst single day on record. LegalZoom fell a fifth. By late March the main software ETF was down more than twenty percent for the year, and price-to-sales multiples had compressed from around nine times to six, levels last seen in the mid-2010s.

The trigger was a demo. Anthropic had shipped an agent product that could run multi-step work across the tools enterprises pay per-seat for. A journalist built a kanban board with it in under ten minutes and posted the video. Monday.com lost a few hundred million in market cap before the session closed. The market had worked something out: if one person with an agent does the work of five, you don't need five seats.

That's the story everyone covered.

Here's the one almost nobody did. Around the same weeks, in a lab at Georgia Tech, a graduate researcher named Hanqing Zhao was watching a different number climb. His team had built something called the Vibe Security Radar. It takes public vulnerability databases, finds the commit that fixed each flaw, walks back through the history, and checks whether an AI coding tool put the bug there. Across the second half of 2025 it found about eighteen cases in seven months. Then January 2026 produced six. February, fifteen. March alone produced thirty-five, more than all of 2025 combined.

Two counters, running in opposite directions, measuring the same event from opposite ends.

One was pricing how cheap software had become to make. The other was measuring what it costs to own once you've made it that way. Both bills land on the same balance sheet, roughly a year and a half apart, and only one of them has been priced.

That gap is the entire build-or-buy question now. Everything else is noise.

What actually got cheap: the first version, and almost nothing after it

The productivity claims from 2026 are close to useless because they average two completely different things together. Split them and the picture resolves immediately. AI is worth something like a third to a half on green-field work: the blank file, the first version, the prototype. On complex changes to code that already exists, it's worth ten percent or less. That's Stanford's productivity research, cited in Google Cloud's DORA work in January 2026, and it is the most decision-relevant finding of the year. It gets almost no airtime because it's less fun than the stories about ten-times engineers.

Sit with what that means for a build decision. Every build you're weighing is a bet about year three, and year three is made entirely of complex changes to code that already exists. The discount applies to the part you were never really paying for, and it expires exactly when the invoice arrives.

There's a reason for this that has nothing to do with model quality. A model satisfies a prompt, and satisfying a prompt means producing something that works now, the cheapest route to which is writing fresh code rather than understanding and extending what's already there. That isn't a flaw you can prompt around. It's the objective, working correctly.

The consequence is measurable, and it's more specific than "AI writes bad code." GitClear has tracked 623 million real code changes since 2023, and the habit that collapsed is tidying up. Developers used to clean as they went: moving code into the right place, folding new work into what already existed, deleting a duplicate instead of leaving two. That kind of edit was about a fifth of all changes in 2022. It's under four percent now. Duplication has climbed every year over the same period, and edits that touch anything written more than a year ago have fallen by three quarters.

Read that last one slowly, because it's the one with teeth. Old code is increasingly not being revisited at all. Codebases grow outward in fresh, self-contained, never-reopened layers while the strata underneath quietly calcify. GitClear's own framing is that the risk isn't AI writing code your team can't maintain, it's AI writing that code faster than ever, and, in their words, "the bill arrives when you can least afford it."

None of this argues against building. We build software for a living and we'd tell you what we tell clients: the prototype is nearly free now and you should go take advantage of that. It argues against one specific and very common mistake, which is reading a discount on version one as a discount on the product.

Build doesn't mean build it yourself: it means paying for software shaped to your problem

“

A purchased tool has to serve thousands of customers, so it optimises for the average case, and the average case is nobody's actual case.

The word "build" got quietly hijacked in 2026, and it's distorting the decision. Build versus buy is custom versus off-the-shelf. It is not amateur versus professional, and it never was. Commissioning a team to build something specific to how you operate is a build. Hiring one engineer to own an internal system is a build. Prompting an app into existence over a weekend is also a build, and it is the least common of the three in any organisation that has to keep the result running.

The survey data says so plainly. In Retool's poll of 817 builders in late 2025, only thirty-one percent were prompting their way to complete applications. Seventy-two percent used AI to write pieces of code they then integrated themselves. Eight percent shipped AI output without changes. Read those numbers knowing Retool sells the platform and polled its own customers; they're worth having anyway, because the interesting findings cut against the commercial interest. Pierre Yves Calloc'h at Pernod Ricard put the boundary about as bluntly as it can be put: "There's no way you can go live with a vibe-coded solution." It works for demos. It does not hold across thirty countries.

What actually changed is the price of commissioned custom software, and it changed enough to move the line. Specification that used to take weeks of workshops now takes days of structured conversation. Iteration that used to take a sprint takes an afternoon. The first working version arrives early enough to be wrong cheaply, which is the whole point of showing it to people. None of that requires anyone to prompt their way to production. It requires the same professional delivery it always did, applied to a much shorter runway.

So the threshold keeps sliding. Categories that were obviously buy three years ago are marginal now: the internal admin tool, the operations workflow, the reporting layer nobody could get a vendor to shape correctly. Retool's respondents named exactly those as the first things they replaced, and the reason is always the same. A purchased tool has to serve thousands of customers, so it optimises for the average case, and the average case is nobody's actual case.

But there is still a cutover, and finding it is the whole skill. Custom stops paying for itself the moment the thing you want is genuinely identical to what everyone else wants, or the moment nobody in your organisation can say precisely what correct behaviour looks like, or the moment you can't name the person who'll still be answering for it in year three. Below that line, custom is now an unusually good deal. Above it, you are buying a rewrite on an unknown date and calling it independence.

The winners weren't the people who could code, they were the people who could specify

“

The old question was: can we build this? The new one is: can we describe this precisely enough that building it becomes the easy part?

The popular version of 2026 is that AI democratised software, the barrier fell, and now anyone can build. The data underneath says something less flattering and considerably more useful. Look at who was actually getting the gains. Heavy AI users out-produce non-users by four to ten times, which is the number that gets quoted. The part that doesn't get quoted, which GitClear found by comparing people against their own history, is that most of that gap predated AI entirely. Against their own past selves, heavy AI users gained about twenty-five percent. The tools didn't create the top performers. They found them, and handed them a multiplier.

What became scarce is the ability to say precisely what you want. That skill used to live inside engineering because it had to. You couldn't specify a system without the vocabulary to build one. AI severed those two things, and organisations are discovering they had far fewer people who could do the first than they thought, because the second had been hiding it.

This is the reframe worth taking from the whole year. The old question was can we build this? The current one is can we describe this precisely enough that building it becomes the easy part? Those are different capabilities, they have shared a department for forty years, and they have now come apart.

The same logic is playing out on the vendor side, which is the tell that it's real. Generic horizontal tools got repriced brutally. What grew was vertical: software encoding real operational knowledge about one industry, trained on data nobody else has. ICONIQ's survey of software executives found forty-three percent building vertical applications against twenty percent horizontal. The defensible thing stopped being the software and became the specificity, which is the same finding pointed at sellers instead of buyers.

Month nine is where the bill lands: rescue engineering became a job category in under two years

A job category now exists that didn't exist eighteen months earlier: rescue engineering. Teams that specialise in taking an AI-built application which has stopped behaving predictably and rebuilding the parts nobody can trust. "Vibe-coded debt" appears in job descriptions.

Be careful with the numbers attached to this. The commonly-cited figures, thousands of startups needing rebuilds and rescue engagements running from fifty thousand to half a million dollars, come from vendor-adjacent trackers piecing together support tickets and forum posts rather than audited research. We wouldn't put weight on the magnitude. The existence of the category is the finding, and that isn't in dispute.

What is well documented is what these systems look like when somebody opens them. Security researchers scanning AI-built applications running in production keep finding the same failures: no CSRF protection, no security headers, server-side request forgery, credentials sitting in the frontend. Escape.tech's scan of over 1,400 production applications found roughly two-thirds carrying security issues and fifty-eight percent with at least one critical vulnerability, including hundreds of exposed secrets and instances of exposed personal data.

The clearest single case is Moltbook. Its founder launched in late January 2026 and said publicly that he hadn't written a line of code. Within seventy-two hours, researchers at Wiz reported the production database was exposed: 1.5 million API tokens, 35,000 email addresses, private messages. The cause was a misconfigured database deployment. Not an exotic attack. A default nobody knew to change.

Zhao's point at Georgia Tech is sharper than any individual breach. Because millions of developers use a handful of models, the same defect pattern appears across unrelated codebases: find it once, scan for it everywhere. AI-generated vulnerabilities are correlated in a way hand-written ones never were, which has changed the economics of attacking software and has not yet changed the economics of defending it.

And the fix is not the next model, which is the part the industry keeps refusing to absorb. Veracode has tested more than a hundred models on security-sensitive tasks, and the pass rate has sat flat at roughly fifty-five percent from 2025 into early 2026, across a period when coding benchmarks improved steadily and syntax correctness climbed above ninety-five percent. Larger models did not do better. Two years of capability gains moved functional quality a great deal and security essentially not at all.

Our own small piece of first-hand evidence points the same way, and it's more instructive precisely because nothing went wrong in the dramatic sense. In February 2026 we specified a product with no interface at all, twenty-one tools, no dashboard, in about eight hours of thinking and fewer than ten messages; our delivery pipeline built it in two to three days. It worked. Six months later we graded the fifteen design principles we'd written against the world as it then stood. Nine held. Three had gone wrong, because the underlying protocol shipped a breaking revision that removed the handshake, removed sessions, and deprecated the authentication mechanism we'd assumed.

Which three broke is the useful part. Not the principles about schema design, error handling, or shaping data a model has to read, those held, and two turned out to be more right than we'd written them. What broke was transport, sessions and auth: every one coupled to a standard somebody else controls, on a schedule we had no say in.

That's one build and a small sample, but it isolates something the industry data can't. Decay isn't uniform. Your own architectural thinking keeps its value, and anything welded to another party's roadmap has a half-life you don't get told. The uncomfortable follow-on is that this is equally true of software you buy. Vendors deprecate, APIs break, products get acquired and sunset. Buying doesn't remove that exposure. It changes who takes the phone call, and whether you find out on their schedule or yours.

The dangerous build isn't the one you approved: it's the one nobody knows exists

“

The build-versus-buy debate is being run as a procurement question when it has already become a governance one.

Two of the year's biggest datasets collide here, and most executives are looking in the wrong direction. Start with the builders. Sixty percent of Retool's respondents had made something outside IT oversight in the preceding twelve months, and a quarter did it regularly. These weren't juniors freelancing; most were senior managers or above. Their reasons were entirely reasonable. They could build faster than IT, existing tools didn't do the job, procurement was too slow.

Now set that against IBM's breach research covering 602 organisations breached between March 2025 and February 2026. The share of security incidents involving shadow AI more than doubled in a year, from twenty percent to forty-three percent. Those breaches averaged $5.39 million against a global average of $4.99 million, and roughly one in five drew a regulatory fine. Among organisations hit by an AI-related breach, ninety-two percent had no proper access controls on the AI systems involved. Fewer than a third of organisations run any regular audit for unsanctioned AI at all.

So the picture is a large population of capable, senior, well-intentioned people building useful software outside any review process, inside organisations that mostly cannot see it, during a year when incidents involving exactly that class of system doubled.

The build-versus-buy debate is being run as a procurement question when it has already become a governance one. Your exposure is not the system engineering scoped, reviewed and deployed. It's the thing your best operations manager shipped in March because the sanctioned path took six weeks, which now holds a production credential nobody has inventoried, and which she'll stop maintaining when she changes roles in November.

Which means the first move for most organisations isn't a decision at all. It's an inventory. Expense reports for unbudgeted AI subscriptions, single sign-on logs, network egress: those will tell you more in an afternoon than a policy memo will in a year. You cannot govern what you don't know exists, and you certainly cannot make a rational build-or-buy call while a third of your estate is invisible.

There's a version of this that ends well, and it isn't a crackdown. Shadow building is a signal that procurement is slower than the business, and the organisations handling it properly are shortening the sanctioned path rather than lengthening the punishment, pulling the good unsanctioned tools into a governed environment instead of killing them.

The Cyber Resilience Act quietly re-prices this, and it favours internal builds over bought ones

The EU Cyber Resilience Act's reporting obligations take effect on 11 September 2026, and they move this decision in a direction that runs backwards from what most people assume. From that date, anyone placing a product with digital elements on the EU market must report actively exploited vulnerabilities within twenty-four hours, with a fuller notification at seventy-two. It applies to products already on the market, not just new releases. Penalties reach fifteen million euros or 2.5 percent of worldwide turnover. The heavier obligations arrive on 11 December 2027: secure-by-design, conformity assessment, software bills of materials. The Commission published eighty-three pages of guidance in July 2026, which tells you how much interpretive room there is.

Here's the part relevant to this argument. Software you build purely for internal use is out of scope. It was never placed on the market, so you aren't a manufacturer and no new obligation attaches. The standard worked example is an insurer's internal claims system. Build your own internal admin tool and you've created nothing a regulator wants. Buy one and you've made yourself dependent on a vendor whose reporting discipline you can't inspect and won't learn about until it fails.

Reverse it and the sign flips hard. The moment what you built goes to customers, or gets embedded in something you sell, a serious regulatory obligation moves off your vendor's balance sheet and onto yours. That is a real, quantifiable cost of building, and we haven't seen it appear in anyone's build-or-buy analysis.

The decision has therefore split in two while most people still treat it as one. Internal builds got cheaper in regulatory terms. Customer-facing builds got materially more expensive. We're not lawyers and none of this is legal advice; scope questions here turn on specifics, which is exactly why the guidance runs to eighty-three pages.

So build or buy? Build what encodes how you operate, buy what everyone needs identically

Both, obviously. But the line moved, and it is no longer where the cost models put it.

Build what encodes how you actually operate. If the workflow is a reason customers choose you, generic software was always a bad fit, and commissioning something specific has become affordable at a scale of company that couldn't consider it three years ago. This is the real opportunity of the year and it's larger than it was in 2024.

Buy what everyone needs identically. Payroll, accounting, email. Nobody has ever won a customer with a bespoke general ledger. Buy it and then negotiate hard, because vendors are pushing renewal uplifts of twenty to thirty-seven percent against a historical norm of three to nine, and roughly half of that comes off if you push. Then never think about it again.

And be honest about the third category, which is where the money actually gets lost: the thing that's important, that nobody can specify, that someone will build anyway. That's the profile behind almost every expensive failure we watched in 2026. Strategic enough to justify pushing through, vague enough that nobody can say what correct means, cheap enough now that it gets built before anyone notices the specification was never written.

Which brings it to one test worth applying before anything else. Not can we build this. You can; that question is settled and the answer is yes. Ask instead: can someone in this organisation write down what correct behaviour looks like, including the edge cases, inside a week? If yes, build it and you'll be glad you did, whether your own team writes it or you pay someone to. If no, buying at least gives you somebody else's opinion about what correct means, which is worse than having your own and far better than having none.

Our bet, and it's a bet: within two years the interesting split stops being build versus buy and becomes specified versus unspecified. A tool you bought that nobody scoped against a real workflow and a tool you commissioned that nobody wrote a data model for fail the same way on roughly the same timeline. The only difference is whether there's someone to call.

We'd happily be shown wrong. If models get good enough at inferring intent that precise specification stops being scarce, this argument collapses and the answer becomes build nearly everything. Veracode's flat security pass rate is the leading indicator to watch, if that moves sharply while functional benchmarks stay put, something real has changed. We don't think it's close.

The last thing worth saying is what the February selloff got right and the coverage got wrong. The market repriced software because making it got cheap, and it got that half correct. What it hasn't priced, and what Zhao's counter in Atlanta has been measuring all year, is that owning software never got cheaper at all, and that bill runs about eighteen months behind the discount, moving steadily in the other direction.