A launch readiness checklist for production software

This is close to the checklist we use internally before a launch. It is not exhaustive and it is not a substitute for judgement, but if you cannot answer these questions the launch is not ready.

Reliability

• Every critical path has an automated test that runs in the pipeline
• The system degrades gracefully when a dependency is down, and you have tested that rather than assumed it
• Load has been tested at a realistic multiple of expected launch traffic
• Database migrations are backward compatible and have been rehearsed against a production sized copy
• There is a documented, tested rollback for both code and schema

Security

• Authentication and authorisation are enforced on the server for every endpoint, not just hidden in the UI
• Secrets are in a secret manager, not in config files or the repository
• Dependencies have been scanned and the known criticals are resolved
• Personal data is encrypted in transit and at rest, and you know exactly what you store and why
• Rate limiting and input validation are on anything public

Observability

• Structured logs, centralised, searchable, with correlation IDs across services
• Metrics for the four signals that matter: latency, traffic, errors, saturation
• Alerts that page a human are tied to symptoms users feel, not to causes
• A dashboard someone can open during an incident and understand in ten seconds
• You can answer is it just this one customer or everyone in under a minute

Support and operations

• Someone is on call, they know they are on call, and they have access to fix things
• There is a runbook for the top few likely failures
• The support team knows the launch is happening and how to escalate
• You have a status page or an agreed way to communicate an incident
• A named person owns the decision to roll back, and everyone knows who it is

The launch itself

• Roll out progressively: internal, then a small percentage, then everyone
• Watch the dashboards for a full traffic cycle, usually a day, before calling it done
• Keep the previous version deployable for at least a week
• Schedule the retro before the launch, while you still intend to have one