OpenAI Needs Just 10 Examples to Fine-Tune a Model. Most Startups Should Still Buy First.

Build, buy and fine-tune are three separate projects, not three settings on the same dial. Buying means calling someone else’s model through an API. Fine-tuning means retraining a model on examples you supply, starting at a minimum most people don’t expect. Building means owning the model itself, a step almost no startup actually needs.

What buying actually commits you to

Buying an AI capability means sending requests to a hosted model, usually from OpenAI, Anthropic or a similar vendor. You pay per token or per call. It is the fastest path to a working feature, often a matter of days rather than months. The tradeoff shows up later. You don’t control when the underlying model changes behavior, and you don’t own the weights. Every request leaves your infrastructure and enters theirs.

That last point matters more in regulated work. If the data includes patient records or anything else covered under HIPAA, sending it to a vendor’s API matters. That vendor becomes part of your compliance boundary. That’s exactly what the business associate requirements in the HIPAA Privacy Rule are built to address. Teams skip that paperwork because the integration felt simple. That’s one of the more common ways a buy decision turns expensive after the fact, not before it.

There’s a quieter cost too. Buying ties your product’s behavior to a vendor’s release schedule. A prompt tuned carefully against one model version can drift when the vendor updates it. Rate limits that felt generous in testing can throttle a feature the day usage actually grows. None of that argues against buying. It argues for knowing, before you ship, what happens to the feature if the vendor changes something you didn’t ask for.

What fine-tuning requires before it does anything useful

Fine-tuning sits between buying and building. You start with an existing model and retrain it on examples specific to your task. That produces the style, format or judgment you actually need instead of the generic version. OpenAI’s own guidance states that the minimum number of examples you can provide for fine-tuning is 10. Noticeable improvement generally shows up somewhere between 50 and 100 well-chosen examples.

Ten examples will technically run. They will not teach a model much. The honest number for most tasks is closer to the fifty the documentation recommends. Those fifty have to be real, representative cases, not a handful of easy ones pulled together the night before a demo. Collecting them is the actual cost of fine-tuning. The retraining step is almost incidental by comparison.

What building costs after launch, not before

Building a model from scratch means owning training infrastructure, a team that can maintain it, and a retraining schedule that never really ends. The sales pitch for building is control. The bill arrives as GPU time and storage, plus infrastructure costs that only show up once traffic is real. Storing and moving large training datasets is one of them, a line item most teams don’t notice until the invoice reflects it. It also arrives as headcount. Someone has to own model quality the way someone already owns uptime. That person doesn’t show up for free once the novelty of having “your own model” wears off.

None of that is a reason to never build. It’s a reason to be honest about when building earns its cost. Building makes sense when the model is the product itself, something a customer pays for directly. It doesn’t make sense as a feature bolted onto a product that would work fine with a vendor’s model underneath it. Outside of that case, a custom model is usually a research project wearing a product roadmap’s clothes.

Build, buy or fine-tune: the decision that actually drives the choice

The real question isn’t which option sounds most impressive in a pitch deck. It’s what you’re trying to control: speed, cost, accuracy on a narrow task, or the model itself. Buy optimizes for speed. Fine-tune optimizes for accuracy on a task a general model handles poorly. Build optimizes for owning something nobody else can sell you, which is rarely what an early product actually needs.

This is the fork a fractional CTO is usually brought in to settle, before a vendor contract or a training budget locks in. Reversing either decision later costs far more than getting the sequence right the first time. Kody Doherty, Fractional CTO, works through exactly this kind of decision with founders before the architecture hardens around it.

Where to start

Buy first. Prove the use case works with a vendor’s model before you spend a dollar on fine-tuning. Don’t spend a single hour on infrastructure for a model you’d have to maintain forever. Move to fine-tuning only once the prompt alone can’t reach the accuracy the task demands. Move to building only when the model is what you’re actually selling.

Most AI features die from being built too early, not from being bought too late. Start where the evidence is cheapest to gather, and let the data decide whether the next step is worth taking.