This is the actual checklist used before every client MVP launch — not a generic “things to remember” list, but the specific items that have caught real, launch-blocking problems across 250+ projects. Organized by what actually breaks, not by generic category.

Before anything else: the “can a stranger use this” test

Have someone who has never seen the product try to complete the core action with zero guidance from you. Watch, don’t help. The number of “obvious” UX problems this single test catches, after weeks of the founder and team being too close to the product to see them, is consistently the highest-value item on this entire checklist.

Technical readiness

• Load testing at 2-3x expected launch traffic, not just expected traffic — launches routinely exceed projections when there’s any real marketing push, and finding out your server can’t handle it during the launch is the worst possible time to find out.
• Error tracking actually configured and tested (Sentry or equivalent) — not just installed, verified to actually alert someone when something breaks. An error tracker nobody’s watching is functionally the same as no error tracker.
• Database backup verified to actually restore, not just verified to run. A backup that’s never been tested for restoration is a false sense of security, and this is discovered at the worst possible moment if it’s wrong.
• Payment flow tested with a real (small) transaction, not just sandbox mode. Sandbox and production payment gateway behavior diverge more often than expected.

Legal and compliance basics

• Privacy policy and terms of service actually reflect what the product does, not a generic template copy-pasted without review — this matters more than founders think, both for user trust and for avoiding real legal exposure.
• Data handling matches what’s claimed — if the privacy policy says data isn’t shared with third parties, verify every integrated tool (analytics, error tracking, email) actually complies with that claim.

The analytics setup that’s always forgotten

• Conversion events configured before launch, not after — the first 48-72 hours of real user data are uniquely valuable and unrecoverable if tracking isn’t correctly set up beforehand. Founders who set up analytics after noticing they should have data are missing the most information-dense window they’ll ever have.
• A dashboard the founder will actually check, not a technically complete setup nobody looks at. Per the earlier piece on founder dashboards — this needs to be simple enough to glance at daily in the first week.

The support readiness check

• A real plan for “what happens when something breaks and a user is stuck,” not just “we’ll figure it out.” Even a simple email address that’s actually monitored, with a committed response time, prevents the worst version of early user experience: someone hitting a wall with no path forward.
• The founder personally available during the first 48-72 hours post-launch, not delegated away. Early user problems reveal product issues faster than any other signal, and that signal is lost if the founder isn’t the one seeing it directly.

The one item founders resist most

A genuine plan for what “we need to pause and fix something” looks like, decided before launch, not improvised during a crisis. Founders in launch-excitement mode resist planning for problems, which is exactly when a calm, pre-decided process (who decides to pause, what the rollback looks like, who communicates to users) prevents a bad moment from becoming a much worse one.

Want an honest read on where your project actually stands? Send me a few lines about what you are building. Free 30-minute call, no pitch, no obligation. Available for founders in India and Australia. Book a Free Call →

Frequently asked questions