Every organization we talk to has a folder of proofs of concept that impressed everyone in the room and then quietly died. The pattern is so consistent it is worth naming: the prototype was never the hard part.
The last ten percent is most of the work
A prototype answers one question: can this work at all? Production answers a harder one: can this keep working, safely, without a person watching it? The distance between those two questions is where budgets and timelines quietly disappear, because it is full of work that is invisible in a demo.
What production actually demands
Turning a prototype into a system means building the parts nobody demos:
- Observability. You cannot operate what you cannot see. Every meaningful behaviour needs to be measured and alerted on.
- Evaluation. A repeatable way to know whether a change made the system better or worse, before your users find out.
- Security and data handling. Access control, data residency and least privilege, designed in rather than retrofitted.
- Pipelines. The unglamorous machinery that keeps data flowing in and results flowing out, reliably, at the right time.
- Operations. Deployment, rollback, on-call, and a plan for the day something breaks — because it will.
Design for the second system first
The teams that cross the gap do one thing differently: they design for production from the first week, even while prototyping. They keep the prototype cheap and disposable, but they make the architectural decisions — how it will be observed, secured, deployed and operated — with the production system already in mind.
That is not gold-plating. It is the difference between a prototype you can grow and a prototype you have to throw away. Choosing that path early is usually the cheapest decision in the whole project.