From prototype to production: what is still missing
A good prototype is honestly unfinished. It shows one narrow case on real data and leaves out everything the proof does not need. That left-out part is the road from prototype to production. Six gaps show up almost every time: the one-off data sample becomes a continuous supply, the human beside the system becomes a defined error path, quiet operation becomes monitoring, a test login becomes clean permissions, unnoticed cost becomes limits, and a frozen state becomes a way to handle model and data change. The single biggest lever is the error path: a production system must not simply carry on in the exception case but must know when to hand over to a human. None of these gaps is a reason to avoid the prototype. They are the reason not to confuse it with a finished product.
What a Prototype Deliberately Leaves Out
A prototype is not a half-finished product. It is an honest answer to a single question: does this case work on real data. To answer it, a good prototype leaves out everything the proof does not need. It pulls the data once by hand, it fails in the exception case in front of a human, and it runs as long as someone stands beside it.
That is not a flaw, it is the point. Build monitoring, a permissions model and error handling into the prototype and you burn time on a system that may never go live. The prototype decides whether the rest is worth it at all. So the left-out part is not sloppiness, it is a deliberate sequence.
The expensive moment comes later, when a successful prototype is confused with a finished system. The demo ran, everyone was impressed, and suddenly the thing is meant to enter daily work on Monday. This is exactly where what the prototype never promised becomes visible.
| Aspect | What the prototype does | What operation needs |
|---|---|---|
| Data | one-off sample, pulled by hand | continuous, checked supply |
| Errors | a human catches them | defined path and escalation |
| Observation | someone watches during the test | monitoring and alerting |
| Access | test login, broadly granted | clean permissions, minimally given |
| Cost | noticed but harmless | limits and a view on usage |
The Six Gaps to Operation
Lay many prototype-to-operation transitions side by side and six gaps recur. They rarely appear alone, and none of them is a technical riddle. It is work you can name and plan for beforehand, instead of discovering it at go-live.
The one-off data sample has to become a continuous supply. The human beside the system has to be replaced by a defined error path that knows when to hand over. Quiet watching during the test becomes monitoring that makes quality, cost and outages visible. A broad test login becomes clean, minimally granted permissions. Unnoticed cost becomes limits, so an error does not turn into a bill. And a frozen state becomes a way to handle change, because models, prompts and data all move.
From a Data Sample to Continuous Supply
In the prototype you pull the data once. One export, a handful of examples, enough to show the case. In operation that single moment is gone. The data has to arrive every day, be current, come in the right format and still be correct when a source somewhere changes its schema.
This is the gap most often underestimated, because it looked solved in the prototype. It was not. A sample pulled once by hand says nothing about whether the same data flows reliably, lawfully and automatically. This is often where more work hides than in the AI part itself: connecting to the source systems, checking completeness, handling gaps and a plan for the day a source goes down.
The honest test is simple: does your case still run when nobody provides the data by hand. As long as the answer is no, you have a prototype, not an operation.
The Error Path Carries Operation
In the prototype the error path is a human. When something unusual comes up, someone looks, corrects and carries on. That is perfectly fine while the system runs in a test. In operation that human is gone, at least not around the clock, and the system has to know itself what to do when it becomes uncertain.
A production system must not simply carry on in the exception case as if nothing happened. It has to recognise it is at its limit and hand over to a human with context.
A clean error path answers three questions: how does the system notice it is uncertain. What does it do then, stop, ask or hand over. And who receives the case with enough context to solve it quickly. Without this path, the first unexpected input is either silently processed wrong or brings the whole flow to a halt. Both cost more than the effort of building the path beforehand.
| Symptom in operation | Real gap | What was missing before |
|---|---|---|
| System silently processes nonsense | no uncertainty threshold | a threshold and a stop |
| One error halts the whole flow | no escalation path | hand-over to a human |
| Nobody notices the outage in time | no monitoring | alert on quality and cost |
| Cost explodes overnight | no limit | a usage cap per period |
The Production-Readiness Check
Before a prototype enters daily work, answer these six questions. Where you have no clear answer is the work still missing, and before it gets expensive at go-live.
- Does the data flow automatically, current and lawful, without anyone providing it by hand?
- Does the system know its limit, and what does it do when it becomes uncertain?
- Is there an error path with clear hand-over to a named person, with context?
- Can you see in operation how quality, cost and outages develop, with an alert on deviation?
- Are permissions minimally granted, not the broad test login from the prototype?
- What happens on change to model, prompt or data source, and who checks it?
Core sentence: the jump from prototype to production is in small part AI and in large part operation. What the prototype left out is exactly the list of what to build now.
Common Misconceptions
- The prototype runs, so the main work is done.
- The prototype proves feasibility, which is the smaller part. Operation builds everything the prototype was allowed to leave out for the proof, and that is often more work than the prototype itself.
- Operation-readiness is a technical detail at the end.
- Data supply, error path and permissions are not polish, they are separate building blocks. Push them to the end and go-live reveals they make up most of the road.
Questions and Responses
- How long does the road from prototype to production take?
- It depends on the six gaps, not the AI part. If data supply is half-clear and the case is narrow, it can be quick. If a continuous connection still has to be built and an error path defined, that is the real work. The honest move is to name it before go-live instead of discovering it after.
- Does everything really have to be operation-ready before we start?
- No, but the critical gaps must be closed: reliable data and an error path. Monitoring and cost limits can start lean and grow. Permissions, on the other hand, should be clean from the start, because they are hard to tighten later.
- Can we just keep the prototype running?
- Rarely well. A prototype is built for proof, not for sustained load, resilience and supervision. Pushing it into daily work unchecked only moves the left-out work into the moment it is most expensive.
Sources and Evidence
No external statistics or client results are asserted as verified. Data, permission and cost questions are checked against the deployed stack before go-live.