# What "production-ready" actually means

> "It works" and "it is ready for production" are different claims. The gap between them is where most late-night incidents live. A checklist for the difference.

*Source: https://www.lazlosoftwaresolution.com/resources/what-production-ready-actually-means*

Software that works on a developer's machine and software that is ready to carry real customers are two different things. The gap between them is not features — it is everything that decides what happens when the system is under load, at 2am, with no one watching.

Here is what we mean when we say something is production-ready.

## You find out about problems before your customers do

Monitoring and alerting that tell you when something is wrong — error rates, latency, the queue that is backing up — and that reach a human who can act. A system without this is not being run; it is being hoped for.

## Backups exist and have actually been restored

Everyone has backups. Far fewer have tested restoring them. A backup you have never restored is a guess, and you do not want to discover it was wrong during an incident. Restoring should be a rehearsed, boring procedure.

## You can undo a bad deploy quickly

Things will ship broken occasionally. What separates a minor blip from an outage is whether you can roll back in minutes without drama. If the answer to "how do we undo this" is a tense conversation, it is not ready.

## Security is designed in, not configured later

Encryption, sensible access control, tenant isolation, and secrets that are not sitting in the code. These are not a hardening pass before launch — they are decisions from the architecture stage, because retrofitting them is far harder than building them in.

 - Monitoring and alerts that reach a person.

 - Backups that have been restored at least once.

 - A tested, fast rollback path.

 - Sensible limits so one tenant cannot exhaust the system for everyone.

 - Logs you can search when you need to understand what happened.

## It degrades instead of collapsing

Dependencies will be slow or down. A production-ready system has decided in advance what happens then — a timeout, a fallback, a feature that quietly turns off — so a third party's bad day does not become yours.

> "Production-ready" is not a feeling. It is a set of specific answers to the question: what happens when this goes wrong?

## Why it is worth the extra effort

None of this shows up in a demo, which is exactly why it gets skipped under deadline pressure. But it is the difference between a launch you can sleep through and one that owns your nights. It is cheaper to build in than to add after the first incident teaches you why it mattered.