Production Launch Checklist

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. It gates a build across eight stages — idea, frozen, building, IT-tested, launched, sales-ready, pipeline, deal closed — and every item closes on proof rather than a promise.

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.

Every item carries one of two tiers. MANDATORY [M] blocks the launch until it closes — no exceptions, no 'we'll do it after go-live.' EXPECTED [E] 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?

• Problem statement written in one paragraph a non-engineer can repeat back.Mandatory
• Primary user and the single job-to-be-done named.Mandatory
• Success metric defined as a number (not 'users like it').Mandatory
• Two or three alternatives considered and rejected in writing.Expected
• Rough build/buy decision made and recorded.Expected
• Named owner accountable for the outcome, not just the code.Expected

Stage 2 — Frozen (scope locked)

Gate question: is the scope specified tightly enough that 'done' is unambiguous?

• Acceptance criteria written for every in-scope capability — each one testable.Mandatory
• Explicit out-of-scope list, so scope creep is a visible decision.Mandatory
• Data model and the boundary of what data the system touches drawn.Mandatory
• Interfaces and integration seams specified (APIs, webhooks, auth).Mandatory
• Non-functional targets set: latency budget, cost ceiling, expected load.Expected
• Rollback and failure-mode plan sketched before code, not after.Expected
• Sign-off recorded from whoever owns the budget. Nothing goes to the bench until the drawing is signed.Expected

Stage 3 — Building

Gate question: is it being built instrumented, reviewed, and demoable — not in the dark?

• Version control with protected main; no direct pushes to production branch.Mandatory
• Secrets in a secret store or env, never committed. Repo scanned for leaked keys.Mandatory
• Every external call wrapped in error handling with a meaningful message.Mandatory
• Inputs validated at the system boundary (API edge, form submit).Mandatory
• Structured logging with a consistent prefix/format from the first commit.Expected
• Automated tests for the critical paths; CI runs them on every PR.Expected
• Weekly demoable increment — the build is shown against the spec, not hidden until reveal.Expected
• Dependencies pinned; a lockfile is committed.Expected
• Feature flags for anything risky, so ship and release are separate decisions.Expected

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, split three ways.

Correctness

• Every critical user flow exercised end-to-end, not just unit-tested in pieces.Mandatory
• Error states and empty states handled and designed — no raw stack traces to users.Mandatory
• No unhandled promise rejections or console errors on any shipping page.Mandatory
• Data-loss and concurrency edge cases exercised (double-submit, race on write).Mandatory
• Accessibility pass: keyboard navigation, visible focus, 4.5:1 contrast, labeled forms, alt text.Expected
• Cross-browser and mobile checked on real viewport sizes.Expected

Hardening

• Security headers set and verified with a curl -I: HSTS, X-Content-Type-Options nosniff, Referrer-Policy, X-Frame-Options, Permissions-Policy.Mandatory
• Content-Security-Policy enforced (not Report-Only), using nonces/hashes — not a host allowlist with unsafe-inline.Mandatory
• Session cookies Secure; HttpOnly; SameSite=Lax.Mandatory
• AuthN/AuthZ verified: every mutating route requires auth; object-level access checked (no IDOR).Mandatory
• No secrets in the client bundle. Verified by grepping the built assets.Mandatory
• Rate limiting and a honeypot/anti-abuse control on public write endpoints.Expected
• Dependency vulnerability scan clean, or every finding triaged with a reason.Expected
• Privacy policy matches what the page actually loads (every script, every cookie).Expected

Operability

• Error tracking wired to a live DSN and a test error confirmed received.Mandatory
• 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.Mandatory
• Rollback tested by actually redeploying the previous image in staging — not 'we tag our releases.'Mandatory
• Uptime checks on key URLs from outside the network.Expected
• Runbook written: how to deploy, roll back, rotate secrets, and who to page.Expected
• Migrations are reversible, or the irreversibility is a logged, owned decision.Expected

Stage 5 — Launched

Gate question: is it live, discoverable, and measured?

• Deployed to production behind TLS; HTTP redirects to HTTPS.Mandatory
• Unique title and meta description per page; exactly one h1; lang and viewport set.Mandatory
• Self-referencing canonical URLs; sitemap.xml lists only 200-status canonical URLs.Mandatory
• robots.txt allows the right crawlers and ships no stray Disallow: / left over from staging.Mandatory
• Analytics confirmed collecting — a real click shows up in the dashboard.Mandatory
• Core Web Vitals inside budget on the key pages (LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1).Expected
• Open Graph and Twitter card tags with a 1200×630 image; link preview checked.Expected
• JSON-LD structured data on the pages meant to be found or cited.Expected
• 404 and 500 pages designed, not defaults.Expected

Stage 6 — Sales-ready

Gate question: can someone who did not build it sell, demo, and support it?

• A demo path that works from a cold start, with seed data, in under five minutes.Mandatory
• Pricing, terms, and what's-included documented and current.Mandatory
• Support channel defined with an owner and a first-response commitment.Mandatory
• One-page product overview and an FAQ that answers the real objections.Expected
• Onboarding path a new user can complete without a human.Expected
• Status/incident communication plan for when something breaks.Expected

Stage 7 — Pipeline

Gate question: is demand being generated and measured, not hoped for?

• Lead capture wired end-to-end and confirmed delivering (test submission received).Mandatory
• Every inbound source tagged so you know what actually converts.Mandatory
• Follow-up sequence defined with an owner; no lead sits untouched.Expected
• Conversion funnel instrumented from first touch to qualified opportunity.Expected
• A repeatable outbound or content motion running, not a one-off blast.Expected

Stage 8 — Deal closed

Gate question: did it produce the outcome the idea promised, and did we learn?

• First paying customer (or the defined success outcome) achieved and recorded.Mandatory
• The Stage-1 success metric measured against reality — hit, missed, or moved.Mandatory
• Post-launch review: what the gates caught, what they missed, what to change.Expected
• Wins and objections fed back into the product and the sales narrative.Expected
• The checklist itself updated with anything this launch taught you.Expected

How to use this well

1. 01Do not skip stages to feel faster. Skipped gates do not disappear; they reappear as an incident at the worst possible time.
2. 02When you check an item, name the artifact — 'Closed, see the restore log / the curl output / the dashboard.' A check with no artifact is a hope.
3. 03Let 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.