Most of the AI projects we're asked to rescue didn't fail in the code. They failed in the decision. Someone picked a heavyweight model for a job a database could do, or built a custom model when an API call would have shipped in a week, or bolted an LLM onto a workflow that needed a rule, not a guess. By the time we're called in, the bill is high, the thing is flaky, and nobody can quite say why it's there.
Choosing the right AI solution is mostly about asking boring questions before you write any code. Here's the framework we actually use.
Start with the problem, not the model
The fastest way to waste a quarter is to start from "we want to use AI" and go looking for a place to put it. Start from the problem instead, in plain language: what does a user need, what's slow or expensive today, what decision are we trying to make.
Only once the problem is written down clearly should the word "model" enter the conversation. Nine times out of ten, the right solution is the simplest thing that solves the problem, and sometimes that isn't AI at all.
Is this actually an AI problem?
Before reaching for a model, we run three quick checks. They take five minutes and save weeks.
Is the rule actually fuzzy?
AI earns its keep on problems you can't write down. "Is this email valid" is a spec, not an AI problem. "Is this support message angry" is genuinely fuzzy. If you can describe the logic in a paragraph of plain conditions, you have an afternoon of coding, not a model.
Can you tolerate being occasionally wrong?
Models are wrong sometimes. That's fine for suggesting tags or drafting a reply. It's not fine for moving money, enforcing permissions, or computing tax. If a single wrong answer is unacceptable, a probabilistic system is the wrong foundation no matter how good the accuracy number looks.
Does the value clear the cost?
Run the multiplication early: per-request cost times volume, per-call latency inside your real user flow. We've killed features in a planning meeting because the math said each call cost more than the action was worth.
If you want to read our fuller take on this, see When Not to Use AI. The short version: the goal was never to use AI, it was to solve the problem well.
Match the solution to the problem
Once you've confirmed AI genuinely fits, there's still a ladder of options, from cheap and boring to powerful and expensive. Climb it from the bottom.
The mistake we see most is people starting at the top of that list. Start at the bottom and only climb when the rung you're on genuinely can't do the job. Here's the same ladder as a quick reference:
| If the problem is… | The right rung is… | Why |
|---|---|---|
| A knowable rule ("is this email valid?") | Rules / code | Instant, free, testable, never mysteriously wrong |
| Structured data with a clear target (churn, fraud) | Classic ML | Cheaper, faster and more predictable than an LLM |
| Fuzzy language (drafting, summarising, extraction) | LLM via API | Rent frontier intelligence by the token, ship in days |
| Answering over your own changing knowledge base | RAG | Grounds the model in your data without retraining |
| A narrow, repeated task with lots of proprietary data | Fine-tuned / custom model | Most powerful, but the most expensive to build and run |
Build, buy, or call an API
Three honest paths, and the right one depends on how core the capability is.
Choosing the model tier
If you land on an LLM, you still have to pick how big a model to use, and bigger is not automatically better. Every tier trades capability against cost and latency.
A pattern that works well: tier your models. Route the easy, high-volume calls to a small model and reserve the frontier model for the genuinely hard cases. A simple classifier up front pays for itself fast.
Run the numbers before you commit
This is the step almost everyone skips, and it's the one that decides whether the project is viable. Both costs matter: what it takes to build the thing, and what it costs to run it every month at your real volume. An AI feature that's cheap to build and ruinous to run at scale is still a bad idea.
Try it yourself: use our Project Cost Calculator to ballpark both the build cost and the ongoing running cost for your idea, then sanity-check whether the value clears the bill before you write a line of code.
Don't forget data, privacy and security
The model is only half the system. The other half is the data flowing through it, and that's where projects get teams into trouble.
We treat every line a model produces with the same scrutiny as code from an unknown contributor, because that's effectively what it is.
A simple decision checklist
When a new idea lands on our desk, we run it through this:
If you can answer those nine, you've done the hard part. The build is the easy 20 percent.
The takeaway
Picking the right AI solution isn't about knowing the latest model. It's about resisting the urge to reach for the most powerful tool, starting from the problem, climbing the ladder from the bottom, and doing the arithmetic before you fall in love with a demo. Get the decision right and the rest gets a lot easier. Get it wrong and no amount of clever prompting will save you.
If you're weighing an AI build and want a straight answer on whether it's worth it, that's exactly the conversation we like to have.