Build vs. Buy in the AI Era — The Calculus Has Changed

The classic build-vs-buy framework worked because the alternative to building was well-understood. Vendors offered stable, contractually defined capabilities. Their products had known limitations. The decision was fundamentally about whether your requirements were sufficiently differentiated from what the market offered to justify the cost and risk of building. When the answer was no, you bought and integrated. When the answer was yes, you built and maintained.

AI breaks this in a specific way: the vendor’s capability is not stable. The model you’re evaluating today is not the model you’ll be running in eighteen months. The benchmark numbers that convinced your team to choose one foundation model over another will be obsolete in a quarter, probably sooner. And the comparative advantage of building versus buying isn’t just about current feature parity — it’s about where the capability frontier is moving and whether your team can move with it.

That last point is where most build-vs-buy analyses fail. They’re essentially static. They compare what you could build today against what you can buy today. But AI procurement is a commitment to a capability trajectory, not a point-in-time capability.

The layer problem

The build-vs-buy question in AI isn’t binary. It’s layered. Foundation models, fine-tuned models, retrieval systems, orchestration layers, evaluation infrastructure, UX — each of these has a different build-vs-buy calculus, and they don’t all move together.

The mistake I see most often is teams treating “we’re buying from OpenAI / Anthropic / Google” as a complete answer to the build question. They’ve bought the foundation. Everything else — how the model is prompted, how it’s evaluated, how it’s updated when it degrades, how user feedback loops back into quality — still has to be built. If you don’t invest in those layers, you’re not really running an AI product. You’re running an API call with a nice UI on top of it, and your competitive position is precisely as strong as your vendor’s current offering and no stronger.

The orgs that are building genuine defensibility right now are the ones investing in evaluation infrastructure. That sounds boring compared to building the actual product, and it is boring, but it’s also the thing that determines whether you can actually improve your system over time or whether you’re flying blind. If you don’t have a rigorous way to measure whether your AI product got better or worse when you changed something, you don’t have an AI product strategy. You have a dependency.

When to build your own models

The fine-tuning decision has become more tractable over the last two years, but the calculus is still often misread. Fine-tuning is worth the investment when you have a specific, stable, well-defined task where base model performance is meaningfully below acceptable and where you have enough labeled data to actually move the needle. That’s a narrower set of cases than most teams think.

What often makes more sense than fine-tuning is investing in your data infrastructure. Not because data is more important than models in some abstract sense, but because your proprietary data is the one thing a vendor can’t replicate. The orgs that built strong data flywheels in the pre-AI era — clean, structured, well-labeled corpora that capture domain-specific knowledge — are the ones that can actually unlock competitive advantage from AI. The ones that don’t have that are largely buying commodity capability and hoping the vendor continues to improve faster than their competitors.

The honest conversation to have

The build-vs-buy question ultimately requires your team to answer something harder than “what can we build?” It requires answering: “What is the minimum capability we need to be able to build in-house for this product to be defensible?” If the answer is nothing — if a competitor with a corporate credit card could replicate your AI capabilities tomorrow — then you’re not building a product. You’re building a distribution play, and you should make that strategy explicit and own it rather than telling yourself the product is differentiated.

That’s not always the wrong strategy. Distribution advantages are real. But they have a different capital allocation logic than technology differentiation advantages, and conflating them leads to over-investment in building capabilities you don’t actually need to own, and under-investment in the distribution and relationships that are your real moat.