What "production-ready" actually means

"Production-ready" is used loosely enough to be meaningless. It is worth replacing with a specific list, because the gap between software that demos well and software a business can depend on is made of unglamorous, checkable items.

Deployment

• Deployment is a single automated action, not a documented sequence of manual steps.
• Rolling back to the previous version takes minutes and does not require the person who built it.
• Staging and production are separate environments, configured identically, with separate data.
• Secrets live in a secret store, not in the repository or a shared document.

Observability

• Application errors are captured with enough context to diagnose them without reproducing the issue.
• Logs are aggregated and searchable across instances.
• Uptime is monitored externally, and someone specific is alerted when it drops.
• You can answer "is it slow for everyone or one customer?" from data rather than by asking.

Data

• Backups run automatically, and a restore has been performed at least once as a test.
• Schema changes run through reviewed, reversible migrations.
• Personal data is identified, and there is a defined answer to a deletion request.

Operability

• A new engineer can run the project locally from the README in under an hour.
• Automated tests cover the paths where failure costs money.
• Dependencies are pinned, and there is a routine for updating them.
• Someone other than the original author can operate the system.

Not every item is required on day one, and a first release deliberately trading some of them for speed is a legitimate decision. The problem is trading them without noticing — then discovering during an incident which ones were missing.