Buy AI when an off-the-shelf tool already does the job at your volume and fits your systems. Build when packaged tools leave you doing the hard part by hand, when you need to connect to systems with no clean API, or when your data and compliance requirements are specific enough that no product fits.
And on the question everyone actually arrives with, fine-tuned model versus ChatGPT: a general model with good prompting and retrieval handles most business tasks. Fine-tuning is a later step for specific needs, not the starting point. Most teams that go straight there end up building retrieval afterwards anyway, having paid for both.
The ladder
Build versus buy is not a binary. It is a ladder, and most real systems land in the middle rather than at either end.
| Step | Approach | Relative cost | Best for | Move up when |
|---|---|---|---|---|
| 1 | Buy a finished product | Lowest | Common needs a mature tool already handles | It hands your hard cases back to a human |
| 2 | General model plus prompting | Low | Broad tasks, quick wins, first versions | Generic answers are not good enough because it does not know your business |
| 3 | Add retrieval | Moderate | Answering from your own data. Most custom needs stop here | You need consistent format or behavior that prompting cannot enforce |
| 4 | Fine-tune a model | Higher | Consistent style, narrow high-volume tasks, cost savings at scale | Almost never |
| 5 | Train or heavily customize | Highest | Rare. Few businesses genuinely need this | Effectively never for a business application |
The skill is landing at the right step, not defaulting to “just buy something” or “build it all ourselves.” Both extremes waste money in different ways: one leaves you doing manual work around a tool that nearly fits, the other spends six figures rebuilding something you could have subscribed to.
Let the actual limits pull you up the ladder. Do not start at the top because it sounds more serious.
When to buy
Buy when a product already solves your problem at your scale. If your need is common, invoice processing, transcription, a standard chatbot, and a mature tool handles it well, buying is faster, cheaper and lower-risk. You should not build what you can buy for a fraction of the cost, and a good partner will tell you when that is the case rather than selling you a build you do not need.
The test is simple and most teams skip it: run your real, messy inputs through the product, not the clean demo set.
The trouble starts when a product handles your easy 70% and hands the hard 30% back to a human, because that hard part was usually the whole reason you wanted automation. A tool that clears the work you could already do quickly has not saved you anything; it has just made the remaining queue more visible.
When to build a custom LLM solution
A custom solution earns its cost when buying cannot get you there. That happens for a few recurring reasons.
Off-the-shelf tools cannot handle your specific data or documents, which vary too much for a packaged product. You need to integrate with systems that have no clean API, like a legacy platform or an internal tool. Your compliance requirements force a particular setup, such as anonymization or deployment in your own cloud. Or the workflow is enough of a competitive edge that owning it, rather than renting a generic version every competitor also uses, actually matters.
We built a custom content engine for a fashion brand because no product could match their brand voice across six languages and plug into their exact stack. We built a custom document pipeline for a logistics company because off-the-shelf vendors choked on the messy 30% of their documents, which was the whole problem.
In both cases buying was tried first and could not close the gap. That is the bar: build when the custom part gives you something buying cannot.
Fine-tuned model versus ChatGPT
This is where a lot of money gets wasted, so it is worth being blunt.
Fine-tuning means taking a base model and training it further on your examples so it adopts a specific behavior. It sounds like the obvious way to make a model know your business. It usually is not, because it does not do that.
Fine-tuning shapes behavior. Retrieval supplies knowledge. A strong general model with good prompting and retrieval on your data handles the large majority of business tasks. Retrieval gives the model your information at query time, which is what “knowing your business” means in practice, and it updates the moment your data changes. Fine-tuning cannot do that: knowledge baked into weights goes stale and re-baking it means retraining.
Fine-tuning earns its place in three specific cases. When you need a very consistent output format that prompting cannot reliably enforce. When the task is narrow and specialized enough that a tuned smaller model beats a general one. Or when you are running at a volume where a cheaper fine-tuned model meaningfully cuts cost.
On the logistics build we fine-tuned a triage classifier for exactly the second and third reasons: sorting a high volume of inbound documents into a small set of categories, a narrow repetitive task where a small tuned model was both more accurate and far cheaper than calling a general model millions of times. General models did the reasoning-heavy extraction downstream.
That is the pattern worth copying. Fine-tune the narrow, repetitive, high-volume part. Use a strong general model for the parts that need judgment.
A worked example: one company, three answers
To make the ladder concrete, here are three needs a single company might have at the same time.
| Need | Where it lands | Why |
|---|---|---|
| Meeting transcription and summaries | Step 1, buy | Common, well-solved, mature products. Building it reinvents something you can subscribe to, and gives you no edge because competitors buy the same thing |
| An assistant answering employee questions from internal policies and docs | Step 3, general model plus retrieval | No product knows their documents, but this needs knowledge, not changed behavior. Retrieval updates when docs change and cites sources. Fine-tuning would add cost and maintenance for no gain |
| Classifying very high volumes of records into narrow categories, fast and cheap | Step 4, fine-tune | Narrow, repetitive, high-volume. A tuned smaller model beats a general one and costs far less at scale. Everything else stays on general models |
One company, three needs, three different answers. That is the normal outcome. If the need is AI inside a product you sell rather than a workflow you run, the same ladder applies with different economics, which we cover in embedding AI in a SaaS product.
The wrong move is picking one philosophy, build everything or buy everything, and forcing every need through it. Let each need find its own step.
What to confirm before you commit to a build
Ownership, in writing. Code, models, prompts, documentation. A custom system you do not own is worse than a product you rent, because you have paid build prices for rental dependency.
A capped budget with phase gates. A scoping step, then a prototype on real data, then production, with a stop point at each boundary. If the prototype shows the workflow is a poor fit, you have spent little and learned a lot.
The hard part proven early. For most builds that means retrieval quality and evaluation, not the model integration. If a prototype phase does not test the hard part, it is a demo.
Readiness on your side. Data access, a named owner and a specific target, which our readiness checklist scores in about an hour. Builds do not fail on the ladder step. They fail on these.
Hand-off as a deliverable. Documentation, a runbook and training in the scope, so your team can run and extend the system. Hand-off should not be an upsell.
If you are choosing who does the build, our ten-point vetting checklist turns each of these into a question to ask on the first call.
Frequently asked questions
Is it cheaper to build or buy AI? Buying is cheaper when a product fits, because you are not paying to build what already exists. Building is worth it only where buying leaves a real gap. The expensive mistakes are building a generic capability you could have bought, and buying a tool that cannot handle your hard cases and going back to manual work.
Do we need to fine-tune a model to use our data? Usually no. Retrieval, not fine-tuning, is how a model uses your data. Fine-tuning shapes behavior and format. Start with a general model plus retrieval, and fine-tune only if you hit a specific limit retrieval cannot solve. Our RAG guide covers how retrieval works and where it gets hard.
Will a custom AI solution lock us in? It should not. On a well-run build you own the code, models and prompts, so you can change providers or take it in-house. Confirm ownership in writing before the work starts, not at hand-off.
How do we know where we land on the ladder? Test buying first with your real data. If a product fits, buy. If it leaves the hard part undone, move up only as far as the gap requires. Let the actual limits pull you up rather than starting at the top.
What if we are somewhere between steps? Very common, and usually it means one part of the workflow needs a higher step than the rest. Split it. Buy the transcription, build the retrieval, tune the classifier. Systems that mix steps are the normal shape of a good architecture, not a sign of indecision.
The fastest way to find your step: take the twenty hardest real inputs your workflow sees and run them through the best product on the market. Wherever it fails is exactly how far up the ladder you need to go, and no further.
If you want a second opinion on where your case lands, that is what our custom AI work starts with. Often the honest answer is to buy for now, or to use a general model with retrieval, and we will say so rather than sell you a bigger build than you need.