Build, buy, or fine-tune

TL;DR

Every generative AI product decision comes back to one question at the top: how much of this do we build ourselves, how much do we buy, and how much do we adjust through fine-tuning? Build means training or running your own model — rare, expensive, and justified only when the model itself is your product. Buy means calling a vendor's model through an API and building your product around it — the default for almost every team, because the model is a commodity input, not a differentiator. Fine-tune sits between the two: you start from someone else's model and adjust it on your own examples, usually to fix a style, a format, or a narrow skill, never to teach it new facts. Most teams should buy the model and spend their real engineering effort on the layers around it — grounding, action, and operations — because that is where the actual product gets built.

🎯 For the product leader

Why it matters — Training your own model sounds like ownership and control, but it is usually the most expensive, slowest way to compete on a layer that is not where your product wins. Most teams that "build" end up rebuilding what a vendor already sells, at a fraction of the quality, for a much higher price.

What it changes in your decisions — You default to buy, and you treat build and fine-tune as the exception that needs a specific justification, not the other way around.

Ask yourself — "Is the model itself our product, or is our product the system we build around a model someone else already trained?"

Risk if ignored — A team spends a year and a large budget training a model that ends up behind the next vendor release, while a competitor who bought the model and built the product around it shipped months earlier.

The mental model: the engine, the workshop, and the tune-up

Buying a model is like buying a car engine from a manufacturer who has spent billions perfecting it. Building your own model is like building an engine from raw metal in your own workshop — possible, but only worth it if engines are your business. Fine-tuning is like a tune-up: you keep the manufacturer's engine, and you adjust it for your specific driving conditions.

The three options, compared

Why "buy" wins by default

Frontier model vendors spend enormous budgets and employ large research teams to make their models better every few months. A team training its own model is competing against that pace with a fraction of the resources, on a task — general-purpose generation — that is rarely the actual product a customer pays for. The customer pays for the problem your product solves, not for which model answers it. Buying the model and spending your budget on grounding, action, and operations — the layers covered in the product stack lesson — is almost always the better use of a limited budget.

Buying is not risk-free, and the evidence on it is mixed. MIT NANDA's 2025 study The GenAI Divide reported that tools bought from specialist vendors succeeded about 67% of the time, and internal builds about one-third as often. Treat that as a signal, not a law. The study rests on interviews, a survey, and public deployments, and it defines success narrowly as rapid revenue growth. The bigger risk of buying is dependence. OpenAI retired the Sora 2 API on 24 September 2026, and Google shut down its Veo 3.1 preview video models on 22 October

2026. Any model you rent can change price, features, or availability on the vendor's schedule, not yours.

When build or fine-tune actually make sense

Build is justified when the model's behavior, cost structure, or data handling is the product itself — a company selling a specialized model to other companies, for example, or one bound by regulation to keep training data fully in-house. Fine-tune is justified when a vendor model's default tone, format, or narrow skill does not fit your use case closely enough, and you have enough well-labeled examples to teach the adjustment reliably. Both are real, valid choices. They are just not the default, and a team should be able to state plainly why this feature is the exception before committing the extra cost and time.

Failure modes

• Building for control that buying already gives you — training a model because "we want to own our AI," when a vendor's terms already give you the control that actually matters, like data handling and usage rights.
• Fine-tuning to teach facts — using fine-tuning to bake in a knowledge base that goes stale on the next update and can never be cited, when retrieval was the right tool.
• Buying without a fallback plan — depending entirely on one vendor's model, with no plan for a price increase, a policy change, an outage, or the model being shut down. Keep your prompts, evals, and data in a form you can move to a second model.
• Skipping the justification step — choosing build or fine-tune out of habit or preference, without a clear answer to why buy alone would not work.

Practitioner checklist

• Have we stated plainly why buy alone would not meet this feature's needs, before committing to build or fine-tune?
• If we are fine-tuning, is the goal behavior, style, or format — never facts that will change?
• If we are building, is the model itself genuinely our product, with the budget and team to keep pace with vendor releases?
• Do we have a fallback plan if our chosen vendor changes price, availability, or policy?

Related lessons

• The generative AI product stack — where the real engineering effort goes once you have bought the model.
• RAG vs. long-context vs. fine-tuning — the same choice, applied specifically to grounding a model in facts.
• Fine-tuning vs. ICL vs. RAG vs. distillation — the engineering-depth spoke on this tradeoff.