Custom Software Didn't Die of Cost. It Died of Verification. That's Why It's Back.

A two-cycle witness on why bespoke software was career suicide for thirty years, why packaged software really won, and why AI has reopened the build-first era — from the opposite direction.

By Scott Farrell, LeverageAI

A good friend of mine — someone I've advised for years — once tried to build his own manufacturing system with custom software. He wasn't a developer. He couldn't lead the project. And he got totally ripped off. That's not a rare story; it's roughly what happens to most corporates that try the same thing. For about thirty years, building your own software was career suicide, and everyone knew it. You bought the package. You didn't build.

I want to argue that the reason that era died is not the reason most people think — and that getting the cause right is the whole game, because the exact thing that killed custom software is the exact thing AI just reversed.

I'm not theorising from the sidelines here. On my very first accounting job I turned up to books of paper and managers with pencils, and I typed it all into one terminal of an eight-terminal Unix accounting box. It was hilarious. A year or so later I led the charge onto spreadsheets, because doing it on a proper computer seemed more fun. Then I watched spreadsheets explode, then Visual Basic, then PC apps — a genuine build-first era, the last one we had. So when I say we're coming back around to custom software, I'm a two-cycle witness. I was in the room for the first one.

1. It died on verification, not on build cost

The standard story is that custom software was too expensive and too slow to build, so packaged software won on price and speed. That story is incomplete, and being incomplete is why it can't explain anything useful.

Custom software didn't lose on build cost alone. It lost on verification cost.

Go back to my friend and his manufacturing system. His problem was never that code was expensive. His problem was that he couldn't tell whether he was getting what he paid for. A non-developer commissioning custom software faces an unsolvable principal-agent problem: they can't inspect the work, can't tell a good developer from a confident one, and can't tell six months of progress from six months of invoices. Every status update is a claim they have no way to check. By the time the gap between the claim and the reality becomes visible, the money is gone.

That is not a cost failure. It's a trust failure. And it's structural — it doesn't matter how honest your developer is if you have no independent way to verify the honesty. The buyer in the middle is flying blind, and blind buyers get taken.

2. Packaged software won because it was a trust technology

Once you see the death as a verification problem, the winner makes sense in a way the cost story never quite manages. Packaged software won as a trust technology as much as an economic one. You could see the finished product before paying. You could run a demo. And ten thousand prior customers had already de-risked it — they had, collectively and at their own expense, done your verification for you.

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

The old line — nobody ever got fired for buying IBM, then SAP, then whichever incumbent — is usually read as a joke about corporate cowardice. It isn't. It's a precise description of how buyers manage verification risk when they can't verify. If you can't check the work yourself, you outsource the checking to the crowd. "Everyone else runs it" is the verification. The package didn't have to be the best tool; it only had to be the one whose correctness someone else had already paid to establish.

That's why "build it yourself" stayed radioactive for three decades. It wasn't that the building was impossible. It was that the checking was impossible for the person who most needed to do it.

3. The SaaS moat was verification in disguise

Fast-forward to the cloud era and the same mechanic hardens into a business model. The developer Theo Browne made a sharp version of the point recently, and I've been saying a variant of it for a while: SaaS vendors write thousands of features, and each feature is used by maybe 1% of customers — but everyone uses a different 1%. That looks like waste. It isn't. It's the moat.

Here's the irony worth sitting with. The switching cost was never the data export. Exporting a database has been easy forever. The switching cost was that re-specifying your particular 1% was prohibitively expensive — so you stayed. The thousands of features weren't bloat; they were the encoded requirements of ten thousand different businesses, and unpicking yours from the pile was the thing you couldn't afford to do.

Now run AI at it. Your existing configuration — the custom fields, the workflow rules, the reports, the integrations — is not technical debt. It's an executable record of what you actually need. My frameworks call this move sunk-cost-as-spec, and it's the heart of what I've written under the banner of the Platform Escape Path: your configuration is your specification. AI can read your 1% straight out of the configuration itself, and leave the 99% you never touched behind.

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.

That's value migration with a punchline. The moat's own artefacts are the extraction target. Which is exactly what I mean when I say AI is natively preferencing build-first: it says, in effect, "I'll harvest the spec for you, write it off your previous setup, and make everything custom."

4. The return is a spiral, not a circle

So we're coming back to custom software. But we are not going back to 1995. This matters, because if it were a circle — the same conditions coming round again — you'd be right to expect the same disaster my friend walked into.

AI's return of custom isn't a circle. It's a spiral — arriving at the same point from the opposite cause.

Two things changed together. The first is the obvious one: build cost collapsed. The "developer" now costs almost nothing to fire, iterates in hours instead of quarters, and can be run in as many parallel instances as you have tabs open. That's real, and it's most of the noise you hear about AI and coding.

The second change is the one that actually matters and almost nobody names: verification got restructured. In the old world, verifying custom software meant trusting a person you couldn't audit. In the new world, you verify behaviour with tests. In my Legacy Takeover work the trust model is a single sentence — you don't trust the AI, you trust the tests — and the mechanism is characterisation testing: you treat the running system as its own oracle, capture what it actually does for known inputs, and turn those input/output pairs into executable, falsifiable assertions. Pass or fail is binary. It isn't a matter of opinion, and it isn't a matter of reading code.

That characterisation harness is the thing my friend never had: a way for a non-developer to verify a system's behaviour without being able to inspect a single line of it. The buyer in the middle finally gets an independent instrument. The crowd of ten thousand prior customers — the thing packaged software rented you — gets replaced by a test suite you own and can read as a percentage climbing toward 100. Same job. Different technology. That's the spiral: the old failure mode isn't abolished, it's addressed differently.

5. The risk didn't vanish — it moved up the stack

Here's the honest flag, because a piece that skips it isn't worth reading. The ripoff risk did not disappear. It migrated up the stack, into the spec.

My friend would still fail today if he couldn't articulate what his manufacturing system was supposed to do. The difference is that now he'd fail cheaper and faster — a bad spec surfaces in a night of generation instead of a year of invoices — and that speed is genuinely most of the improvement. But the failure mode itself relocated. The gating skill moved from can you manage developers to can you specify what you want. You no longer need software engineers so much as you need people who can design what they want precisely enough that the software can materialise from it.

I feel this personally every day. I can do an almost unlimited amount of coding in a day — it writes, tests itself, debugs, drives a browser to check its own work — and the only thing that limits me is the ideas and the features I can think of. The bottleneck isn't execution anymore. It's goal formation, which I've argued elsewhere is now the scarce resource in the whole system. Every era's constraint climbed the stack — hardware, then developers, then licences, then integration — and it has finally arrived at intent. Which is also why the asset worth building is the one that makes intent cheap to express: a compounding record of what you've already decided you want.

6. A specimen: the Big Four engagement that was custom dev disguised as Excel

Let me make this concrete, because I watched it happen. On a recent consulting engagement — I won't name the firm, but it was one of the big four — I could not believe what the work actually was. Their entire delivery was pulling numbers out of the client's systems into Excel. And every meeting was about what the spreadsheets said: how to resync them, whether they were accurate, why last week's numbers didn't match this week's.

Look at what that is. They were doing custom software development — schemas, joins, versioning, a sync pipeline — but by calling it Excel they exempted it from every engineering discipline: no tests, no source control, no review, no spec. And they wouldn't call it software development, wouldn't run any proper process, because... no. No. It's Excel. It's the shadow-spreadsheet phenomenon, except performed by the people billed as the adults in the room, at partner rates.

Now look at what the meetings were. "How do we resync it, is it accurate?" — that is manual verification. Humans doing by hand, in a conference room, the exact checking a test harness does structurally and for free. They had rebuilt the era-1 verification problem inside a modern engagement and were hand-cranking their way through it week after week. It's a manual reporting factory, and it strands: the deliverable dies at the end of the engagement. Every insight assembled in those spreadsheets evaporates when the statement of work closes. It's the anti-Product-of-One — all of the custom-build cost, none of the compounding asset.

7. The precedent nobody credits: the spreadsheet never lost

There's a coda to this, and it runs right back through that 1990s accounting office. The spreadsheet I championed there never actually lost. It was, quietly, the most successful custom-software platform in history¹ — VisiCalc landing in 1979 as the first electronic spreadsheet and the software that sold the personal computer to business, then Lotus 1-2-3, then Excel. What all of them did was let end users materialise bespoke logic without developers. That's the whole trick.

It's also why corporate IT spent three decades trying to stamp out "shadow spreadsheets" and never could. The person with the problem kept building the tool anyway, because building it themselves was the only path that didn't route through a developer they couldn't verify. The spreadsheet was the one place ordinary people got to be build-first the entire time.

AI coding is the spreadsheet's vindication at general-software scope: the person with the problem builds the tool.

I backed that horse in 1990-something because it was more fun. It just took thirty years for the rest of the stack to agree with me.

Where this leaves the build-vs-buy call

If you take one thing from this, don't take "AI writes code fast." Take the causal version, because it tells you where to look. Custom-1.0 died because verification didn't scale. A non-developer couldn't check the work, so they bought the package that a crowd had already checked. Custom-2.0 runs on cheap generation plus test-based verification — and its ceiling, for everyone, is how fast they can want things precisely.

So when you weigh building versus buying now, stop pricing the build and start pricing the specification. The code is cheap and getting cheaper; the tests will tell you if it's right; the vendor's own configuration is your escape map. The scarce thing — the thing that will actually decide whether your custom build succeeds or ends up as another manual reporting factory — is whether you can say clearly enough what you want. The bespoke era is back. This time the hard part is you.

Scott Farrell writes on AI strategy, knowledge architecture, and the economics of building versus buying software at LeverageAI. If you're weighing a build-vs-buy decision, the question to sit with isn't "can we build it?" — it's "can we specify it?"