Elena Marchetti, YuSMP Group
Elena Marchetti Head of Product, YuSMP Group · 12+ Jahre Erfahrung mit B2B-SaaS-Launches für US- und EU-Teams

So nutzen Sie die Checkliste

Jeder Punkt ist entweder erforderlich (ohne ihn nicht launchen), starker Standard (nur mit schriftlicher Begründung überspringen) oder nice-to-have (bei Bedarf auf Post-Launch verschieben). Notieren Sie für jeden Punkt den Verantwortlichen (PM, Entwickler, Gründer, Anwalt) und den Nachweis (URL, Screenshot, Link zum Testergebnis). „Erledigt“ ohne Nachweis ist nicht erledigt.

Sie sollten diese Checkliste in 2–4 Stunden mit dem Team in einem Raum von Anfang bis Ende durchgehen können. Wenn es länger dauert, ist etwas unklar und Sie sind nicht bereit.

Produkt (1–6)

  1. Eine Ein-Satz-Positionierung ist geschrieben und getestet. Erforderlich. Die 8-Wort-Version, die ein Kunde einem Kollegen weitererzählen wird. Getestet an 5 Zielnutzern.
  2. Der Kern-Flow läuft ohne Hilfe von Anfang bis Ende. Erforderlich. Signup → Aktivierung → Wertmoment → Zahlung, ohne manuelle Eingriffe dazwischen.
  3. Empty States sind gestaltet. Starker Standard. Jede Liste, jedes Dashboard, jeder Feed hat einen sinnvollen Empty State, keinen leeren Bildschirm.
  4. Error States sind gestaltet und menschlich. Starker Standard. „Etwas ist schiefgelaufen“ ist ein Produktversagen, keine Fehlermeldung.
  5. Das Onboarding ist in unter 4 Minuten abgeschlossen. Starker Standard. Gemessen, nicht angenommen. Time-to-Value ist die wichtigste einzelne MVP-Metrik.
  6. Die Pricing-Seite spiegelt die tatsächliche Billing-Implementierung wider. Erforderlich. Wenn die Seite „jederzeit kündbar“ sagt und der Kündigungs-Flow 4 E-Mails benötigt, wartet eine Betrugsbeschwerde auf Sie.

Engineering (7–14)

  1. Alle Umgebungen nutzen IaC. Starker Standard. Terraform, Pulumi oder SST. Click-Ops-Infrastruktur ist spätestens im dritten Monat ein Launch-Blocker.
  2. Die CI-Pipeline läuft bei jedem PR. Erforderlich. Lint, Typecheck, Unit-Tests, Build. Unter 10 Minuten von Anfang bis Ende.
  3. Datenbankmigrationen sind forward-only und idempotent. Erforderlich. Sqitch, Flyway, Prisma Migrate oder Drizzle Kit. Kein „dieses SQL von Hand auf Prod ausführen“.
  4. Secrets liegen in einem Vault, nicht in env-Dateien. Erforderlich. AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Doppler. Rotiert.
  5. Backups sind getestet. Erforderlich. Nicht nur konfiguriert — mindestens einmal aus Produktivdaten in eine frische DB wiederhergestellt.
  6. Rate-Limiting an Auth- und Zahlungs-Endpunkten. Erforderlich. Mindestens 100 Req/Min pro IP; strengere Limits bei Signup, Login, Passwort-Reset.
  7. Mobile-Builds mit korrekten Distributionszertifikaten signiert. Erforderlich bei Mobile. Verlorenes Zertifikat = verlorene Fähigkeit, Updates zu veröffentlichen.
  8. Eine Staging-Umgebung existiert und wird genutzt. Starker Standard. Gleiche Form wie Prod, gespeist aus anonymisierten Daten. PR-Previews sind nett; Staging ist Pflicht.

Sicherheit & Compliance (15–22)

  1. HTTPS überall mit HSTS. Erforderlich. Kein Mixed Content. HSTS-Preload eingereicht.
  2. Eine Content Security Policy ist gesetzt und getestet. Starker Standard. Selbst eine laxe CSP fängt ganze XSS-Klassen ab.
  3. Auth nutzt einen Managed Provider. Erforderlich. Clerk, Auth0, Supabase Auth, WorkOS, FusionAuth — nicht selbst gebaut.
  4. Passwörter werden mit bcrypt/Argon2id gehasht. Erforderlich, wenn Sie Auth selbst verwalten. Klartext oder MD5 ist 2026 unverzeihlich.
  5. RLS erzwingt Tenant-Isolation (Multi-Tenant-SaaS). Erforderlich. Siehe Multi-Tenant-SaaS-Architektur.
  6. Dependency-Scanning läuft in der CI. Starker Standard. Dependabot, Renovate, Snyk. Kritische CVEs blockieren den Merge.
  7. Ein Incident-Runbook existiert. Erforderlich. Wer hat Bereitschaft, wie wird ein Incident erklärt, wie kommuniziert man mit Kunden, wie führt man ein Post-Mortem durch.
  8. Der DSGVO-/CCPA-Datenlösch-Flow funktioniert. Erforderlich, wenn Sie EU- oder kalifornische Nutzer haben. Ein End-to-End-Test deckt die nutzerinitiierte Löschung über DB, Blob, Analytics und Logs hinweg ab.

Billing & Zahlungen (23–28)

  1. Stripe im Produktivmodus, Webhooks verifiziert. Erforderlich. Testmodus = kein Umsatz.
  2. Der Webhook-Handler ist idempotent. Erforderlich. Stripe wiederholt Zustellungen; ohne Idempotenz buchen Sie doppelt ab.
  3. Fehlgeschlagene Zahlungen lösen Dunning aus. Erforderlich. Smart Retries aktiviert, Dunning-E-Mails konfiguriert.
  4. Der Kündigungs-Flow respektiert das Gesetz. Erforderlich. EU-Recht und die US-FTC-Click-to-Cancel-Regeln verlangen Gleichwertigkeit mit dem Signup-Flow.
  5. USt./Umsatzsteuer geregelt. Erforderlich für EU-Verkäufe. Stripe Tax oder Quaderno deckt die meisten Fälle ab.
  6. Der Erstattungs-Flow hat ein dokumentiertes Runbook. Starker Standard. Selbst MVPs erhalten in der ersten Woche Erstattungsanfragen.

Observability & Zuverlässigkeit (29–34)

  1. Error-Tracking mit Stack-Traces. Erforderlich. Sentry, Rollbar, Bugsnag. Mit Releases verknüpft für source-gemappte Traces.
  2. Strukturiertes Logging. Erforderlich. JSON-Logs, Request-ID end-to-end propagiert, Tenant-ID auf jeder Log-Zeile bei Multi-Tenant.
  3. Ein einfaches Metrik-Dashboard. Starker Standard. Latenz, Fehlerrate, Durchsatz. Datadog Free Tier, Grafana Cloud Free Tier oder selbst gehostetes Prometheus.
  4. Uptime-Checks von außerhalb Ihrer Infrastruktur. Erforderlich. Better Uptime, Healthchecks.io, Pingdom. Mindestens zwei Regionen.
  5. Alerts gehen an einen Menschen, nicht nur an einen Slack-Channel. Erforderlich. PagerDuty, OpsGenie oder eine Telefonnummer. Channels werden stummgeschaltet; Menschen werden geweckt.
  6. Eine Status-Seite existiert. Starker Standard. statuspage.io, Instatus, BetterStack Status. Kunden vertrauen Ihnen mehr, wenn Sie Ausfälle eingestehen, als wenn Sie sie verbergen.

Analytics & Growth (35–39)

  1. Produkt-Analytics mit 5–10 benannten Events instrumentiert. Erforderlich. PostHog oder Amplitude. Aktivierung, Retention, Conversion, Engagement plus produktspezifische Wert-Events.
  2. Der Funnel von der Landingpage bis zur Zahlung ist messbar. Erforderlich. Sie sollten die Frage „Wie viele der Besucher der letzten Woche haben gezahlt?“ in 60 Sekunden beantworten können.
  3. UTM-Tagging ist über alle Kanäle hinweg konsistent. Starker Standard. Andernfalls ist die Attribution Fiktion.
  4. Die Marketing-Site hat Schema.org-Markup und eine Sitemap. Starker Standard. Siehe technisches SEO & Growth.
  5. Im Produkt existiert eine Feedback-Schleife. Starker Standard. Linear-Feedback-Widget, Canny oder eine einfache E-Mail. Nutzen Sie sie ab dem ersten Tag.
  1. Datenschutzerklärung + Cookie-Consent + AVV-Vorlage. Erforderlich. Anwaltlich geprüft bei jeglichem EU-Traffic. Kopieren Sie nicht von einer anderen Website.
  2. Allgemeine Geschäftsbedingungen. Erforderlich. Haftungsbeschränkung, anwendbares Recht, zulässige Nutzung, Erstattungsrichtlinie.
  3. Der Cookie-Consent-Banner blockiert nicht-essenzielle Cookies bis zur Einwilligung korrekt. Erforderlich für die EU. Klaro, Cookiebot, Iubenda. Nur „Alle akzeptieren“ ist nicht mehr konform.

Marketing & Launch (43–45)

  1. Die Landingpage besteht die Core Web Vitals. Starker Standard. LCP < 2,5 s, CLS < 0,1, INP < 200 ms auf Mobile. PageSpeed-Score 90+.
  2. Open Graph und Twitter Cards konfiguriert. Starker Standard. Mit den tatsächlichen Card-Debuggern testen, nicht nur mit den Dev-Tools.
  3. Launch-Kommunikation entworfen. Starker Standard. E-Mail an die Warteliste, Social-Posts, Product-Hunt-Entwurf, LinkedIn-Post des Gründers. Entworfen, nicht nur beabsichtigt.

Post-Launch-Ops (46–47)

  1. Der Support-Eingang ist besetzt. Erforderlich. Ein echter Mensch antwortet an Werktagen innerhalb von 4 Stunden, sonst innerhalb von 24 Stunden. Mindestens E-Mail + In-App.
  2. Die Roadmap hat einen Bucket für „Woche eins“, „Monat eins“ und „Quartal eins“. Erforderlich. Vorab eingeplante Kapazität für die unvermeidlichen Bugs und kleinen Fixes. Ohne sie brennt das Team bis Woche drei aus.
MVP-Launch-Dashboard mit Go/No-Go-Checkliste
47 Punkte. 2–4 Stunden mit dem Team in einem Raum. Wenn ein erforderlicher Punkt rot ist, launchen Sie nicht.

FAQ

Wie viele Punkte sollte eine MVP-Launch-Checkliste haben?

Unsere Produktiv-Liste umfasst 47 Punkte in neun Kategorien. Weniger als ~30 lässt kritische Arbeit aus; mehr als ~70 ist überdimensioniert.

Welcher Punkt wird vor dem MVP-Launch am häufigsten ausgelassen?

Produktiv-Observability. Gründer launchen ohne Error-Tracking und stellen in Woche zwei fest, dass 14 % der Nutzer still in einen Fehlerpfad laufen.

Brauche ich für meinen MVP eine Datenschutzerklärung?

Ja. Schon kleine EU-/US-Nutzerbasen lösen DSGVO-/CCPA-Pflichten aus. Nicht optional.

Sollte der MVP ein Admin-Panel haben?

Ja — ein einfaches. Retool, Forest Admin oder ein an einem Tag gebautes In-App-Admin. Spart 5–10 Support-Stunden pro Woche.

Wie viel Testing braucht ein MVP?

Unit-Tests für Zahlung, Auth und Tenant-Isolation. Playwright-Smoke-Tests für 3–5 kritische Flows. Verzichten Sie auf erschöpfende E2E-Tests.

Welche Metriken sollte ich vor dem Launch instrumentieren?

Aktivierung, Retention (D1/D7/D30), Conversion (kostenlos zu zahlend), Engagement und eine produktspezifische Wert-Metrik. Der kostenlose PostHog- oder Amplitude-Tarif deckt das ab.

Holen Sie sich ein Launch-Audit, bevor Sie veröffentlichen

Ein Tag Senior-Engineering. Abhakliste mit Rot/Gelb/Grün, die riskantesten Fixes priorisiert, schriftliche Go/No-Go-Einschätzung. Nützlich vor dem Launch, vor der Finanzierungsrunde, vor Enterprise-Piloten.

Zuletzt aktualisiert am 26. Mai 2026.