# Production Launch Checklist *A stage-gated checklist for taking a software product from idea to a closed deal — where every item closes on proof, not a promise.* Engineering Square runs a version of this before every production launch. This is the genericized template: adapt the item text to your stack, keep the two rules that make it work. --- ## The two rules **Rule 1 — Stages gate.** A build cannot enter a stage until the previous stage is fully closed. You do not tune performance on a page that still throws in a core flow, and you do not chase pipeline on a product that has never been restore-tested. The order is the discipline. **Rule 2 — Close on proof, not intent.** An item is only checked when someone can point at the evidence that it is true. A backup job that is *scheduled* does not count; a backup you *restored into a scratch database and queried* does. A security header you *added to the config* does not count; a `curl -I` of the production response *showing the header* does. **Two tiers per item:** - **[M] MANDATORY** — the launch is blocked until this closes. No exceptions, no "we'll do it after go-live." - **[E] EXPECTED** — closes in the normal course of a healthy launch; a deliberate, logged exception is allowed with an owner and a date. --- ## Stage 1 — Idea *Gate question: is this worth building, and do we know what "done" means?* - [ ] **[M]** Problem statement written in one paragraph a non-engineer can repeat back. - [ ] **[M]** Primary user and the single job-to-be-done named. - [ ] **[M]** Success metric defined as a number (not "users like it"). - [ ] **[E]** Two or three alternatives considered and rejected in writing. - [ ] **[E]** Rough build/buy decision made and recorded. - [ ] **[E]** Named owner accountable for the outcome, not just the code. ## Stage 2 — Frozen (scope locked) *Gate question: is the scope specified tightly enough that "done" is unambiguous?* - [ ] **[M]** Acceptance criteria written for every in-scope capability — each one testable. - [ ] **[M]** Explicit out-of-scope list, so scope creep is a visible decision. - [ ] **[M]** Data model and the boundary of what data the system touches drawn. - [ ] **[M]** Interfaces and integration seams specified (APIs, webhooks, auth). - [ ] **[E]** Non-functional targets set: latency budget, cost ceiling, expected load. - [ ] **[E]** Rollback and failure-mode plan sketched before code, not after. - [ ] **[E]** Sign-off recorded from whoever owns the budget. Nothing goes to the bench until the drawing is signed. ## Stage 3 — Building *Gate question: is it being built instrumented, reviewed, and demoable — not in the dark?* - [ ] **[M]** Version control with protected main; no direct pushes to production branch. - [ ] **[M]** Secrets in a secret store or env, never committed. Repo scanned for leaked keys. - [ ] **[M]** Every external call wrapped in error handling with a meaningful message. - [ ] **[M]** Inputs validated at the system boundary (API edge, form submit). - [ ] **[E]** Structured logging with a consistent prefix/format from the first commit. - [ ] **[E]** Automated tests for the critical paths; CI runs them on every PR. - [ ] **[E]** Weekly demoable increment — the build is shown against the spec, not hidden until reveal. - [ ] **[E]** Dependencies pinned; a lockfile is committed. - [ ] **[E]** Feature flags for anything risky, so ship and release are separate decisions. ## Stage 4 — IT-tested (correctness & hardening verified) *Gate question: does it do what the spec says, and is it safe to expose? This is the heaviest gate.* ### Correctness - [ ] **[M]** Every critical user flow exercised end-to-end, not just unit-tested in pieces. - [ ] **[M]** Error states and empty states handled and designed — no raw stack traces to users. - [ ] **[M]** No unhandled promise rejections or console errors on any shipping page. - [ ] **[M]** Data-loss and concurrency edge cases exercised (double-submit, race on write). - [ ] **[E]** Accessibility pass: keyboard navigation, visible focus, 4.5:1 contrast, labeled forms, alt text. - [ ] **[E]** Cross-browser and mobile checked on real viewport sizes. ### Hardening - [ ] **[M]** Security headers set **and verified with a `curl -I`**: HSTS, X-Content-Type-Options nosniff, Referrer-Policy, X-Frame-Options, Permissions-Policy. - [ ] **[M]** Content-Security-Policy **enforced** (not Report-Only), using nonces/hashes — not a host allowlist with `unsafe-inline`. - [ ] **[M]** Session cookies `Secure; HttpOnly; SameSite=Lax`. - [ ] **[M]** AuthN/AuthZ verified: every mutating route requires auth; object-level access checked (no IDOR). - [ ] **[M]** No secrets in the client bundle. Verified by grepping the built assets. - [ ] **[E]** Rate limiting and a honeypot/anti-abuse control on public write endpoints. - [ ] **[E]** Dependency vulnerability scan clean, or every finding triaged with a reason. - [ ] **[E]** Privacy policy matches what the page actually loads (every script, every cookie). ### Operability - [ ] **[M]** Error tracking wired to a live DSN and a test error confirmed received. - [ ] **[M]** **Backups are restore-TESTED** — restored into a throwaway database, with a row count or query proving the dump is complete. A scheduled backup you have never restored is a hypothesis, not a safety net. - [ ] **[M]** Rollback tested by actually redeploying the previous image in staging — not "we tag our releases." - [ ] **[E]** Uptime checks on key URLs from outside the network. - [ ] **[E]** Runbook written: how to deploy, roll back, rotate secrets, and who to page. - [ ] **[E]** Migrations are reversible, or the irreversibility is a logged, owned decision. ## Stage 5 — Launched *Gate question: is it live, discoverable, and measured?* - [ ] **[M]** Deployed to production behind TLS; HTTP redirects to HTTPS. - [ ] **[M]** Unique `` and meta description per page; exactly one `<h1>`; `lang` and viewport set. - [ ] **[M]** Self-referencing canonical URLs; `sitemap.xml` lists only 200-status canonical URLs. - [ ] **[M]** `robots.txt` allows the right crawlers and ships **no** stray `Disallow: /` left over from staging. - [ ] **[M]** Analytics confirmed collecting — a real click shows up in the dashboard. - [ ] **[E]** Core Web Vitals inside budget on the key pages (LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1). - [ ] **[E]** Open Graph and Twitter card tags with a 1200×630 image; link preview checked. - [ ] **[E]** JSON-LD structured data on the pages meant to be found or cited. - [ ] **[E]** 404 and 500 pages designed, not defaults. ## Stage 6 — Sales-ready *Gate question: can someone who did not build it sell, demo, and support it?* - [ ] **[M]** A demo path that works from a cold start, with seed data, in under five minutes. - [ ] **[M]** Pricing, terms, and what's-included documented and current. - [ ] **[M]** Support channel defined with an owner and a first-response commitment. - [ ] **[E]** One-page product overview and an FAQ that answers the real objections. - [ ] **[E]** Onboarding path a new user can complete without a human. - [ ] **[E]** Status/incident communication plan for when something breaks. ## Stage 7 — Pipeline *Gate question: is demand being generated and measured, not hoped for?* - [ ] **[M]** Lead capture wired end-to-end and confirmed delivering (test submission received). - [ ] **[M]** Every inbound source tagged so you know what actually converts. - [ ] **[E]** Follow-up sequence defined with an owner; no lead sits untouched. - [ ] **[E]** Conversion funnel instrumented from first touch to qualified opportunity. - [ ] **[E]** A repeatable outbound or content motion running, not a one-off blast. ## Stage 8 — Deal closed *Gate question: did it produce the outcome the idea promised, and did we learn?* - [ ] **[M]** First paying customer (or the defined success outcome) achieved and recorded. - [ ] **[M]** The Stage-1 success metric measured against reality — hit, missed, or moved. - [ ] **[E]** Post-launch review: what the gates caught, what they missed, what to change. - [ ] **[E]** Wins and objections fed back into the product and the sales narrative. - [ ] **[E]** The checklist itself updated with anything this launch taught you. --- ## How to use this well 1. **Do not skip stages to feel faster.** Skipped gates do not disappear; they reappear as an incident at the worst possible time. 2. **When you check an item, name the artifact.** "Closed — see the restore log / the curl output / the dashboard screenshot." A check with no artifact is a hope. 3. **Let the gate pull quality upstream.** When the team knows "backups work" closes on a restore, they design backups to be restorable from day one. That upstream pull is the entire point of having a gate. > Scheduled is not tested. A backup you have never restored is a hypothesis, and production is a bad place to find out it was wrong. --- *Template by Engineering Square. Reuse freely inside your organization. Adapt the item text; keep the two rules.*