The gap is operational, not functional
Software that fulfils its requirements can still be unshippable. Production readiness is about what happens on the bad day: when a dependency is down, the input is malformed, the volume is ten times normal, or the author is unreachable.
1. Failures are visible
Errors reach somewhere a human looks, with enough context to act. Anything that fails silently will fail silently for months — the property that makes an unowned integration dangerous rather than merely untidy.
2. Someone other than the author can run it
Deployment, configuration, and recovery documented well enough that a colleague can follow them under pressure. If the only path back to a working state is in one person’s head, the system is not ready regardless of its test coverage.
Production ready means someone who didn’t build it can fix it at 2am.
3. It behaves under bad input
Malformed data, missing fields, duplicates, and unexpected volume all arrive eventually. Deciding in advance whether each is rejected, quarantined, or accepted is the same discipline that keeps a migration from silently dropping records.
4. There is a way back
A rollback path, a backup that has actually been restored at least once, and a known-good state to return to. Untested backups are a belief, not a control.
5. Access doesn’t depend on a person
Credentials on service accounts, not on individuals; permissions granted by role. This is also the layer where what a system is allowed to read gets decided, and it is far cheaper before launch than after.
6. Someone owns it
A named owner responsible for it continuing to work. Everything above decays without one, and the absence of a name is the single best predictor that a system will become a liability.