A Production Readiness Checklist for Your First Real Launch

Most product launches we have helped with were technically functional but operationally fragile. The team had a working app, but no one had asked the boring questions about what happens at 3 AM when the API stops responding, or what happens when the next intern accidentally drops a table. This checklist is the list of those boring questions.

Security

• HTTPS everywhere. Auto-renewing TLS via Let's Encrypt, AWS ACM, or Cloudflare. HSTS header set with at least 6-month max-age.
• Secrets out of the repo. No .env committed; all secrets loaded from a secret manager (AWS Secrets Manager, GCP Secret Manager, Doppler, 1Password Connect).
• Rate limiting on auth endpoints. 5 failed logins per IP per 5 minutes is a sane starting point. Anything else without rate limits is asking for credential stuffing.
• SQL injection-proof. Every database query parameterised, never string-interpolated.
• Security headers. CSP (start in report-only), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, helmet.js or equivalent.
• Dependency audit clean. npm audit or your language equivalent: zero high-severity advisories at launch.

Observability

• Application logs. Structured JSON logs going to a queryable destination (CloudWatch, Loki, Datadog, etc.). At minimum: request id, user id (if known), latency, status code, error message.
• Metrics. Request rate, error rate, p50/p95/p99 latency, CPU and memory per service. Track database connection pool utilisation if you have one.
• Error tracking. Sentry, Honeybadger, Rollbar, or self-hosted equivalent. Every unhandled exception lands in a queryable place with stack trace.
• Uptime monitoring. External pinger every 60 seconds checking a public endpoint that exercises the database (not just a static "ok"). Pingdom, Better Uptime, UptimeRobot, or Cloudflare Health Checks.
• Alerts that page someone. At least: site down for 2 minutes, error rate above threshold, disk above 80%, database connection pool exhausted. Alerts go to a channel with a human, not a quiet inbox.

Backups and recovery

• Automated backups. Database backed up at least daily, encrypted, retained for 30 days minimum.
• Tested restore. You have actually restored a backup to a fresh instance and verified the application starts. Untested backups don't exist.
• RPO and RTO defined. Recovery Point Objective (how much data can we lose?) and Recovery Time Objective (how fast must we be back online?) written down somewhere your on-call can find them.
• Off-site copies. Backups in a different region or different account from the primary database. If the primary account is compromised, you can still recover.

Performance and scale

• Load tested. A k6 or Locust run simulating at least 2x your expected day-one traffic. Note the breakpoint.
• Database indexed. Every query that runs in a hot path has an index covering it. Slow query log enabled.
• CDN configured. Static assets served via CloudFront / Cloud CDN / Cloudflare with proper cache-control headers.
• Connection pool sized. Database connection pool is sized for the actual instance class, not left at framework defaults.

Operations

• Runbook for each alert. What does this alert mean, how do I diagnose it, how do I fix it, who do I escalate to?
• One-command deploy and rollback. If rolling back the latest release requires more than two commands or a coordinated meeting, you don't have a real rollback.
• Database migrations forward-and-backward safe. No migration that drops a column the previous version still reads. Multi-step migrations for non-trivial changes.
• On-call rotation defined. Even if it is just two founders alternating weeks, write it down. Without a defined on-call, alerts go to nobody.

Compliance and admin

• Privacy policy and terms. Both linked from the footer, both reviewed by someone who knows your data flows.
• Data deletion path. An actual implemented endpoint or process for "delete my account and data". DPDP and GDPR both expect this.
• Audit trail for admin actions. Who changed what, when. At minimum for billing, user role changes, and data exports.

Pre-launch dry run

The night before launch, run through the alarms-go-off scenarios:

1. Trigger an error and confirm it lands in your error tracker.
2. Trigger an alert and confirm someone actually gets paged.
3. Restore yesterday's backup to a clean environment.
4. Roll back the last deploy and verify the previous version comes up cleanly.

If any of these fail, you are not ready to launch. The checklist isn't theatre — it's the list of items that turn a working app into a real product.