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 →