What Changes When an AI Prototype Moves to Production?

The demo written over a weekend works. The team sees it in a meeting, management is convinced, and the decision follows: let's ship it.

Three months later the feature still isn't live, and nobody can quite explain what took so long. The code exists, the model is the same, and everyone watched it work.

The best way to understand the gap is to count the assumptions a prototype quietly makes. A demo answers one question: can this be done at all? Production has to answer a different one: what happens on a bad day?

What a demo proves, and what it doesn't

A prototype shows that the best case is possible. That is worth having — finding out it isn't possible would have cost far more later.

But a prototype says nothing about a distribution. A feature that works on twenty examples tells you nothing of the same kind about twenty thousand. And what matters in production isn't the average, it's the tail: the rare but bad outcomes.

The four assumptions below get made during the demo without anyone noticing, and their cost always surfaces afterwards.

Assumption 1: The user is you

The demo was driven by the person who knew what the feature was supposed to do. They knew what to type, how hard to push, and when the output looked odd they read it as a tuning matter rather than a defect.

Real users know none of that. They type a single word. They leave the question half-finished. They try the feature for a job it wasn't designed for — often with sound instinct, because the interface never told them where its edge was.

This isn't a user-education problem. What the prototype measured was the best output from the best input. What production meets is the full range of input quality. The cheapest thing to do before launch is to collect the first thirty attempts from real users and look at the input shapes the demo never tried.

Assumption 2: The input arrives clean

The examples used in the prototype were selected. Even when nobody admits selecting them they were selected, because the ones that didn't work got quietly dropped.

What arrives in production is this: an empty document, a four-hundred-page document, a scanned PDF with no text layer, text in the wrong language, text mixing two languages, data formatted as a table, characters mangled during a copy-paste.

Most of these don't raise an error — they do something worse and produce plausible output. A summary generated from an empty document also reads fluently. A system's ability to say "I can't work with this input" matters as much as its ability to answer correctly, and it was never written because the prototype never needed it.

Assumption 3: The provider is always up and always the same

During the demo the provider was running, fast, and answered every time. Three things break that.

Outages and limits. The provider may stop responding for a while, or you may hit a rate limit. The real question isn't technical but a product one: what does the user see at that moment? Is the work queued and reported later, or does the feature switch off and the job continue the old way? Left unanswered, the resulting behaviour is a spinner that never stops.

The latency tail. In the demo the answer came back in a few seconds. In production some calls take far longer. Timeout duration, retry count, and the cost of retrying — because each attempt is billed separately — get decided by default, badly, on the first busy day unless they are decided deliberately.

Ground that shifts. In conventional software a dependency doesn't change unless you update it. In a model-based feature, the same code can produce different output when the version underneath moves, and the retirement schedule of the version you use runs without consulting your plan. So the version should be pinned explicitly, and a sample set kept so a change can be compared against something. Without that set, "it used to be better" stays an impression and cannot be discussed.

Assumption 4: Someone is watching the output

Whoever ran the prototype saw every output. In production the feature runs with nobody looking — and this is the most expensive assumption.

In a system nobody watches, three things have to report themselves.

Quality. Conventional monitoring measures errors and response times; output quality can fall while both look normal. The practical way to catch it is running a small evaluation set built from real usage on a schedule, and counting user behaviour as a signal: how often was the output edited, ignored, or redone by hand.

Cost. In a system nobody watches, spending isn't watched either. A ceiling and an alert as it approaches is the only mechanism that keeps the invoice from being a surprise.

Records. Answering why a given result came out that way later requires the input, the version, and the output to have been recorded. What those records contain is also a data decision; how long they are kept and who can read them belongs with data security in LLM integrations.

When the feature ships, the work changes too

All four assumptions were technical. The fifth difference isn't, and it tends to be seen latest: once the feature is live, the work around it reshapes itself to fit.

Before long the team stops performing the old step. The manual check becomes rare, whoever knew how to do it moves into another role, and six months later turning the feature off costs far more than turning it on did. This is digital transformation being more than buying software at small scale.

The practical consequence is to define the way out while it is still cheap. If you can write in one sentence how the work proceeds when the feature is disabled, both a provider outage and a drop in quality stay manageable events. If you can't, a temporary fault turns straight into a stoppage.

Prototype code isn't production code

One argument recurs during the transition: build on the existing code, or start again?

A prototype's value is not in its code but in what it taught — which approach works, which inputs strain it, what the output should look like. Once that knowledge has been carried over, the code itself is usually cheap.

The real risk is prototype code staying in production undecided: nobody says "we're keeping this as it is," they simply don't change it. That is the most typical way technical debt turns into a business problem, and one explicit decision prevents it.

Launching is a curve, not a moment

Trying to solve all of these assumptions at a desk is unnecessary and slow. The cheaper route is to stage the rollout.

The internal team goes first; input variety is limited, but the most obvious breakages appear here. Then a small share of users, where the real distribution becomes visible. Then the scope widens.

Keeping review strict in the early period lets loosening it later rest on data — the same logic as tiering human oversight. The main benefit of that order is that errors land on a small audience and at a reversible scale.

In closing

The distance between a prototype and production isn't the finishing work most teams take it for. A demo proves the best case; production has to manage the bad one — and that is separate work.

Shortening that distance doesn't come from a longer prototype phase but from surfacing the assumptions early: how does input actually arrive, what happens when the provider goes quiet, who notices when quality drops. Once those three are answered, the remaining work becomes predictable.

In our AI integration work, a prototype phase counts as successful to the extent that it produces answers to those questions — showing that the thing works is not enough on its own.