For twenty years, the smartest people I know have given the same advice on technology: don’t build it, buy it. It was good advice, and there was a reason for it that nobody said out loud very often. Choosing to build wasn’t really a cost decision. It was an act of quiet arrogance - the assumption that we knew enough about whatever it was to build it well, run it well, and support it well, indefinitely. Most organisations didn’t. And the real cost was never the build itself. It was what building badly did to our attention afterwards - the years spent nursing something we’d created instead of spending that same focus on the business it was meant to serve. Another version of the opportunity cost of automation: not what we built, but what we stopped doing in order to keep it alive.

Buy solved that. You traded a bit of personalisation for a lot of expertise, and a lot of restful nights.

I’ve been reading a piece this week arguing that CIOs need to reopen the build-versus-buy question, because the economics have shifted. AI has made building dramatically cheaper. The people who can build are no longer just the engineering team - they’re in operations, in finance, in marketing, producing working tools with tools that didn’t exist three years ago. It’s a good argument, and worth your time if you sit anywhere near a technology budget.

But I think the calculation it’s reopening is the wrong one.

AI hasn’t removed the old trade-off. It’s moved it. The mistake we used to make was assuming we knew enough to build something well. What’s changed is that you now need to know far less about a given problem to build a working version of it. The bar for “good enough to build” has fallen through the floor. The bar for “good enough that the difference doesn’t matter” hasn’t moved nearly as far.

You’ll have heard some version of the line going round at the moment - “software is no longer the moat”. There’s truth in it. Most features, most internal tools, most of the workflows we used to think needed a vendor, can now be recreated by a small team, or a single capable person, in a couple of weeks. I could build my own word processor in a couple of weeks too, with the right prompting and enough patience. It would technically work but it would not be Microsoft Word. And here’s the trap hiding inside that couple of weeks: I’d probably get 80% of the way there in the first few days. The easy part - the part GenAI has genuinely transformed - is fast now. But the remaining 20%, the edge cases, the polish, the thousand small decisions that separate “works” from “good,” still takes the same effort it always did. So the real risk isn’t that I can’t build a word processor. It’s that I build 80% of one quickly, mistake that for nearly finished, and then spend most of my time and goodwill discovering why the last fifth was always the hard part.

That’s the test. Not can we build it - we almost certainly can, now, at least most of the way there. But does the gap between our version and the best available version matter to the outcome we’re actually chasing? And, just as importantly: are we willing to own that gap, indefinitely, whichever way we decide to leave it?

Two questions, really, sitting underneath every build-versus-buy decision from here on.

Does excellence here actually move the needle? If this is the thing your customers or your people experience as the difference between you and everyone else, the gap matters enormously, and a merely-adequate AI-built version is the new version of the old mistake - just arrived at more cheaply. If it’s a commodity workflow that nobody will ever notice or care about, the gap is irrelevant.

And are we genuinely willing to own the consequence, not just the build? Cheaper construction doesn’t mean cheaper ownership. Someone still has to understand it when it breaks, maintain it as the business changes around it, and be accountable when it quietly stops doing what it was meant to do.

Put those two questions together and the decision mostly makes itself - and so does the harder discipline underneath it. Where the gap matters and you’re willing to own it, the honest next question is whether you actually have the expertise to close that last 20%, or whether you’re about to make the old mistake again, just later in the process - assuming effort is the same thing as competence. If you have the expertise, or you’re willing to go and properly acquire it, build, and finish the job. If you don’t, and you’re not prepared to get it, you haven’t really chosen to build - you’ve chosen to stop at 80% and call it done. Where the gap matters but you’re not willing to do either, buy, and be honest with yourself about why. Where the gap doesn’t matter, build the easy 80% if you enjoy it, but don’t mistake it for a strategic decision.

And the same lazy default is creeping one layer further down the stack. Most organisations now route nearly everything through a single frontier AI model, for the same reason they once routed everything through a single ERP vendor - it’s the path of least resistance. But a lot of what gets sent to the most expensive, most capable model in the world is routine: extraction, classification, a first pass at a summary. Work a smaller, cheaper, locally-run model could do perfectly well. Every task sent to the frontier model that didn’t need to be there is the same trade-off, one layer down - budget and attention spent on horsepower you didn’t need, instead of being available for the few things that genuinely do. More on that next week.

The economics of building have changed. Good. Use that. But don’t let cheaper construction be the reason you stop asking whether the building was worth putting up at all - and whether you’re still willing to be the one who looks after it once it’s standing.