The 48-hour preflight
The last two days before launch have one job: prove the plan works while there's still time to fix it. No new features. No "quick wins." Verification only.
T-48 hours: freeze and verify
- Freeze the scope. Write down exactly what is launching — pages, features, integrations. Anything not on the list is not launching. New ideas go on the post-launch list, not into the build.
- Run the full assessment. Take the Launch Readiness assessment now, not on launch morning. Every critical blocker must be resolved before you proceed; highs should be resolved or explicitly accepted in writing (even if "writing" is a note to yourself).
- Lower DNS TTLs to 300 seconds if a cutover is coming (see the DNS cutover playbook). This is the step everyone forgets until it's too late.
- Confirm the rollback plan is written and the previous production artifact is retained and restorable. If you can't name the exact command or click-path to roll back, you're not ready.
T-24 hours: the staging pass
- Deploy the exact launch build to staging. Not "equivalent to" — the exact artifact, commit, or bundle going to production.
- Walk every critical flow end to end on staging: signup, login, checkout or lead capture, contact forms, password reset, and the onboarding sequence. Use real-ish data, not just the happy path — try the expired card, the duplicate email, the 500-character name.
- Check every page on mobile. Not in a resized desktop browser — on an actual phone, or at minimum a real device emulator at 390px width. Navigation, forms, and CTAs all get tapped, not just viewed.
- Verify third-party integrations with production keys in staging: payment processor webhooks, email delivery, analytics events, error reporting. Staging keys and production keys fail differently.
- Proofread the launch surfaces one last time: homepage, pricing, signup, and the launch announcement itself. Read them aloud — your ear catches what your eyes skip.
T-12 hours: drills
- Backup and restore drill. Trigger a real backup, then restore it to a scratch environment and confirm the app boots and data is intact. An untested backup is a hope, not a plan.
- Rollback rehearsal. Walk through the rollback runbook step by step against staging. Time it. If it takes 40 minutes, you now know your worst-case recovery time — plan launch-day staffing around it. (Full detail: rollback runbook.)
- Schedule the launch comms. Announcement post, changelog entry, social posts, emails — drafted, reviewed, and scheduled or queued. Writing these on launch day, mid-adrenaline, is how typos and wrong links ship.
- Charge everything, clear the calendar. Launch day needs the decision-maker available and reachable. If you're a team of one, that means no meetings, no errands, phone charged, alerts on loud.
T-2 hours: final checks
- Confirm monitoring dashboards are open and alerting routes are tested (send a test alert; confirm a human receives it).
- Confirm the on-call roster: who acknowledges alerts, the escalation contact, and how to reach them.
- Verify the production deploy path one more time — credentials, permissions, and the exact sequence.
- Take a final backup or snapshot of the current production state (for relaunches) or confirm the fresh environment is clean (for first launches).
The go/no-go decision
Make this call explicitly — out loud, or written in a note — using criteria you set before the 48-hour window, not during it. Sane defaults:
- GO if: zero critical blockers, all critical flows pass on the exact launch build, rollback rehearsed, monitoring alerting a human.
- NO-GO if: any critical blocker is unresolved, the rollback drill failed, or a critical flow fails on the launch build. A delayed launch costs a day; a broken launch costs trust.
The hardest part of the preflight is the no-go. If the criteria say no-go, say no-go. Launching to hit a date you invented is how 48 hours of discipline gets thrown away in 48 seconds of optimism.
Common preflight mistakes
- Testing a different build than the launch build. "It's the same except for this one config change" is how launches break.
- Skipping the restore drill because backups "obviously work." They obviously work until the day they don't.
- Adding "one small thing" during the freeze. The freeze is the whole point; small things have the largest blast radius per line of code.
- Writing launch comms on launch day. Schedule them now, while you're calm.
Next step: run the score now — 24 questions, about 5 minutes — and work the blocker list before the clock starts. Run the score →