
The MVP Launch Checklist: 20 Things to Verify Before Going Live
Launch is a process, not an event. Work through 20 checks in four groups: legal (imprint, privacy policy, consent, processor agreements), technical (a backup you've actually restored, error tracking, rate limits), measurement (one activation metric, defined in writing), and operations (rollback path, support inbox). Then soft-launch to 20 friendly users before any public date.
We've taken 30+ MVPs live, and the launches that go wrong rarely fail on code. They fail on a missing AV contract, a backup nobody ever restored, or a founder duo that didn't decide who wakes up at 3 a.m.
What legal checks does a launch in Germany need?
- Imprint reachable from every page, including error pages.
- Privacy policy that describes what you actually collect — not a template for a product you don't run.
- Cookie consent that genuinely blocks non-essential scripts until consent, not a banner over already-loaded trackers.
- Processor agreements (Art. 28 DSGVO) with every vendor touching personal data: hosting, analytics, email, error tracking.
- Data location matches what the privacy policy promises — EU regions where you said EU.
Is the product technically ready?
| # | Check | How to verify |
|---|---|---|
| 6 | Backups | Restore one into a fresh environment — a backup you haven't restored is a hope |
| 7 | Error tracking | Throw a test exception, confirm the alert reaches a human |
| 8 | Uptime monitoring | External check with an alert path to a phone |
| 9 | Rate limiting | Hammer the login and email endpoints yourself |
| 10 | Secrets | Staging and production share nothing — no keys, no databases |
| 11 | HTTPS and headers | Run a scanner; don't assume the defaults are fine |
Can you measure whether the launch worked?
- Analytics installed, wired to your consent layer.
- One activation metric, written down — "user creates a second project within 7 days", not "engagement".
- Funnel events from signup to activation actually fire — test with a fresh account, not your admin one.
- A dashboard somebody opens every morning.
Who runs this thing after go-live?
- A support inbox a human reads daily — not a dead form.
- Rollback is one tested command, not a plan in someone's head.
- On-call reality for a two-person team: who gets which alerts, what can wait until morning, what can't.
- A soft launch to ~20 friendly users for one to two weeks. They will find the bugs your tests didn't.
- A feature freeze for launch week. New code and launch day don't mix.
Point 19 is the one we defend hardest. The public date is marketing; the actual launch happened two weeks earlier, quietly, when real users first touched production. Treat it that way and the public date becomes boring — which is the goal.
We take MVPs from first commit through exactly this checklist — see our MVP development service, or read how we structure the build itself in our 4-week MVP playbook.

