Prepares production launches. Use when preparing to deploy to production, or when asking what needs to be in place before shipping. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.

Shipping and Launch Overview Ship with confidence. The goal is not just to deploy — it's to deploy safely, with monitoring in place, a rollback plan ready, and a clear understanding of what success looks like. Every launch should be reversible, observable, and incremental. When to Use Deploying a feature to production for the first time Releasing a significant change to users Migrating data or infrastructure Opening a beta or early access program Any deployment that carries risk (all of them) The Pre Launch Checklist Code Quality [ ] All tests pass (unit, integration, e2e) [ ] Build succeeds with no warnings [ ] Lint and type checking pass [ ] Code reviewed and approved [ ] No TODO comments that should be resolved before launch [ ] No console.log debugging statements in production code [ ] Error handling covers expected failure modes Security [ ] No secrets in code or version control [ ] The ecosystem's dependency audit ( npm audit , pip audit , cargo audit , ...) shows no critical or high vulnerabilities [ ] Input validation on all user facing endpoints [ ] Authentication and authorization checks in place [ ] Security headers configured (CSP, HSTS, etc.) [ ] Rate limiting on authentication endpoints [ ] CORS configured to specific origins (not wildcard) Performance [ ] Core Web Vitals within "Good" thresholds [ ] No N+1 queries in critical paths [ ] Images optimized (compression, responsive sizes, lazy loading) [ ] Bundle size within budget [ ] Database queries have appropriate indexes [ ] Caching configured for static assets and repeated queries Accessibility [ ] Keyboard navigation works for all interactive elements [ ] Screen reader can convey page content and structure [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for text) [ ] Focus management correct for modals and dynamic content [ ] Error messages are descriptive and associated with form fields [ ] No accessibility warnings in axe core or Lighthouse Infrastructure [ ] Environment variables set in production [ ] Database migrations applied (or ready to apply) [ ] DNS and SSL configured [ ] CDN configured for static assets [ ] Logging and error reporting configured [ ] Health check endpoint exists and responds Documentation [ ] README updated with any new setup requirements [ ] API documentation current [ ] ADRs written for any architectural decisions [ ] Changelog updated [ ] User facing documentation updated (if applicable) Feature Flag Strategy Ship behind feature flags to decouple deployment from release: Feature flag lifecycle: Rules: Every feature flag has an owner and an expiration date Clean up flags within 2 weeks of full rollout Don't nest feature flags (creates exponential combinations) Test both flag states (on and off) in CI Staged Rollout The Rollout Sequence Rollout Decision Thresholds Use these thresholds to decide whether to advance, hold, or roll back at each stage: Metric Advance (green) Hold and investigate (yellow) Roll back (red) Error rate Within 10% of baseline 10 100% above baseline 2x baseline P95 latency Within 20% of baseline 20 50% above baseline 50% above baseline Client JS errors No new error types New errors at <0.1% of sessions New errors at 0.1% of sessions Business metrics Neutral or positive Decline <5% (may be noise) Decline 5% When to Roll Back Roll back immediately if: Error rate increases by more than 2x baseline P95 latency increases by more than 50% User reported issues spike Data integrity issues detected Security vulnerability discovered Monitoring and Observability What to Monitor Error Reporting Post Launch Verification In the first hour after launch: Error Budget Release Gate Your service's error budget — the fraction of requests or time your SLO allows to fail — determines whether it's safe to ship. Use it as an objective gate — not a negotiation: A high burn rate during a canary (consuming budget faster than the baseline pace) is a hold signal in the rollout thresholds table above — treat it the same as an elevated error rate. Rollback Strategy Every deployment needs a rollback plan before it happens: See Also For the project wide Definition of Done that every change must clear before this checklist, see ../../references/definition of done.md For security pre launch checks, see ../../references/security checklist.md For performance pre launch checklist, see ../../references/performance checklist.md For accessibility verification before launch, see ../../references/accessibility checklist.md For the alerting rules and SLO tied thresholds, see observability and instrumentation Common Rationalizations Rationalization Reality "It works in staging, it'll work in production" Production has different data, traffic patterns, and edge cases. Monitor after deploy. "We don't need feature flags for this" Every feature benefits from a kill switch. Even "simple" changes can break things. "Monitoring is overhead" Not having monitoring means you discover problems from user complaints instead of dashboards. "We'll add monitoring later" Add it before launch. You can't debug what you can't see. "Rolling back is admitting failure" Rolling back is responsible engineering. Shipping a broken feature is the failure. "The error rate looks fine, let's keep shipping" Check the burn rate, not just the current error rate. Consuming budget faster than baseline is a hold signal even when individual thresholds are green. Red Flags Deploying without a rollback plan No monitoring or error reporting in production Big bang releases (everything at once, no staging) Feature flags with no expiration or owner No one monitoring the deploy for the first hour Production environment configuration done by memory, not code "It's Friday afternoon, let's ship it" Error budget exhausted but feature work continues unchanged Verification Before deploying: [ ] Pre launch checklist completed (all sections green) [ ] Feature flag configured (if applicable) [ ] Rollback plan documented [ ] Monitoring dashboards set up [ ] Team notified of deployment After deploying: [ ] Health check returns 200 [ ] Error rate is normal [ ] Latency is normal [ ] Critical user flow works [ ] Logs are flowing [ ] Rollback tested or verified ready For every shipped service: [ ] Error budget policy in place: know what action to take when budget drops below 20% and when it's exhausted

shipping-and-launch