What We Actually Check in a Pre-Launch Readiness Review

QA testing answers one question: does the product work correctly. A pre-launch readiness review answers a different set of questions entirely - is everything around the product ready for it to actually go live. We treat these as separate steps on purpose, because a product can pass every functional test and still launch into real trouble if the surrounding pieces weren't checked.

Rollback Readiness Comes First

Before anything else, we confirm there's a clear, tested way to revert if something goes wrong after launch - not a theoretical plan, but a rollback path that's actually been verified to work. A launch without a confirmed rollback plan means the first serious issue after going live gets solved improvised, under pressure, which is exactly the wrong time to be figuring out how to undo a deployment for the first time.

Monitoring and Alerting Have to Be Live Before Users Are

We confirm that monitoring is actually capturing the right signals and that alerts are configured to notify the right people, before real traffic hits the system - not set up as a follow-up task for after launch. A launch with monitoring added afterward means the first hours of real usage, often the highest-risk window, happen with the least visibility into whether anything's actually going wrong.

We Verify the Support Plan Actually Exists, Not Just That It Was Discussed

Following what we've written about scoping post-launch support, the readiness review confirms that plan is fully in place before launch, not just agreed to in principle - who's covering what, what the response expectations are, and that whoever's on point for early post-launch support actually knows they're on point. A support plan that exists only as a general understanding isn't a plan yet.

Data and Backup Verification

We confirm production data backups are actually running and, critically, that a restore has been tested recently - a backup that's never been tested restoring is an assumption, not a safeguard. This matters even more for launches involving data migration, where we specifically verify the migrated data against the source before considering the migration itself launch-ready.

Load Expectations Get a Sanity Check

We revisit expected launch-day traffic against what was actually load-tested, and flag any gap between the two rather than assuming the original testing assumptions still hold by launch day - expected usage sometimes shifts between when testing happened and when launch actually occurs, particularly if there's been marketing or announcement activity that changes the realistic traffic picture.

Access and Permissions Get a Final Check

We verify that the people who need production access actually have it, and - just as important - that access which shouldn't exist anymore, from earlier in development, has been revoked. This is a small, easy-to-skip check that we treat as mandatory specifically because access cleanup is exactly the kind of unglamorous task that's easy to defer indefinitely if it isn't a hard gate before launch.

What This Review Doesn't Replace

This isn't a substitute for QA, and it isn't a substitute for the testing-in-production strategies we use for things that can only be validated with real traffic. It's specifically focused on the operational readiness surrounding the product - the parts that don't show up in a functional test but absolutely show up if something goes wrong in the first week live.

Why We Treat This as a Hard Gate

Every item above has, at some point on some project, been the actual cause of an otherwise avoidable post-launch problem - not because the product itself was broken, but because something around it wasn't ready. Treating this review as optional or as a quick formality defeats its purpose. It's a deliberate, separate checkpoint precisely because "the product works" and "we're ready to launch it" are two different claims, and we don't move forward until both are actually true.