Eine SaaS-Launch-Checkliste, die über die Landing Page hinausgeht

Die erste Kundensitzung durchgehen

Erstelle ein frisches Konto in der Umgebung, die du veröffentlichen willst. Folge der Verifizierung oder den Anbieter-Callbacks, lade die App neu, aktualisiere ein Profil und melde dich ab. Wiederhole den Ablauf auf einem schmalen Bildschirm mit der Tastatur. Deine übliche Entwicklungssitzung kann fehlende Konfigurationsschritte und veralteten Zustand verbergen.

Prüfe die Hinweise, die erklären, was als Nächstes zu tun ist. Ein leerer Bildschirm sollte eine nützliche Aktion anbieten. Eine fehlgeschlagene Anfrage sollte erklären, wie man es erneut versucht, statt den Eindruck zu erwecken, die Arbeit sei gelungen. Nutze die echte Sprache des Produkts in diesen Meldungen und stelle sicher, dass Konto- und Support-Links zu echten Zielen führen.

Wiederhole den Ablauf einmal pro Anmeldemethode. OAuth-Callbacks für Google und GitHub bringen jeweils eigene Redirects und Fehlermodi mit (der OAuth-Setup-Guide deckt die Konfiguration ab), und der Test-Consent-Screen eines Anbieters verhält sich anders als der produktive.

• Kontoerstellung und Sitzungswiederherstellung funktionieren.
• Abmeldung widerruft Zugang und löscht die Darstellung des vorherigen Nutzers.
• Leer-, Lade- und Fehlerzustände bleiben auf Mobil verständlich.
• Jeder OAuth-Anbieter schließt seinen Callback auf der echten Domain ab.
• Verifizierungs- und Reset-E-Mails kommen an, sind klar lesbar und verlinken auf die richtige Umgebung.
• Der erste Start zeigt einem neuen Nutzer, was als Nächstes zu tun ist.

Bezahlten Zugang am Server beweisen

Der Checkout ist die einfache Hälfte. Geh den ganzen Lifecycle in der Sandbox des Anbieters durch: Kauf, empfangener und verifizierter Webhook, persistierte Berechtigung, freigeschaltetes Paid-Feature — dann Verlängerung, Kündigung und Erstattung. Jeder Übergang sollte serverseitigen Zustand ändern, nicht nur ein Client-Flag. Der Billing-Guide zeigt, wo supastack diesen Zustand hält.

Dann teste die Ereignisse, die du lieber nicht sehen willst: ein zweimal zugestellter Webhook, eine fehlgeschlagene Zahlung, ein Abo, das mitten in einem Task erlischt. Eine Berechtigung beantwortet „ist das gerade erlaubt“ zum Zeitpunkt der Anfrage — ein Dashboard-Badge tut das nicht.

• Ein Sandbox-Kauf läuft durch und schaltet das Paid-Feature frei.
• Doppelte Webhook-Zustellungen sind sicher — die Verarbeitung ist idempotent.
• Kündigung und Erstattung entziehen Zugang an der Server-Grenze.
• Sitz- oder Nutzungslimits, falls angeboten, lehnen jenseits ihrer Bedingungen ab.

Grenzen mit echten Abhängigkeiten verifizieren

Nutze zwei unabhängige Konten, um Besitz zu verifizieren. Versuche, den Datensatz eines Kontos vom anderen aus zu lesen und zu ändern — einschließlich Task-Status und Wiederherstellungs-URLs. Prüfe bezahlten Zugang an der Server-Aktionsgrenze, nicht nur durch das Verstecken eines Buttons im UI.

Workspace-begrenzte Datensätze sind das Rückgrat eines Multi-Tenant-Produkts — der Workspace-Grenzen-Post erklärt das Modell. Was auch immer dein Stack ist, die Launch-Frage bleibt dieselbe: Leitet jedes Lesen und Schreiben Besitz aus dem authentifizierten Server-Kontext ab, ohne dass eine Datensatz-ID oder ein vom Client gesendeter Workspace als Beweis akzeptiert wird?

• Workspace-übergreifende Lese- und Schreibzugriffe werden abgelehnt.
• Wiederherstellungs- und Task-URLs gewähren für sich allein keinen Zugang.
• Listen- und Detailansichten setzen dieselbe Begrenzung durch.
• API-Schlüssel und Webhooks tragen, falls angeboten, ebenfalls den Workspace-Scope.

Die Fehlerpfade absichtlich durchspielen

Hintergrundarbeit scheitert auf zwei unterschiedliche Arten, und jede braucht ihren eigenen Test. Ein fehlgeschlagener Dispatch lässt den Client unsicher, ob überhaupt etwas eingereiht wurde — ein task-bezogener Idempotenzschlüssel und eine gespeicherte Einreichung lassen die Wiederherstellung die ursprüngliche Anfrage wiederverwenden, statt sie zu doppeln. Ein fehlgeschlagener Abschluss bedeutet: Die Arbeit lief, aber das Ergebnis kam nie an — Retries und Status-Polling sollten diese Lücke ohne eine zweite Generierung schließen.

Wende dieselbe Denkweise auf Anbieter an: ein KI-Anbieter-Timeout, eine unzustellbare E-Mail, ein Fehler der Billing-API. Jeder sollte in einem konkreten, erklärbaren Zustand enden statt in einem stillen Halbergebnis. Der Task-Recovery-Guide dokumentiert, wie der Produktionspfad des Kits damit umgeht.

• Ein Retry nach einem Einreichungs-Timeout dupliziert weder Arbeit noch Kosten.
• Ein fehlgeschlagener Abschluss ist sichtbar und behebbar, kein stiller Verlust.
• Anbieterfehler erreichen den Nutzer als ehrliche Zustände, nicht als generische Abstürze.

Auf den ersten Fehlschlag vorbereiten

Stelle sicher, dass jemand einen Fehler finden, ihn mit dem betreffenden Task verknüpfen und dem Nutzer bei der Wiederherstellung helfen kann — ohne Anbieter-Geheimnisse offenzulegen. Bestätige, welche Logs und Audit-Datensätze existieren, wie lange du sie aufbewahrst und wie ein Operator darauf zugreift.

Entscheide vor dem Launch, wie „etwas stimmt nicht“ aussieht: fehlgeschlagene Job-Zustellungen, Webhook-Verifizierungsfehler, ein plötzlicher Anstieg der Anbieterkosten. Ein Alert, den niemand empfängt, ist kein Monitoring — das Observability-Setup deckt die Verdrahtung dieser Signale ab.

Behandle Backups als operative Übung: Ein konfiguriertes Backup ist nicht dasselbe wie ein wiederhergestelltes. Führe die Wiederherstellung einmal aus, mit Daten, die der Produktion ähneln, bevor der Tag kommt, an dem du sie brauchst.

• Ein Fehler lässt sich zu der Anfrage, dem Nutzer und dem Task zurückverfolgen, die ihn verursacht haben.
• Logs und Audit-Datensätze haben einen Besitzer, eine Aufbewahrungsrichtlinie und Zugriffsregeln.
• Ein Backup wurde wiederhergestellt, nicht nur konfiguriert.
• Fehlgeschlagene Jobs und Webhook-Fehler lösen einen Alert aus, den ein Mensch empfängt.

Die Oberflächen rund ums Produkt prüfen

Rechts- und Kommunikationsflächen gehören zum Launch, nicht zum Feinschliff: Datenschutz und Bedingungen, die beschreiben, was das Produkt wirklich tut, eine Support-Adresse, die einen Menschen erreicht, und eine verifizierte Absenderdomain, damit Transaktions-Mails von einer Adresse kommen, die dir gehört.

Lies jede automatisierte E-Mail so, wie ein Kunde sie lesen würde. Verifizierungs-, Reset-, Beleg- und Abschlussmeldungen sollten den Produktnamen tragen, auf die richtige Umgebung verlinken und einen Antwortweg bieten, der keine tote noreply-Adresse ist.

• Datenschutz- und Bedingungsseiten beschreiben das Produkt, das du wirklich betreibst.
• Transaktions-Mails werden von einer verifizierten Domain versendet, die dir gehört.
• Support- und Abrechnungsfragen haben ein erreichbares Ziel.

Die Go-oder-No-Go-Entscheidung explizit machen

Stelle die Release-Akte zusammen: Build-Revision, Zielumgebung, was wie getestet wurde und was ungeprüft bleibt. Eine Checkliste mit ehrlichen Lücken schlägt eine selbstbewusste Zusammenfassung — in den Lücken liegt meist der erste Vorfall.

Entscheide den Rollback-Pfad, bevor du ihn brauchst: wie du das Deployment zurückdrehst, was mit den zwischenzeitlich geschriebenen Daten passiert und wer die Entscheidung trifft. Dann launche die kleinste Version des Angebots, die du vollständig unterstützen kannst, und erweitere sie bewusst.

Häufige Launch-Fragen

Launch-Checklisten scheitern an vorhersehbaren Stellen. Diese Fragen erwischen die meisten davon.

• Was vergessen die meisten SaaS-Launches? — Die Enden der Abläufe: eine Abmeldung, die wirklich widerruft, eine Kündigung, die Zugang wirklich entzieht, und eine Restore-Übung für das Backup, das auf dem Papier existiert.
• Wie viele Testkonten brauche ich? — Mindestens zwei, in der Zielumgebung. Datenisolation und Einladungsabläufe lassen sich mit einem nicht verifizieren.
• Sandbox- oder Produktionstests? — Beides. Die Sandbox beweist die Lifecycle-Logik; eine kleine echte Transaktion beweist, dass Schlüssel, Domains und Webhooks am richtigen Ort verdrahtet sind.
• Wann ist ein Launch sicher? — Wenn jeder Punkt, der Kundendaten oder Geld schützt, verifiziert ist und die ungeprüften Punkte mit Besitzern notiert sind — nicht wenn die Feature-Liste vollständig aussieht.
• Was ändert sich nach dem Launch? — Behalte die Release-Akte, beobachte die konfigurierten Fehler-Alerts und führe die Checkliste nach jeder wesentlichen Änderung an Auth, Billing oder Scoping erneut aus.