· 1 min read
Build vs Buy in the AI Era
The build/buy framework I use for AI investments at Johor Corporation — and why the answer changes faster than your procurement cycle.
- ai-strategy
- leadership
The build-vs-buy question used to take a quarter to answer and three years to live with. In the AI era the answer changes every six months, but the procurement cycle has not been told. So the most honest framing I have found is not "build or buy" — it is "what do we want to own in three years' time, and what do we want to rent this quarter?"
Owning means three things, and only three: the data, the prompts, and the evaluations. If we own those, the foundation model can change underneath us and we lose a sprint, not a programme. Anything you can move to a cloud-hosted endpoint without losing your data, your prompts, or your evals is a renting decision. Anything that quietly leaks one of those three is a build decision — no matter what the vendor's slide deck says.
The corollary is uncomfortable. A lot of "buy" decisions in the last twelve months were rentals that quietly demanded ownership in the fine print — copilot deployments that needed bespoke grounding data, agents that needed bespoke tool definitions, evals that ended up custom anyway. We budgeted as if it were buy and we executed as if it were build. The cure is to make the build/rent/buy split explicit on the first page of every business case, and to revisit it the day after each foundation-model release.