Why AI projects die between the prototype and production

The pattern is consistent enough to be predictable. Someone builds a prototype in a fortnight, it demos beautifully, everyone is enthusiastic, budget appears. Then six months pass and there is still nothing anyone outside the team can use.

This is not because the team is weak or the technology is immature. It is because a prototype and a production system are different artefacts, and almost everything that makes the second one hard was deliberately skipped to build the first one quickly. The demo was not a smaller version of the product. It was a different thing that happens to look similar.

Here is what gets skipped, in roughly the order it comes back to bite.

The prototype ran on clean data

Almost every prototype is built against a curated sample — a few hundred records someone picked because they were representative. Production data is not representative. It has records from a system that was migrated twice, fields that mean different things depending on which decade they were entered, nulls where the schema says there cannot be nulls, and encodings that fail on one row in ten thousand.

The prototype does not have to handle any of that, and often the person who built it does not know it exists. The first real engineering problem in most AI projects is not the model. It is that nobody has ever looked at the actual data end to end.

Nobody defined what correct means

This is the one that kills most projects, and it rarely gets named as the cause.

In ordinary software, correctness is mostly decidable. The invoice total is right or it is not. In a system built on a language model, a large share of outputs are judgement calls, and if nobody has written down what a good answer looks like, then the project has no definition of done. Work continues indefinitely because there is no criterion that would let anyone say it is finished.

Symptoms are easy to spot once you know them: quality is discussed in adjectives, the team cannot tell you whether last week's change made things better or worse, and every stakeholder demo turns into someone finding a bad example and the team reacting to it.

The fix is unglamorous. Build a set of test cases with expected outcomes before building the feature — a few hundred real inputs, with a human judgement on each of what the system should have done. That set is the specification. Without it you are not engineering, you are redecorating.

The last twenty per cent is most of the work

A prototype that handles the common case gets to something impressive in days, which is exactly why prototypes are so persuasive and so misleading. The distribution of real inputs has a long tail, and the tail is where the work lives: the unusual document format, the ambiguous request, the input that is technically valid and semantically nonsense.

The tail cannot be reasoned about in advance, only discovered. That is an argument for getting a narrow path into production early with real users, rather than perfecting the demo. A system handling one workflow for ten real people teaches you more in a week than three more months of prototype refinement.

Cost and latency were never measured

In a demo, per-request cost is irrelevant and nobody is timing it. In production both are product decisions.

Work out the unit economics before building: cost per request multiplied by realistic volume, and where that lands relative to what the feature is worth. Plenty of AI features are technically sound and economically absurd, and it is much cheaper to discover that on a spreadsheet than after the build. The same goes for latency — a chain of model calls that feels fine when you are demoing it can be unusable when someone is waiting on it fifty times a day.

There is no plan for being wrong

A demo has no failure mode, because the person running it steers away from the cases that break it. A production system needs an answer to what happens when the model is confidently wrong — and it will be.

• Can the system tell when it is uncertain, and hand off rather than guess?
• Is there a human review path for the cases that matter, and does someone own that queue?
• Can a user tell they are looking at a generated answer, and challenge it?
• When something goes wrong, can you reconstruct why afterwards — inputs, retrieved context, and what came back?
• If the provider changes the model underneath you, would you find out from your monitoring or from a customer?

None of these are model problems. They are systems design, and they are most of the difference between a prototype and something a business can depend on.

Retrieval was assumed to work

For anything answering questions over your own documents, the model is rarely the weak component. Retrieval is. If the right passage is not in the context, no amount of prompt work will produce a correct answer, and the failure looks like a model failure — so teams spend weeks tuning prompts against a retrieval problem.

Measure retrieval separately from generation. For a set of real questions, was the passage containing the answer actually retrieved? That single number explains most quality complaints in most document-based systems, and it is measurable without touching the model at all.

Sometimes the honest answer is that you do not need this

We build AI systems, so this costs us something to say: a meaningful share of the projects we are asked to look at would be better served by something simpler.

If the task is genuinely rule-shaped — a fixed set of categories, a deterministic decision, a form that needs validating — then rules are cheaper to build, cheaper to run, testable in the ordinary way, and explainable to a regulator. Language models are the right tool when the input is genuinely unstructured or the judgement is genuinely fuzzy. They are an expensive and unpredictable way to do work that a lookup table does perfectly.

The tell is whether you can write the rules down. If a domain expert can describe the decision procedure in an afternoon, write it as code.

How to tell if your project is in trouble now

1. 01You cannot state, in a sentence, what a correct output looks like. Everything else follows from this.
2. 02There is no test set. Quality is assessed by someone trying a few things and forming an impression.
3. 03The team cannot say whether this week is better than last week. Without measurement, effort and progress stop being related.
4. 04It has never run against unfiltered production data. The timeline is built on a sample somebody chose.
5. 05Nobody has calculated cost per request at real volume.
6. 06The demo has been rebuilt more than once and still is not in front of a user.

If more than two of those are true, the problem is not that the system needs more work. It is that nobody can currently tell what work would count as progress.

What we would do instead

Define correct first, as a test set of real cases with human judgements attached. Build the measurement before the feature. Get one narrow path all the way to production with real users early, so the long tail starts teaching you while it is still cheap. Work out the unit economics before committing. Design the failure path as a first-class part of the system rather than an afterthought.

None of that is exotic. It is ordinary engineering discipline applied to a component that happens to be probabilistic — which is precisely what tends to get abandoned in the excitement of a demo that works.