Cost & Budgeting
Engineering Practice3 min read
Why the AI pilot worked and the rollout did not
Most stalled AI projects are not missing a better model. They are missing an evaluation set, a cost ceiling, and a decision about what happens when it is wrong.
Working on something like this?
Get an estimateThe short version
- A demo proves the model can be right. Production requires knowing how often it is wrong.
- Without a scored evaluation set, every prompt change is an argument rather than a decision.
- Token cost and latency behave differently at ten users and ten thousand. Model both early.
- Design the failure path first: what the system does when it does not know.
The pattern is consistent enough to be predictable. A pilot is built in three weeks, demonstrates beautifully, and gets funded. Six months later it has not reached general availability and nobody can quite say why.
The reason is rarely the model. It is that a demo optimizes for the best case and production is decided by the worst one.
1. Nobody built an evaluation set
This is the single largest predictor we see. Without a scored set of real examples with expected outputs, quality is assessed by whoever last tried it, and every prompt or model change becomes an argument about vibes.
What an evaluation set needs
- Real examples from actual usage, not invented ones
- Expected outputs agreed with the people who own the domain
- The hard cases and the ones the system must refuse, not only the easy ones
- A score that runs automatically on every change
Build it in week one. It is the artefact that turns AI work from demo-driven into engineering, and teams that skip it spend the following six months unable to prove any change was an improvement. One vendor stuck in exactly that position spent four weeks building a set from four hundred real tickets and made no model changes at all, then moved from 61% to 89% correct-and-cited over the following ten.
2. The cost curve was never modelled
Pilots run on a handful of users and a generous model. Multiply by the real audience and the arithmetic sometimes stops working — particularly where every request retrieves large context or calls the most expensive model available.
- Cache the repeated questions, which are more common than anyone predicts
- Route simple work to smaller models and reserve the expensive one for the hard cases
- Bound the context: retrieving twenty passages when four suffice multiplies cost with no quality gain
- Instrument spend per feature from the first week, not after the first invoice
3. There is no failure path
In a demo, someone asks a reasonable question and gets a good answer. In production, people ask things the system was never designed for, and a confidently wrong answer is worse than a refusal.
The system needs an explicit way to say it does not know, and that behaviour needs to be tested like any other requirement.
Ground answers in retrieved sources with citations, give the system permission to decline, and route the declined cases somewhere useful. Then score the refusal behaviour on the evaluation set, because a prompt instruction alone will not hold it.
4. The data path was never agreed
This is what kills projects in regulated sectors specifically. Nobody wrote down where the data goes, under what agreement, with what retention — and the question arrives from legal or security after the build, when changing the answer means rebuilding. In a multi-tenant product it is sharper still: retrieval scoped by a filter rather than an index boundary fails by returning a confident, correct answer from another customer's documents.
Agree it first: which deployment processes the data, whether there is an agreement covering it, what is logged, and how long it is kept. It takes a fortnight at the start and stops the project at the end.
When the answer is not AI
Sometimes the workflow is deterministic and a rules engine wins on cost, latency, and explainability. Sometimes the data is too inconsistent for retrieval to work and the honest first project is fixing the data. Both are better outcomes than a system that impresses in a demo and gets quietly switched off.
Our AI development page sets out how we scope and evaluate this work, and the industry crossings — healthcare and financial services — cover the data-path constraints where they bite hardest.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
In our experience, four reasons and rarely the model: no evaluation set, so quality cannot be measured or defended; cost and latency that were never modelled at real volume; no defined behaviour for when the system does not know; and a data path that legal or security had not agreed. All four are cheap to address at the start and expensive afterwards.
A collection of real inputs with expected outputs, agreed with domain experts, scored automatically on every change. It matters because without one you cannot tell whether a change improved anything, so the project runs on opinion — and opinion does not survive contact with a sceptical stakeholder.
Cache repeated queries, route easy work to smaller models, bound the retrieved context, and put spend per feature on a dashboard from week one. Most cost overruns we see come from retrieving far more context than the answer needed, on the most expensive model available, for every single request.
Usually not first. Retrieval and prompt engineering over a hosted model solve most business problems more cheaply and are far easier to change. Fine-tuning earns its cost when you have proprietary data and a task a general model keeps getting wrong — which you can only demonstrate if you have an evaluation set.