Build, buy or partner for AI models

Three options, not one decision

Teams often frame this as a single strategic choice: are we a company that trains its own models? In practice the decision applies to each task. A company may buy a general model for drafting, fine-tune a smaller model for classification, and partner with a specialist for speech. Treating it as a portfolio of small decisions avoids both over-building and over-dependence.

Buy: rent capability and move quickly

Buying means using a provider's models through an interface. It gives quick access to strong capability, no training cost, and a path to better models as the provider improves. The costs are less control over behavior and price, exposure to provider changes, and the risk that competitors can rent the same thing. Buying fits when the task is common, when speed matters more than uniqueness, and when the volume is not yet high enough for custom work to pay back.

Build: own the model where it matters

Building ranges from fine-tuning an existing model to training one from scratch. It can reduce cost per unit at high volume, improve quality on a narrow domain, keep sensitive data in a controlled environment, and make the company less dependent on any single vendor. The costs are talent, compute, evaluation infrastructure and ongoing maintenance, because a model that is not updated drifts behind. Building fits when you have proprietary data that improves results, volume large enough to change the cost math, or a requirement that outside providers cannot meet.

Partner: borrow skill and share risk

Partnering covers co-development, joint ventures with data holders, and long-term services relationships with specialists. It can bring expertise a young team lacks and access to data or distribution. The costs are shared control and the need for careful contracts on intellectual property, data use and exit. Partnering fits when the capability is outside your core, when a counterparty holds something you cannot obtain alone, or when the learning matters as much as the result.

A quick comparison

	Buy	Build	Partner
Speed to start	Fast	Slow	Medium
Control	Low	High	Shared
Upfront cost	Low	High	Medium
Cost at high volume	Can be high	Can be lower	Depends on terms
Main risk	Dependence	Maintenance burden	Misaligned incentives

Questions that settle most cases

• Is the task common or distinctive? Common tasks favor buying.
• How sensitive is the data? Strict constraints favor building or a controlled arrangement.
• What does a small change in quality mean to the customer? If it is large, custom work may pay for itself.
• How many units per month? Volume changes the arithmetic. The method in unit economics of AI products shows how to work it out.
• Can you evaluate the result? Without a good test set, you cannot compare options honestly.
• Who will maintain it? A model without an owner becomes technical debt.

A hypothetical path

Keep your options open

Whichever route you choose, a few habits keep switching affordable. Hold your own evaluation set and run any candidate model against it. Keep prompts and business logic in your own code, not inside a provider's proprietary tooling. Record which model produced which output. And test a second provider early, even if you do not plan to use it, so the switching plan is real rather than aspirational. These habits matter more than the first decision, because the right answer will change.

Common errors

Three errors recur. Teams build too early, before they have the data or the volume to justify it. Teams buy without a measure of quality, so they cannot tell whether a cheaper model would do. And teams partner without a clear exit, so a promising arrangement becomes a dependency. Each is avoided by writing down, before you start, the result you expect and the evidence that would change your mind.

What we look for

We like teams that can explain, task by task, why they chose their route, what it costs and what would make them change. Founders who build everything because it feels strategic, and founders who buy everything without a plan for dependence, both tend to have unexamined assumptions. A clear rationale is a sign of good judgment. Our page for startup founders describes how we think about early technical choices, and hiring the first AI team covers the people question that follows.

This article is for general information only and is not investment, legal, tax or accounting advice.