Build, Buy or Fine-Tune: Choosing Your AI Route

There are four routes, not three

The build-versus-buy question used to have two answers. With AI in 2026 it has at least four, and conflating them is how businesses end up fine-tuning a model to do something a well-written prompt would have handled in an afternoon.

1. Buy a finished product with AI built in: a support desk, a transcription tool, an invoice reader.
2. Build on a hosted model: your software, your workflow, a general model called through an API, often with retrieval over your documents.
3. Fine-tune an existing model on your own examples so its behaviour shifts towards your task.
4. Train your own model from the ground up, which for language models is outside the budget of nearly every SME.

Classic machine learning on tabular data, such as forecasting or scoring, is a separate case: there you almost always build, because the model is small and the data is uniquely yours.

When buying is right

Buy when the task is something thousands of other businesses also do and doing it slightly better gives you no edge. Meeting transcription, generic email drafting and standard document OCR are good examples. Vendors spread the development cost across all their customers, and you will not beat that economics.

The catch is integration and lock-in. A bought tool that cannot read from or write to your core systems creates a new copy-and-paste job. Check the API and the export path before the demo, not after. We cover the wider trade-off in build vs buy for AI features.

When building on a hosted model is right

This is where most custom business AI sits, and for good reason. You own the workflow, the data handling and the user experience, while renting general language ability from a provider who improves it every few months.

It fits when the task depends on your data or process: answering questions from your policy library, extracting fields from your suppliers' particular documents, routing your enquiries by your categories. Retrieval handles knowledge; careful prompts and examples handle format and tone. Swapping the underlying model later is usually a configuration change, if the system was built with that in mind.

When fine-tuning actually earns its cost

Fine-tuning is oversold. It changes how a model behaves, not what it knows, so it is a poor way to teach it your product catalogue. It is a good way to make a smaller, cheaper model consistently perform one narrow task the way you want.

• You have several thousand high-quality input and output examples, not a few hundred
• You have measured a gap with prompting and retrieval, on a proper evaluation set
• Volume is high enough that moving to a smaller fine-tuned model saves real running cost or latency
• The output format or style is very specific and prompting keeps drifting from it
• You accept the upkeep: retraining when the base model is retired or your task changes

If fewer than three of those are true, do not fine-tune yet. Our comparison of RAG, fine-tuning and prompt engineering goes deeper on the technical side.

The four routes side by side

The figures are indicative of what we see on SME projects, not quotations. The ordering matters more than the numbers.

A worked example

Take an illustrative insurance broker handling 1,500 claim forms a month in varied formats. Buying a generic document tool gets 70% of fields right, but misses broker-specific fields and cannot post into their policy system. Building on a hosted model with structured extraction and a review screen reaches a level where staff only check flagged fields, and it integrates directly.

Fine-tuning would only enter the conversation if volume grew tenfold and per-document cost started to matter, and by then there would be tens of thousands of reviewed examples to train on. That sequence, build first and fine-tune on the evidence later, is the one we recommend in most cases.

How each route typically goes wrong

Every route has a characteristic failure, and knowing it in advance is most of the protection.

• Buying goes wrong when the tool is chosen on demo quality and the integration is discovered to be a CSV export once a week. Staff end up running two systems.
• Building on a hosted model goes wrong when nobody keeps an evaluation set, so every prompt tweak is judged by feel and quality wanders over months without anyone noticing.
• Fine-tuning goes wrong when the training examples are inconsistent. The model learns the inconsistency faithfully, and the team concludes fine-tuning 'does not work'.
• Training your own goes wrong by running out of money, usually before the model is better than the hosted option would have been.

One more that cuts across all four: making the decision once and never revisiting it. Hosted models improve, prices move and volumes change. A decision that was right eighteen months ago deserves a fresh look, and a system built with the model isolated behind a clean interface makes that fresh look cheap.

Questions that settle it

1. Is this task a source of advantage, or a chore every competitor also has?
2. Does it depend on our data and systems, or on general ability?
3. Do we have a measured quality gap, or only a suspicion?
4. What will monthly volume be in two years?
5. Who maintains it when the provider retires a model version?

At SpiderHunts we answer these with the client before recommending an AI integration route. Sometimes the honest answer is a subscription and an afternoon of setup.

Frequently asked questions