Build vs. Buy Is the Wrong Question for Your AI Feature

Every planning meeting about an AI feature collapses into the same binary. One camp wants to "just wrap an API" and ship next sprint. The other wants to "own the model" so the company controls its destiny. The argument feels strategic. It is actually a category error.

Build vs. buy treats your AI feature as one indivisible thing that you either make or purchase. But an AI feature is not one thing. It is a stack of at least five distinct layers, and each layer has its own answer. The team that frames the decision as a single coin flip will almost always own the wrong layer and rent the wrong layer, because the question they asked could not distinguish between them.

The better question is not "can we build it?" Most things, you can build. The question is: which layer breaks our differentiation if a competitor buys the exact same thing tomorrow? That question sorts the stack for you.

The five layers of an AI feature

Pull any AI feature apart and you find roughly the same anatomy underneath:

• The model — the foundation model doing inference. GPT, Claude, Gemini, an open-weight model you host, or a fine-tune of one.
• Retrieval — the data you feed the model at runtime: vector indexes, knowledge bases, the documents and records that ground a response.
• Orchestration — the control flow. Prompt assembly, tool calls, retries, multi-step agent loops, routing between models.
• Evals — the test suite that tells you whether a change made the product better or worse: golden datasets, scored rubrics, regression checks.
• UX — the surface the user touches. How the feature collects intent, shows uncertainty, lets the user correct it.

"Build the AI feature" or "buy the AI feature" is a sentence that spans all five. It is as meaningless as a database team debating "build vs. buy" without saying whether they mean the storage engine, the schema, the query layer, or the dashboard. The decision only becomes tractable when you make it per layer — and the layers do not get the same answer.

Owning the model rarely creates a moat

The instinct to own the model is the strongest and the most often wrong. It feels like the deepest layer, therefore the most defensible one. The opposite is closer to true.

A foundation model is the most rapidly commoditizing component in the stack. Multiple labs ship frontier-class models on overlapping timelines, prices fall by roughly an order of magnitude a year, and open-weight models trail the frontier by months, not years. If your differentiation is "we use a good model," a competitor erases it by reading a pricing page. The investor version of this test is blunt: if a frontier lab released a model 10x better tomorrow, does your company still have a reason to exist? If the honest answer is no, the model was never your moat.

Fine-tuning is where this gets expensive to learn. A fine-tune feels proprietary — it is your weights, trained on your data. But a fine-tune is a snapshot. It is frozen against the base model it started from. Eighteen months later the base model has been superseded twice, and your fine-tune is now a fork you maintain alone, slowly drifting behind a moving frontier that the labs improve for free. You did not build a moat. You built a maintenance liability and called it one.

Owning the model makes sense in a narrow band of cases: hard data-residency or regulatory constraints, latency or cost envelopes the APIs genuinely cannot meet, or a domain so far from the training distribution that no general model is close. Outside that band, owning the model means signing up to out-run labs spending billions a year. That is not a moat. That is a treadmill.

Owning the eval set and the data almost always does

Now look at the layer everyone treats as plumbing. Your eval set is the most defensible asset in the entire stack, and most teams cannot see it because it never shows up as a feature.

Loading…