“You don't churn your own butter to run a bakery. You also don't outsource the recipe that makes you the best bakery.”
The one question that drives it
Start with: is this capability core to how you compete? If the AI is doing something every business in your space needs but nobody wins on — transcribing meetings, summarising documents, basic support deflection — buy it. Someone has built a better version than you will, and maintaining it is a distraction from what you're actually good at.
If the AI is doing something central to your differentiation — the thing customers choose you for, built on data or workflows only you have — that's a candidate to build, because owning it is owning your edge. The mistake is treating every AI decision the same. Buy the commodity; build the differentiator.
What "build" really means now
"Build" rarely means training your own model — that's a multi-million-dollar undertaking reserved for a handful of companies. For almost everyone, "build" means building a system on top of someone else's model via an API: your data, your workflows, your interface, their model underneath. This is the sweet spot for most differentiated AI products.
This matters for the decision because it changes the cost of building. You're not funding AI research; you're funding software engineering around a rented capability — which is far more predictable. The fundamentals of build-vs-buy you already know mostly apply; AI just adds a rented component in the middle.
The lock-in question
Whichever way you go, ask what happens when you want to leave. With a vendor: can you export your data and your configuration, or are you captured? With a model provider: are your prompts and workflows portable to another model, or have you built everything around one provider's quirks? Providers deprecate models, change prices, and have outages — your design should survive all three.
When to wait
Waiting is a legitimate, underused choice. If a capability is core to you but not yet reliable enough, funding it now means paying to be on the bleeding edge — high cost, high failure rate, and you'll likely redo it in a year when the technology matures. Sometimes the right move is to watch closely, run a tiny experiment to stay informed, and commit real budget when the capability crosses the reliability line.
"Wait" is not "ignore." It's an active position: stay informed, keep a small bet running, and be ready to move fast when the moment comes. The teams that win aren't always the first; often they're the ones who moved decisively at the right time, having avoided the expensive early failures.
In one line each
- Decide per case, not once: buy the commodity capability, build the differentiator, wait on the core-but-immature.
- "Build" now almost always means building a system on a rented model via an API — software engineering, not AI research.
- Mind lock-in: keep data, configuration, and prompts portable; providers raise prices, deprecate models, and have outages.
- Waiting is an active, legitimate choice — stay informed with a small bet and commit when the capability crosses the reliability line.
Where to go next