A demo shows that something can work. Production means it keeps working, for real users, with real data, on a day when nobody who built it is available. The gap between the two is where most software projects get into trouble.
"Production-ready" is used loosely. This article makes it concrete: what has to be true before a system should carry a real business process, and why it is worth designing for from the start.
Demo-ready versus production-ready
A demo-ready system works on the happy path, with clean data, for the person who built it. A production-ready system also handles the unhappy paths:
- Bad input: missing fields, wrong formats, duplicates.
- Many users at once, with different permissions.
- A dependency being slow or down: the payment provider, the email service, an API.
- A release that goes wrong and has to be undone.
- Data that must survive a failed server.
- A question months later: what happened to this record, and who changed it?
The checklist behind the phrase
These are the pieces we treat as part of the build, not extras for later.
- Monitoring and alerts, so you find out about a problem before your users do.
- Backups that have actually been restored at least once.
- An automated release process that can be reversed quickly.
- Access control and an audit trail for anything sensitive.
- Error handling that fails visibly and safely, not silently.
- Documentation that someone new could follow to run, deploy and fix the system.
Why it is cheaper early
Each item on that list is cheap to design in at the start and expensive to retrofit. Adding an audit trail after a year of untracked changes cannot recover the history that was never recorded. Adding access control to a system everyone already uses with full permissions means untangling who actually needs what.
Teams that treat these as part of the build ship calmer releases and spend far less time firefighting later.
A small example
Even a simple website can be production-ready or not. This site, for instance, serves pages from the server, has one canonical address per page, sends standard security headers, and its forms validate input on both the browser and the server so a malformed request can't get through. None of that is visible to a visitor. All of it matters on the day something unusual happens.
A short pre-launch checklist
Before a system carries real work, each of these should have a clear yes:
- Releases are automated, and the last release has been rolled back at least once as a rehearsal.
- A backup has been restored into a separate environment and checked.
- Alerts go to a named person, and that person has tested receiving one.
- Roles and permissions match what each kind of user actually needs, not "admin for everyone".
- Error messages tell users what to do next, and errors are logged with enough detail to fix them.
- Someone other than the original builder has followed the documentation to deploy the system.
Who owns it after launch?
A system without an owner decays: dependencies go out of date, alerts get ignored, and small fixes pile up. Before launch, decide who is responsible for updates, monitoring and changes, whether that is your own team with a proper handover or the team that built it on an ongoing basis.
Either can work. What doesn't work is assuming someone will notice.
How to tell if your system is ready
Ask what happens when it breaks. Specifically:
- Who finds out first, a monitor or a customer?
- How long does it take to roll back the last release?
- When were the backups last restored, as a test?
- Could someone other than the original builder deploy a fix?
- Can you see who changed a given record, and when?
Where this fits
Production readiness runs through all our work, and most directly through cloud & infrastructure and software development. It matters most where downtime or a bad record is costly, such as a manufacturing line or a clinic.