Die MVP-Launch-Checkliste: 20 Punkte vor dem Go-live

TL;DR

Ein Launch ist ein Prozess, kein Ereignis. Arbeitet 20 Punkte in vier Gruppen ab: Recht (Impressum, Datenschutzerklärung, Consent, AV-Verträge), Technik (ein Backup, das ihr wirklich wiederhergestellt habt, Error-Tracking, Rate-Limits), Messung (eine Aktivierungsmetrik, schriftlich definiert) und Betrieb (Rollback-Pfad, Support-Postfach). Dann leise an 20 wohlgesonnene Nutzer launchen — vor jedem öffentlichen Termin.

Wir haben über 30 MVPs live gebracht, und die Launches scheitern selten am Code. Sie scheitern am fehlenden AV-Vertrag, am nie wiederhergestellten Backup oder an einem Gründerduo, das nicht geklärt hat, wer nachts um drei aufsteht.

Welche rechtlichen Punkte braucht ein Go-live in Deutschland?

Impressum von jeder Seite erreichbar, auch von Fehlerseiten.
Datenschutzerklärung, die beschreibt, was ihr wirklich erhebt — kein Template für ein Produkt, das ihr nicht betreibt.
Cookie-Consent, der nicht-essenzielle Skripte tatsächlich blockiert, bis zugestimmt wurde — kein Banner über bereits geladenen Trackern.
AV-Verträge (Art. 28 DSGVO) mit jedem Dienstleister, der personenbezogene Daten berührt: Hosting, Analytics, E-Mail, Error-Tracking.
Datenstandort stimmt mit der Datenschutzerklärung überein — EU-Region, wo ihr EU versprochen habt.

Ist das Produkt technisch bereit?

#	Punkt	So prüft ihr es
6	Backups	Eines in eine frische Umgebung wiederherstellen — ein nie getestetes Backup ist eine Hoffnung
7	Error-Tracking	Test-Exception werfen und prüfen, ob der Alert einen Menschen erreicht
8	Uptime-Monitoring	Externer Check mit Alarmpfad bis aufs Handy
9	Rate-Limiting	Login- und E-Mail-Endpoints selbst unter Last setzen
10	Secrets	Staging und Produktion teilen nichts — keine Keys, keine Datenbanken
11	HTTPS und Header	Scanner laufen lassen statt Defaults vertrauen

Könnt ihr messen, ob der Launch funktioniert hat?

Analytics installiert und an eure Consent-Schicht angebunden.
Eine Aktivierungsmetrik, schriftlich — „Nutzer legt innerhalb von 7 Tagen ein zweites Projekt an", nicht „Engagement".
Funnel-Events von Signup bis Aktivierung feuern wirklich — mit einem frischen Account testen, nicht mit eurem Admin-Login.
Ein Dashboard, das jemand jeden Morgen öffnet.

Wer betreibt das Ganze nach dem Go-live?

Ein Support-Postfach, das täglich ein Mensch liest — kein totes Formular.
Rollback ist ein getesteter Befehl, kein Plan in jemandes Kopf.
On-Call-Realität für ein Zwei-Personen-Team: Wer bekommt welche Alerts, was kann bis morgens warten, was nicht.
Ein Soft-Launch an rund 20 wohlgesonnene Nutzer für ein bis zwei Wochen. Sie finden die Bugs, die eure Tests nicht gefunden haben.
Feature-Freeze in der Launch-Woche. Neuer Code und Launch-Tag vertragen sich nicht.

Punkt 19 verteidigen wir am hartnäckigsten. Der öffentliche Termin ist Marketing; der eigentliche Launch war zwei Wochen vorher, leise, als echte Nutzer zum ersten Mal die Produktion berührt haben. Wer es so behandelt, erlebt einen langweiligen Launch-Tag — genau das ist das Ziel.

Wir bringen MVPs vom ersten Commit bis durch genau diese Checkliste — siehe unser MVP-Development-Angebot, oder lest, wie wir den Build selbst strukturieren: unser 4-Wochen-MVP-Playbook.