Launch-ready: the 12 checks before a product goes live
Launch day should be the most boring day of the project. This is the checklist that makes it so.
- Test the paths that make money from start to finish, automatically.
- Load test above expected peak, and make sure every alert reaches a real person.
- Rehearse rollback and restore before you need them.
- Write a runbook with named owners, and test AI features against evals and spending caps.
Hope is not a strategy, but it remains a surprisingly popular way to deploy software. We’ve seen enough launch days to know that the exciting ones are exciting for the wrong reasons.
These are the 12 checks we run before anything we build goes live. None is glamorous. All of them have, at some point, saved a weekend.
Product
- The critical paths are tested from start to finish, automatically. Sign-up, log-in, payment and the one core action your product exists for. If a human has to click through it to know it works, it isn’t tested.
- Analytics fire, and someone has looked at the dashboard. The first week of data is the most valuable you’ll ever get. Don’t discover in week three that the purchase event never fired.
- Empty, error and loading states exist. Real users meet them in the first five minutes. A blank white screen reads as “broken”, even when it’s just slow.
Reliability
- Load tested at well above expected peak. Two to three times is our usual rule of thumb. Launches attract curious people, and a mention in the press can’t be scheduled.
- Monitoring and alerts reach a human with a phone. An alert that goes to an unread channel is a diary entry, not an alert. Set up an on-call rota before launch, not after the first incident.
- Backups exist, and a restore has actually been tested. A backup you’ve never restored is a theory.
- Rollback is one command, and it’s been rehearsed. The worst time to learn how rollback works is while you need it.
- Risky features sit behind feature flags. Switching one off should be a toggle, not a redeploy.
Launch day should be boring. Boring is a feature.
Security and compliance
- Secrets are out of the repo, access is least-privilege, and dependencies are scanned. Assume someone will look. Usually someone does.
- Privacy is handled. Consent where it’s needed, retention rules, and no personal data in the logs.
- AI features have passed their evals, with guardrails and spending caps on. A runaway prompt loop can burn a monthly budget overnight. A cap turns a disaster into a notification.
People
- A launch runbook with named owners. Who flips the switch, who watches which dashboard, who talks to customers, and who has the authority to call a rollback. Add support macros, a status page and a short war-room channel. Then go home on time.
Twelve out of twelve: launch with confidence. Ten or eleven: launch, with the gaps owned and dated. Fewer than ten: you don’t have a launch date yet, you have a deadline.
The best launches are anticlimactic. The graphs go up, nothing catches fire, and the team’s biggest decision of the evening is what to order for dinner. That’s the goal.
