Skip to content
Back to Launch & Discoverability

Pre-Launch Checklist

A comprehensive gate-check before opening your product to real users — infrastructure, content, analytics, support, and legal readiness.

Why

A pre-launch checklist turns a chaotic, hope-based launch into a deterministic, gate-based one. Every item you forget becomes a user-facing failure: a broken signup, an untested payment, a 404 on the marketing page, a support inbox nobody monitors. The checklist forces the team to verify readiness across infrastructure, content, analytics, support, and legal in one pass, so launch day is execution rather than discovery. Products that skip this step ship visible bugs to their first cohort and spend the first week firefighting instead of learning. A signed-off checklist is also the artifact that lets stakeholders agree the product is actually ready, not just 'code-complete'.

When

When code is feature-complete and merged to main, but before any public URL is accessible. Run the checklist 1-2 weeks before the target launch date so failures have time to be fixed.

How

1. Infrastructure: verify production build deploys clean, DNS resolves, SSL certificate is valid, CDN cache is purged, error monitoring (Sentry) is wired, uptime monitor is active
2. Functional smoke test: complete the top 3 user journeys end-to-end on production (signup, core action, payment if applicable) with a fresh account
3. Content: every marketing page has final copy, OG images render in the Facebook/Twitter/LinkedIn card validator, favicon and app icons are deployed
4. Analytics: page-view events fire on all key pages, conversion funnels are configured, the dashboard shows data within 5 minutes of a test visit
5. Support: help@ inbox is monitored, status page is live, in-app help/feedback widget is wired, the FAQ page answers the top 10 anticipated questions
6. Legal: privacy policy and terms of service are published, cookie banner is present if required, GDPR/data-deletion endpoint works
7. Rollback plan: document the deploy SHA, the rollback command, and the decision-maker who can authorize rollback
8. Sign-off: each section owner marks their item green; launch is authorized only when all items are green

Example

# Pre-Launch Checklist — ez4code v2.0
Date: 2026-10-04  Owner: @launch-lead

## Infrastructure
[x] Production build deploys clean (wrangler pages deploy)
[x] DNS: ez4code.com resolves to Cloudflare Pages
[x] SSL: A grade on ssllabs.com
[x] Sentry: error rate < 0.1% on staging
[ ] Uptime monitor: UptimeRobot 5-min ping  <-- FAILING

## Functional
[x] Signup → dashboard → create project → deploy
[x] Payment: Stripe checkout + webhook + invoice
[ ] Password reset email arrives in < 30s  <-- SLOW

## Content
[x] /launch, /growth, /maintenance pages final
[x] OG image: 1200x630, renders in validator
## Analytics
[x] GA4 page_view fires on all 47 pages
[x] Conversion funnel: visit → signup → deploy
## Support
[x] [email protected] → Zendesk, 4h SLA
[x] status.ez4code.com live
## Legal
[x] /privacy and /terms published
[x] Cookie banner: OneTrust
## Rollback
SHA: a1b2c3d  Rollback: wrangler pages deploy --branch=prev
Decision-maker: @cto

## Sign-off
Infra: GREEN  Functional: AMBER  Content: GREEN
Analytics: GREEN  Support: GREEN  Legal: GREEN
=> NOT READY: 2 amber items must be green before launch

Common Problems

  • ⚠Treating 'code-complete' as 'launch-ready' — the checklist exists precisely because the two are different; code-complete means features work, launch-ready means users won't hit obvious failures.
  • ⚠Running the checklist on staging instead of production — staging and prod diverge (different env vars, different data, different CDN); verify on the actual deployment target.
  • ⚠No rollback plan because 'we'll just fix forward' — when the deploy breaks signup for 1000 new users in the first hour, fix-forward is too slow; you need a 30-second rollback.
  • ⚠Checking items by asking 'is it done?' instead of verifying — the checklist owner must click the link, run the command, see the data; verbal confirmation hides gaps.

Best Practices

  • ✓Make the checklist a single shared document (Notion/Linear) with one owner per section and a deadline; 'shared' means everyone sees amber/red items in real time, not in a weekly sync.
  • ✓Automate every item that can be automated (deploy health, SSL expiry, analytics fire, uptime) into a CI gate; humans verify only the subjective items (copy quality, FAQ completeness).
  • ✓Add a 'dark launch' step: deploy to production behind a feature flag with 0% rollout, run the checklist against the real prod environment, then ramp rollout — this catches prod-only issues before any user sees them.
  • ✓Keep the checklist versioned in git alongside the code; it evolves with the product and becomes an audit trail of what 'ready' meant at each launch.