Most AI projects don't fail because the model was bad. They fail because the team picked the wrong shape of solution for the problem they had: buying a generic tool for a job that needed customization, building something custom when an off-the-shelf product would have worked, or fine-tuning a model when the real issue was that it needed fresher information, not a different personality.
Before you commit budget or engineering time, run the problem through a short set of questions. It won't settle every edge case, but it resolves the majority of buy-versus-build debates we see clients get stuck on.
Start here: is this a knowledge problem or a behavior problem?
Before the full decision tree, ask one quick thing. Is the AI failing because it doesn't know something (it needs access to the right document, record, or data point), or because it doesn't behave the way you want (wrong tone, wrong format, inconsistent structure)? Knowledge problems point toward retrieval-based approaches. Behavior problems point toward fine-tuning or tighter prompting. Keep that distinction in mind as you go through the questions below, because it's the one teams skip most often.
The decision tree: six questions
1. Is there a ready AI product that already covers 70-80% of what you need?
If yes, buy it. This applies to simple, well-scoped tasks where speed matters more than a perfect fit and the cost of an occasional mistake is low: support ticket triage, meeting notes, first-pass search, internal Q&A on non-sensitive topics. There is no strategic advantage in building your own version of a solved problem.
2. Is the real gap about process and integration, not knowledge?
If the model already knows enough but the workflow around it is broken, customize the workflow layer instead of the model itself. A common example: a sales call gets summarized correctly, but nobody has connected that summary to the fields your CRM actually needs filled in. That's not an AI problem, it's an integration problem, and it's usually cheaper to solve than people assume.
3. Must every answer strictly follow current documents, with sources attached?
If accuracy and traceability matter, and your source material changes often, implement retrieval-augmented generation (RAG) rather than trying to bake knowledge into the model itself. RAG keeps the model grounded in your actual, current documents and lets you show where an answer came from, which matters for anything with an audit trail: policy assistants, compliance Q&A, internal documentation search.
4. Does the model need a consistent voice or format, applied thousands of times?
Only if the answer is clearly yes should you consider fine-tuning, and even then, treat it as a later-stage optimization rather than a first move. Fine-tuning is rarely the right call in the first sprint of a project. It's expensive to get right, it locks you into a specific model version, and it solves a narrower problem (consistent style and structure) than most teams initially think it will. If your real issue is stale information, fine-tuning won't fix it, RAG will.
Laid out visually, the six questions collapse into a single flow you can walk through in a few minutes:
Putting the four options side by side
Option 1: Buy off the shelf
Best for simple, well-understood tasks where a generic tool already does the job. Fast to deploy, low upfront cost, minimal customization needed. The tradeoff is that you're accepting whatever the vendor built for the average customer, not your specific workflow.
Option 2: Customize the workflow layer
Best when the model's outputs are fine but the surrounding process isn't. This is often the cheapest fix on the list, because you're not touching the AI at all, you're closing the gap between what it produces and what your systems need.
Option 3: Implement RAG
Best when accuracy, freshness, and traceability matter and your knowledge base changes regularly. RAG lets you update the underlying documents without retraining anything, which keeps maintenance costs predictable.
Option 4: Fine-tune, carefully
Best when you have thousands of similar examples and need strict, repeatable formatting or tone, such as generating product descriptions at scale in a fixed structure. Treat it as a refinement step after the basics are working, not a starting point.
Where teams usually get this wrong
The failures we see most often aren't technical, they're mismatches: buying a generic tool where the task actually needed customization, reaching for fine-tuning when the problem was really outdated information that RAG would have solved, or building a custom system from scratch when an existing product covered most of the need. Each of these mistakes is expensive to reverse, because by the time it's obvious the fit is wrong, there's already a workflow built around it.
The bottom line
If you treat AI as a quick fix, it tends to cost more over time, through re-testing, edits, and a slow erosion of trust in the outputs. If you treat it as a capability that has to be matched to the actual shape of the problem, it starts to function as a real part of the system instead of a bolt-on experiment.
If you're not sure which of the four options fits your situation, that's a reasonable place to bring in outside eyes. Talk to our team and we'll help you map the problem before you commit to a build.