shipping-and-launch

A pre-launch checklist covers six areas: code quality (tests, lint, reviews), security (no secrets, dependency audits, CORS), performance (Core Web Vitals, N+1 queries), accessibility (WCAG 2.1 AA), infrastructure (env vars, migrations, health checks), and documentation. All sections must pass before deploying.

Deploy with the flag off, enable for internal team first, then canary to 5% of users, and increase gradually to 25%, 50%, and 100%. Monitor error rates and latency at each stage for 24-48 hours, advancing only when metrics stay within baseline thresholds.

Roll back immediately when error rate exceeds 2x baseline, P95 latency rises more than 50%, user-reported issues spike, or data integrity or security problems appear. Feature flag rollbacks take under a minute; redeploying a previous version takes under five minutes.

An error budget release gate uses your SLO's allowed failure fraction to decide if shipping is safe. Above 20% budget remaining you ship normally, 0-20% means slow rollouts only, and exhausted budget freezes feature work until reliability is restored.

Monitor application metrics (error rate, p50/p95/p99 latency, request volume), infrastructure metrics (CPU, memory, database connections, disk), and client metrics (Core Web Vitals, JavaScript errors). In the first hour, verify the health endpoint, error dashboards, and the critical user flow manually.

Yes. Every deployment carries risk, and even simple changes can break production. A feature flag acts as a kill switch, and a documented rollback plan with trigger conditions ensures recovery in minutes rather than hours.