For twenty years, the smartest advice in business technology was "never build, always buy."
I gave that advice myself. I gave it for most of the twenty-four years I spent as a CTO. It was right — and it just stopped being right.
That's an uncomfortable thing to say out loud, because "buy, don't build" wasn't a preference. It was arithmetic. And when the arithmetic changes underneath you, the advice you've repeated for two decades doesn't announce that it's expired. You just keep giving it, out of habit, long after it's wrong.
So let me make the case for the thing I spent most of my career warning people away from.
First, let me concede everything
Custom software earned its horror stories. I watched them happen.
The two-year build that shipped a year late and did half of what the spec promised. The budget that started at a number and ended at three times that number. The consultant who understood the whole system, and then left — and walked out the door with the only real copy of how any of it worked, living in his head. The application that ran fine until the one person who maintained it retired, and then nobody could touch it.
None of that is a strawman. I could name projects. If you've been in an operations-heavy business long enough, so could you. For a long time, "we're going to build our own" was a sentence that made experienced people wince, and they were right to wince.
I'm not here to tell you those failures didn't happen. I'm here to tell you why they happened — because the reason matters more than the wreckage.
Why "always buy" won
Writing software was expensive. Not incidentally expensive — overwhelmingly expensive. The build was something like 80% of the total cost of any system. Everything else was rounding.
When the expensive part of a thing is the building, the rational move is to build it once and share the cost across as many buyers as possible. That's SaaS. That's the whole idea. A vendor writes the software one time, spreads that enormous build cost across a thousand companies, and sells each of them a seat. Everybody pays a fraction of what it would cost to build alone. On paper, it's elegant.
But here's the part nobody put in the brochure. When you share the cost of the software, you also share the software. One product, built for a thousand companies, means one product built for the average of a thousand companies — which is to say, built for none of them exactly.
You didn't buy software that fit your business. You bought software that fit the middle of your industry, and then you bent your business to close the gap. Everybody did. We called it "best practices," which was a generous name for "the compromises the product forced on us."
What buying actually costs today
Walk any shop floor or any engineering office and ask to see the spreadsheet that actually runs the place. There's always one. Sometimes there are a dozen.
That spreadsheet exists because the real process — the one the business actually runs on — never fit the software you bought to run it. So the software handles the 70% it was built for, and the spreadsheet, the emailed form, the checklist in somebody's head, handles the part that makes your company your company.
Meanwhile you're paying for a thousand features to use twelve. You're paying per seat, every month, forever. And at the end of all of it — after ten years and a small fortune — you own nothing. Cancel the subscription and you're left with exactly what you started with: your data trapped in an export file and a process you have to rebuild somewhere else.
That was the deal. For twenty years it was the best available deal, because the alternative — building — cost too much to consider.
What changed
The expensive part got cheap.
AI has commoditized the actual work of making software — the designing, the building, the testing, the shipping. The part that used to take a team the better part of a year now takes weeks. I'm not speculating about a future here; this is how the work gets done now.
And notice what that does to the math. Every argument for "buy, don't build" was, underneath, a cost argument. Building is too expensive, so share the cost. When the cost of building collapses, the argument doesn't get weaker. It inverts. The reason to accept software that almost fits was that the alternative was unaffordable. The alternative is no longer unaffordable.
One thing this does not mean: less software. When something gets cheap to make, we don't make less of it — we make it for places it could never reach before. Cheap printing didn't end the written word; it put words on everything. The demand for software isn't going away. It's about to grow, because every workflow that was never worth building for is suddenly worth building for. What's changing isn't whether software gets built. It's how — and for whom.
What didn't change
This is the part I want to be careful about, because it's the part that separates a real answer from the hype.
AI made the building cheap. It did not make the judgment cheap, because judgment was never the expensive part on the invoice — it was the expensive part in the failures.
Go back to those horror stories. The two-year overrun, the blown budget, the knowledge that walked out the door. None of those were coding failures. Nobody's project died because the loops were written badly. They died because someone built the wrong thing, or built the right thing and had no plan to keep it alive, or built something that worked and let all the understanding of it live in one person's head.
Those are judgment failures and maintenance failures. And judgment and maintenance still require humans who've seen a few things go wrong. Knowing what to build — molding it to how a business actually runs, down to the words your people use for things — that's human work. Keeping it alive after the ERP updates and the integration you depended on quietly breaks — that's human work too.
So the old custom software failed for reasons AI doesn't touch. Which means the honest version of this argument isn't "AI builds your software now." It's "the expensive part got cheap, and the hard part is the part that was always hard." That's a much better position to be in than the one we were in for twenty years.
The new math, plainly
Put it together and it's not complicated.
Custom software now costs less than it used to — often less than the stack of subscriptions it replaces, because you stop paying for the 988 features you never used. It pays back faster, because it fits the work instead of forcing the work to bend around it. And the part almost nobody mentions: you own it.
That last one is worth sitting with. Cancel a SaaS subscription and you have nothing. Cancel a builder and you keep working software — the source, the documentation, the right to run it wherever you want. The relationship is a relationship, not a hostage situation. That's not a feature anybody could offer you when building cost 80% of the total. It's a feature you can demand now.
One I watched happen
A manufacturer I work with needed a system to run their work orders. Not exotic — work orders, the thing that literally moves product through the building.
They did it right. They evaluated the market. Every work order product they could find, demoed and scored against how their floor actually operated. And every one of them was close. None of them fit. Each would have meant reshaping the way the floor worked to match the assumptions the software's makers had baked in — and this was the floor, the part of the business you don't casually reshape to please a vendor.
So they'd been running it out of SharePoint, bent into a shape it was never meant to hold, plus the inevitable spreadsheet on the side.
The custom version took weeks. Not a year. It fit the floor, because it was built to fit the floor. The analyst who'd been running the old workaround told me the first working version felt like going from the stone age to the space age — which is the reaction you get when software finally fits. And when it was done, they owned it.
Five years ago I'd have told that company to keep shopping, keep bending, wait for a product to get close enough. It would have been good advice — then. It's the wrong advice now, and the thing that makes it wrong is the same thing that made "buy, don't build" right for twenty years: the arithmetic moved.
What's the workflow at your company that nothing off the shelf ever fit? I collect these.