The Pre-Launch Checklist Every MVP Forgets

Your MVP works on staging. The demo runs clean. The founders are excited. You're three days from launch.

Here's the problem: "working in staging" and "ready for production" are different systems. The gap between them is where MVPs break on day one — usually for reasons nobody thought to check.

This is the checklist we run before any MVP goes live. Nothing on it is glamorous. Everything on it has saved a launch at least once.

Observability: Can You See What's Happening?

If you can't see it, you can't fix it. Before launch, confirm:

Error tracking is wired up and you've verified a test error shows up in the dashboard (Sentry, Rollbar, or equivalent)
Structured logs are flowing somewhere you can query — not just console.log on a server nobody SSHs into
Uptime monitoring pings a health endpoint every minute and will page someone when it fails
Basic metrics — request rate, error rate, response time — are visible on a single dashboard

The test for all of these: trigger a failure on purpose, and confirm you find out about it within five minutes. If that doesn't happen, you're flying blind.

Secrets and Environment

The number of launches derailed by a hardcoded API key or a staging database URL is higher than anyone admits.

No secrets in source control. Run git grep -i "api_key\|secret\|password" and audit every hit.
All config comes from environment variables, not hardcoded values
Production environment variables are set, documented, and backed up somewhere other than your laptop
Third-party API keys are production keys with correct permissions, not staging keys that silently fail after 1,000 requests

Database: The Part That's Hard to Undo

Code you can roll back. Databases you often can't.

Backups run automatically — and you've tested a restore to a scratch database. "We have backups" means nothing until you've recovered from one.
Migrations have been run against a copy of production data, not just the empty staging schema. Migrations that work on 100 rows can lock a table for 20 minutes on 100,000.
Indexes exist for the queries your app actually runs. Turn on slow query logging for an hour of normal use and fix anything over 100ms.
Connection pooling is configured with a sensible max. The default in many frameworks will exhaust your database under mild load.

Security: The Boring Basics

You don't need a penetration test for an MVP. You do need the basics.

HTTPS everywhere, with HSTS enabled
Rate limiting on authentication endpoints (login, password reset, signup)
Input validation on every public endpoint, not just the frontend form
Dependencies audited (npm audit, composer audit, etc.) with known vulnerabilities addressed
File uploads restricted by type and size, stored outside the web root
CORS configured to match your actual domains, not *

The Human Part

Launches fail in ways the code didn't predict. Have these ready:

A status page (or at least a known URL) where users can see if the service is degraded
A support email that reaches a human, not /dev/null
A rollback plan that takes less than 10 minutes to execute. If the launch goes sideways at 2am, what do you revert to?
On-call clarity — one person is responsible for the first 48 hours. Not "the team." One person with a phone.

The Pre-Flight Test

One hour before launch, run through this:

Open the live site from a browser you've never used it in
Sign up with a real email
Complete the core flow end-to-end
Open the error tracker — is the test session clean?
Open your logs — are they readable?
Kill the process and confirm monitoring pages you within two minutes

If all six pass, you're launching. If not, you're not.

The Real Checklist Is Shorter Than You Think

Most of this list exists because small teams skip it in the rush to ship. None of it is hard. All of it is boring.

The difference between an MVP that survives its first week and one that burns a weekend is usually just: did someone take an hour to go through a list like this one?

Take the hour.