A prototype and a production system can look identical in a screen share. Both take the input, both produce the output, both are impressive. The difference shows up on the days when things do not go to plan, which in a real operation is most days.
This is why so many pilots stall at rollout. The prototype was never wrong. It was just never asked to survive contact with reality.
The happy path is a small fraction of the work
Demos run the case the system was designed around. Production runs everything else: the malformed input, the duplicate record, the customer whose name breaks the parser, the PDF that turns out to be a scanned photograph of a PDF.
Handling these is unglamorous and it is most of the build. As a rough rule, getting the main path working is perhaps a third of the effort. The rest goes into everything that deviates from it.
Failure has to be graceful and visible
A prototype that fails throws an error and stops. A production system has to fail in a way that is safe and noticed:
- It must not leave work half-completed with no record of where it stopped
- It must retry what is worth retrying, and only that
- It must tell somebody. Silent failure is worse than loud failure, because it erodes trust invisibly
- It must degrade rather than collapse when a dependency is unavailable
You cannot operate what you cannot see
Production systems need instrumentation: what ran, how long it took, how often it escalated, where the exceptions cluster. Without it, the only available signal is a person noticing something feels off, which arrives late and is hard to act on.
Monitoring is also what makes improvement possible. The exception log is the roadmap for the next iteration. It tells you which edge cases are frequent enough to be worth handling properly.
Integration is where the time goes
A demo can read from a spreadsheet someone prepared. Production has to authenticate against your CRM, respect its rate limits, cope with its scheduled maintenance window, and handle the fact that a field which is supposed to hold an email address sometimes contains two email addresses and a phone number.
None of this is difficult in isolation. All of it takes time, and it is the part most consistently underestimated at the quoting stage.
Security and access are not a later step
Who can trigger this? What can it reach? What leaves your environment, and to which third party? What happens to credentials when someone leaves the company?
Retrofitting these answers onto a working prototype is much harder than designing for them up front. It is also the stage at which many pilots quietly die, not because the answers are bad, but because nobody had them ready when the question was finally asked.
The test is whether it runs without you
A useful definition: a system is production-ready when the people who built it can stop paying attention to it. Not when it works, and not when it demos well. When it can be left alone.
That standard sets the scope of the work. It is why we treat error handling, monitoring, integration and security as part of the build rather than hardening to be done later. Later tends not to arrive, and a system that needs babysitting is a system your team will eventually route around.