Every few weeks somebody asks me whether they should build their AI capability in-house or buy it from a vendor. I always answer, because it's a fair question, but I've come to think it's the wrong shape. Build-versus-buy gets framed as a two-way choice mainly because two-way choices fit on a slide and go to a vote cleanly. There are three doors. The third one is "wait," and in my experience it is simultaneously the cheapest option available and the one almost nobody picks, because nobody has ever been promoted for recommending it.
Let me take them in order, since the reasoning is different in each case.
Buying, and actually meaning it
Buy when the problem you have is a problem thousands of other companies also have. Transcription. Document extraction. Support ticket routing. Meeting summaries. There is no strategic advantage waiting for you at the end of building your own transcription service, and a vendor who does nothing else will be better at it than you within a quarter.
The failure mode here isn't buying. It's buying and then refusing to accept what you bought. A team purchases a platform, discovers it does the job 80% the way they'd like, and then spends fourteen months and a small fortune customising the remaining 20% until they've built a bespoke system they can't upgrade, can't support, and don't own the source code to. You've now paid the full cost of building plus a licence fee. If a product doesn't fit your process, the honest options are to change your process or to walk away, and changing the process is usually right and always unpopular.
Three questions I'd want answered before signing anything. Where does our data go, and can we get it back in a usable form if we leave? Which model is under the hood, and what happens the day you swap it for a cheaper one without telling us? And what does the price look like at ten times our current volume — not because we'll get there, but because I want to see whether the pricing was designed by someone who thought about it.
Building, with your eyes open
Building is right when the thing is genuinely yours — when it runs on data nobody else has, encodes judgement specific to your business, or is the actual product you sell. Fair enough. But be clear about what you're signing up for, because the initial build is the smallest line item in the whole undertaking.
What you're really committing to is a second year. The retraining pipeline when the data drifts. The evaluation harness that tells you whether last week's change made things better or quietly worse. The monitoring, the on-call rota, the runbook. The awkward Tuesday when the one engineer who understood the whole thing hands in their notice and you discover the design lived entirely in their head. I've seen more AI systems die of maintenance neglect than of bad modelling. The first version is a sprint; everything after it is a standing cost, and it doesn't stop.
So the test isn't "can we build this." Almost any competent team can build a first version now; the tooling is extraordinary. The test is whether you're prepared to fund it in year three, when it's boring and works and nobody's excited about it any more.
The third door
Wait when the problem is real but the ground is moving faster than your procurement process. This is more common than people admit. If a category of capability is getting roughly twice as good and half as expensive every year or so, a three-year contract signed today locks you to today's economics for the entire period in which those economics are going to change most. Sometimes the correct move is to sit still for six months and buy the thing that doesn't exist yet, cheaper.
The critical part: waiting is not the same as doing nothing, and if you treat it as an excuse to do nothing you've simply lost six months. Waiting well means spending that time on the parts that don't expire. Write down how the process actually works today, in real detail, including the exceptions people handle by instinct and have never documented. Measure the baseline — how long the task takes now, how often it's wrong now — because without that number you will never be able to prove any tool helped. Clean up the data. Fix the permissions mess. Sort out who owns which system.
None of that gets thrown away when you eventually build or buy. All of it is required either way. And most of it is what stalls projects six weeks in, when the pilot grinds to a halt because nobody can get access to the CRM export.
The test, compressed
I ask three things. Is this differentiating — would a competitor with the identical tool beat us anyway on something else? Is the hard part the data, and is that data ours and messy? And how fast is this category moving right now?
Generic problem, mature category: buy it, and don't customise it into a coffin. Differentiating problem, your data, stable enough tooling: build it, and budget for year three. Real problem, category in flux: wait deliberately, and spend the wait on the plumbing.
The companies I've watched get the most out of AI over the last few years weren't the fastest movers. They were the ones who knew which of their problems was which.
