Don't Buy Software, Build AI Instead: Cheap Code Was Never the Argument

The build-vs-buy case has aged in both directions. Construction cost was never the binding constraint — verification was — and that changes which software you should still be renting.

Scott Farrell · LeverageAI · Second edition, July 2026

The slogan went mainstream. The reasoning didn't.

In December 2025, Andrej Karpathy posted that he had never felt this far behind as a programmer, that he had "a sense that I could be 10X more powerful if I just properly string together what has become available over the last ~year," and that failing to claim the boost "feels decidedly like skill issue."¹¹ Theo Browne, running production teams, put numbers on the same shift: roughly 90% of his own code AI-generated, at least 70% across the teams he runs.¹²

Six months later, the organisational conclusion everyone drew from that has stopped being a forecast. In Retool's February 2026 survey of 817 builders, 35% had already replaced at least one SaaS tool with something they built themselves, 78% expected to build more in 2026, and 60% had shipped something outside IT oversight in the preceding year.¹ That is a build-inclined sample — Retool sells a build tool — so read it as evidence of direction among people equipped to act, not as a population rate. Directionally, it is unambiguous.

Meanwhile the other side of the ledger got worse in ways with dates attached. SaaS pricing rose about 11.4% year on year against 2.7% average G7 inflation.³ In a 2026 survey of IT leaders, 79% met a price increase at renewal, 78% met unexpected charges tied to consumption or AI features, and 61% cut projects because of unplanned SaaS cost increases.⁴ Gartner has software as the fastest-growing IT segment of 2026, up 15.1%.⁵ Software is supposedly becoming free, and the software line keeps going up.

So the conclusion is right. Building more of your own software is now rational for a widening class of work. Here is my problem with that: the reasoning underneath it is wrong, and a right answer held for a wrong reason fails silently at the boundary. It will tell you to build things you have no way to verify, and to keep paying for things whose only remaining value was verification you can now produce yourself.

It died of verification, not cost

The standard story is that custom software was too slow and too expensive, so packaged software won on price and speed. That story cannot explain the thirty years it is meant to describe.

A friend of mine tried to build his own manufacturing system. He was not a developer. He could not lead the project. He got comprehensively ripped off — which is roughly what happened to most organisations that tried the same thing. His problem was never that code was expensive. His problem was that he could not tell whether he was getting what he paid for. Every status update was a claim he had no way to check; by the time the gap between the claim and the reality was visible, the money was gone.

That is not a cost failure. It is a trust failure, and a structural one: it does not matter how honest your developer is if you have no independent way to verify the honesty.

Which makes the winner legible in a way the cost story never manages. Packaged software won as a trust technology. You could see the product before paying. Ten thousand prior customers had already de-risked it — they had done your verification, collectively, at their own expense.

"Nobody got fired for buying SAP" was never about SAP being good. It was about the buyer's inability to verify anything else.

Read that way, the old line stops being a joke about corporate cowardice and becomes a precise description of how buyers manage risk when they cannot inspect. If you cannot check the work yourself, you outsource the checking to the crowd. "Everyone else runs it" is the verification.

There is one more piece of evidence, and it is the one that settles the argument. Custom software supposedly died for thirty years — during which the most widely used custom-software platform in history was flourishing in every office in the world. VisiCalc, Lotus 1-2-3, Excel. Corporate IT spent three decades trying to stamp out shadow spreadsheets and never could, because the person with the problem kept building the tool anyway. The spreadsheet was the one place ordinary people got to be build-first the entire time — precisely because it was the one path that did not route through a developer they could not verify. Only the verification story explains both facts at once.

A subscription contains four products. AI repriced one of them.

Once you see the death as a verification problem, the buy side decomposes. What you are actually paying a platform vendor for is at least four separable things:

This is why "anything you're paying for, replace it with your own software" is a good provocation and a bad rule. Auth, payments, messaging, CDN and storage stay bought — not because their code is hard, but because the value is operational muscle you would have to build a company to replicate. That is Tier 1, and it is not moving.

The flip zone is the middle: horizontal platforms — CRM, ITSM, HCM, ERP, marketing automation — and industry verticals, which promise specificity and deliver an average. The vendor optimises for their 80th-percentile customer; everything that makes you distinctive is, by definition, customisation work. In that zone the licence fee is the small number. HFS Research's November 2025 study of 123 Global-2000-scale organisations found enterprises spend two to seven times licence cost on implementation and integration, with average code reuse of just 33% — teams rebuild about two-thirds of the functionality anyway.²

The first edition of this argument had a table of dollar figures here. Every number in it was invented. I have replaced them with the one sourced magnitude I can defend, because the shape is the point: for configured platforms, the subscription is not the cost.

The instrument: where does the customisation dollar get leverage?

The old question was "is it cheaper to build or buy?" That question is now aimed at the wrong variable. The better one, which I have written about at length elsewhere as the Leverage Test, is: where does your customisation dollar get AI leverage?

Money spent configuring a proprietary platform gets almost none. It lives in closed configuration languages that agents can barely touch, cannot be refactored, cannot be tested, cannot be meaningfully version-controlled, and — this is the part people miss — gains nothing from model improvements. Money spent on spec-driven code gets most of the leverage available, compounds, and treats every model release as a free upgrade. Same dollar, wildly different trajectory.

That asymmetry also explains the debt problem. Platform configuration debt and codebase debt both compound. Only one has fifty years of engineering discipline attached to it. Configuration has the complexity of software with none of the tooling: no refactoring, no automated tests, no diffable history, and no specification to regenerate from. Its five-year trajectory is archaeology — "we can't touch that, no one knows what it does" — and its seven-year trajectory is ossification. A codebase with a spec and a test harness has the opposite trajectory: it can get cleaner at year five, because regeneration keeps getting cheaper.

Your configuration is your exit specification

Here is the part that inverts the usual lock-in conversation, and the place where my first edition was not wrong so much as too timid. I filed vendor lock-in under costs. It belongs under assets.

SaaS vendors write thousands of features. Each feature is used by a small fraction of customers — but everyone uses a different fraction. That looks like bloat. It is the moat. And the switching cost was never the data export; exporting a database has been easy forever. The switching cost was that re-specifying your particular slice was prohibitively expensive, so you stayed.

Now run an agent at it. Your custom fields are data requirements. Your workflow rules are business rules. Your reports are output specifications. Your integrations are interface contracts. Your validation rules are the constraints that are hardest to discover and are already written down. That configuration is not technical debt; it is an executable record of what you actually need, and AI is extremely good at exactly this kind of structure-to-structure translation.

The vendor spent twenty years encoding every customer's requirements into their platform — and it turns out they were maintaining everyone's exit specification, at their own expense.

Two honest caveats. First, the configuration does not contain everything: the workarounds, the "we always do it this way", the tribal knowledge in the head of the admin who is one resignation from being a single point of failure. Capture that by interview and observation before you touch anything. Second, extraction is worth doing even if you decide to keep buying. A costed, credible build alternative is the only thing that has ever changed a renewal conversation. The analysis pays for itself before the decision is made.

The harness — and the two things it does not cover

So what replaced the crowd of ten thousand prior customers? A test suite you own and can read as a percentage climbing toward 100.

The mechanism is characterisation testing: treat the running system — including the platform you are leaving — as its own oracle. Capture what it actually does for known inputs. Turn those input/output pairs into executable, falsifiable assertions. Pass or fail is binary. It is not a matter of opinion and it is not a matter of reading code. That is the instrument my friend never had: a way for a non-developer to verify a system's behaviour without inspecting a single line of it. You don't trust the AI. You trust the tests.

This is why the return of custom software is a spiral rather than a circle. Two things changed together — build cost collapsed and verification restructured — and only the second one explains why the outcome should be different this time.

Now the limits, at full strength, because a piece that skips them is not worth reading.

A behavioural harness proves behaviour. It does not prove safety. Veracode's March 2026 longitudinal study across more than 150 models found that only about 55% of generation tasks produce secure code, and that this rate has stayed essentially flat between 45% and 55% since 2023 — while syntax correctness climbed past 95%.⁶ Recent flagship releases produced no statistically significant improvement. Your characterisation tests will pass happily on an injectable query. Security needs its own gate, and it does not arrive with the model.

A harness does not stop debt accumulating. A large-scale April 2026 study of 302,600 verified AI-authored commits across 6,299 repositories found 484,366 distinct issues introduced, more than 15% of commits from every assistant carrying at least one, and — the number that should govern your maintenance planning — 22.7% of tracked AI-introduced issues still alive at the repository's latest version, with the cumulative surviving count passing 100,000 by February 2026.⁷ Cheap generation produces volume, and volume produces residue.

Which is exactly why the durable asset cannot be the code. Keep the specification, the acceptance tests, the context and the decisions that cannot be safely re-inferred; treat the generated implementation as regenerable output. Otherwise you have not escaped a vendor's maintenance liability. You have taken it in-house and put your own name on it.

What I got wrong in January

The first edition of this piece reached the right conclusion by the wrong route. Five corrections, in the open.

The decision sheet

Run this on one platform, not on your portfolio. The portfolio version is a strategy offsite; the single-platform version is a decision.

The last thing worth saying is the thing that has aged best. The risk did not disappear when code got cheap; it migrated up the stack, into the specification. My friend would still fail today if he could not articulate what his manufacturing system was supposed to do — he would just fail in a night instead of a year, which is genuinely most of the improvement. Every era's binding constraint has climbed: hardware, then developers, then licences, then integration. It has finally arrived at intent.

So stop pricing the build. Price the specification and the proof. The bespoke era is back, and this time the hard part is you.

If you are weighing a build-versus-buy call, the question to sit with isn't "can we build it?" It's "can we specify it, and can we prove it?" LeverageAI works with mid-market organisations on exactly that decision — including the analysis that ends with "keep buying, and here is the costed alternative that changes your renewal."