SaaS Production Checkliste:14 Checks vor dem Go-live
Die SaaS Production Checkliste: 14 technische Checks — SSL, Backups, Sicherheitsregeln, geheime Schlüssel, Rollbacks — bevor echte Nutzer dein Produkt anfassen.
Bevor deine SaaS live geht, arbeite eine SaaS Production Checkliste ab: Sicherheitsregeln auf jeder Datenbanktabelle aktiviert und getestet, geheime Schlüssel aus dem Code, SSL aktiv, Backups verifiziert und ein Rollback, den du wirklich geübt hast. Launch-Marketing bekommt die ganze Aufmerksamkeit — aber die unglamourösen Go-live-Checks entscheiden darüber, ob deine ersten echten Nutzer auf ein funktionierendes Produkt treffen oder auf ein Datenleck.
Das ist die technische Hälfte des Launchs. Die Marketing-Hälfte — die Ankündigung, die Kanäle, der Schwung — ist der Launch-Week-Playbook. Heute geht es darum sicherzustellen, dass das, was du ankündigst, nicht umfällt.
Warum du überhaupt eine Production-Checkliste brauchst
Dein Produkt hat bisher in einer nachsichtigen Welt gelebt: eine Entwicklungsdatenbank, die du löschen und neu aufbauen kannst, lose durchgesetzte Sicherheitsregeln, großzügige Fehlermeldungen, keine echten Nutzerdaten auf dem Spiel. Produktion ist die gegenteilige Welt — echte Menschen, echte Daten, strikte Sicherheit und keine Wiederholung bei einem geleakten Schlüssel oder einer verlorenen Datenbank.
Die Gefahr: Eine App kann fertig aussehen und doch nur ein ungeprüftes Häkchen vom Desaster entfernt sein. Alles auf dieser Liste ist in einer Demo unsichtbar. Alles davon ist in Produktion existenziell.
Die SaaS Production Checkliste mit 14 Punkten
Das ist die Checkliste, die ich vor jedem Go-live abarbeite, in einfache Sprache übersetzt:
| # | Check | Warum er zählt |
|---|---|---|
| 1 | Alle Datenbank-Migrationen laufen erfolgreich durch | Das Produktionsschema passt zu dem, was deine App erwartet — keine fehlenden Tabellen am ersten Tag |
| 2 | Row-Level Security auf jeder Tabelle aktiviert | Die Datenbank selbst weigert sich, die Daten eines Kunden an einen anderen auszuliefern |
| 3 | Sicherheits-Policies getestet, nicht nur geschrieben | Eine Policy, die existiert, aber falsch ist, fühlt sich identisch an — bis zum Datenleck |
| 4 | Indizes für die Performance angelegt | Abfragen, die sich mit 10 Testzeilen sofort anfühlten, kriechen bei 10.000 echten |
| 5 | Authentifizierung für deine Live-Domain konfiguriert | Registrierungs- und Passwort-Reset-Links müssen auf deine echte Seite zeigen |
| 6 | Datei-Speicher-Buckets mit Zugriffs-Policies angelegt | Uploads funktionieren — und Nutzer können nur ihre eigenen Dateien lesen |
| 7 | Serverseitige Funktionen deployt | Jegliche Backend-Logik existiert tatsächlich in Produktion, nicht nur lokal |
| 8 | Secrets für diese Funktionen gesetzt | Schlüssel von Drittanbietern liegen in sicheren Einstellungen, nie im Code |
| 9 | E-Mail-Templates angepasst | Bestätigungs- und Reset-Mails tragen deine Marke, keinen generischen Standard |
| 10 | Rate Limiting konfiguriert | Ein missbräuchliches Skript kann weder deinen Login bombardieren noch deine Rechnung hochtreiben |
| 11 | Backups als laufend verifiziert | Automatische tägliche Backups existieren — bestätigt, nicht angenommen |
| 12 | Monitoring-Alerts aktiviert | Du erfährst von Fehlerspitzen und langsamen Abfragen, bevor Nutzer dir mailen |
| 13 | Connection Pooling, falls nötig | Viele gleichzeitige Nutzer erschöpfen nicht deine Datenbankverbindungen |
| 14 | API-Schlüssel sicher gespeichert — nie im Code | Ein Schlüssel in deinem Repository ist ein Schlüssel im Internet |
Jeder Check ist eine Frage, die du der KI stellen kannst: „Zeig mir, dass Row-Level Security auf jeder Tabelle aktiviert ist, und liste die Tabellen auf, bei denen es nicht so ist.“ Du musst nicht wissen, wie du jeden Punkt von Hand behebst. Du musst dich weigern zu launchen, bis jede Antwort Ja lautet.
12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →Die drei Checks, die Gründer am häufigsten überspringen
Row-Level Security (Checks 2 und 3). Das ist die Mauer zwischen den Daten deiner Kunden — die Datenbank, die sich auf ihrer eigenen Ebene weigert, die Datensätze von Nutzer A an Nutzer B auszuliefern. Es ist der Check mit dem schlimmsten Fehlerfall, weshalb er einen eigenen Leitfaden bekommt. Aktiviert reicht nicht; teste es, indem du versuchst, die Daten eines anderen Accounts zu lesen, und bestätigst, dass es nicht geht.
Geheime Schlüssel (Checks 8 und 14). Deine App hat öffentliche Schlüssel (im Browser sicher) und geheime Schlüssel (voller Zugriff auf alles). Die geheimen gehören in die geschützten Einstellungen deines Hosting-Anbieters. Wurde ein geheimer Schlüssel je in deinen Code geschrieben, behandle ihn als kompromittiert und tausche ihn vor dem Launch aus.
Die Rollback-Probe. Nicht in der Liste oben, weil sie eine Übung ist und keine Einstellung: deployen, dann üben, aus deinem Hosting-Dashboard auf die vorherige Version zurückzugehen. Das dauert etwa 30 Sekunden ohne Downtime — fühlt sich aber erst nach dem Üben wie ein Sicherheitsnetz an. Diese Probe ist auch die Grundlage für Deployen ohne Angst nach dem Launch.
Checks auf Hosting-Seite: Domain, SSL, Umgebung
Auf der Hosting-Seite runden vier Punkte den Go-live ab. Deine eigene Domain ist verbunden — DNS-Änderungen brauchen 10–30 Minuten zur Verbreitung. SSL ist aktiv, was dein Host kostenlos und automatisch in 5–10 Minuten ausstellt; kein Nutzer sollte je eine „Nicht sicher“-Warnung sehen. Umgebungsvariablen für Produktion sind im Dashboard mit echten Werten gesetzt, getrennt von allen Staging-Werten. Und Fehler-Tracking plus Analytics sind eingeschaltet, sodass du ab dem allerersten Nutzer siehst, was kaputtgeht und was genutzt wird — dieselbe Infrastruktur wie beim Monitoring deiner SaaS als Solo-Gründer.
Backups und Wiederherstellung: einmal vom Schlimmsten ausgehen
Im kostenlosen Tarif einer Plattform wie Supabase laufen Backups täglich und werden 7 Tage aufbewahrt. Der Pro-Tarif ($25/Monat) verlängert die Aufbewahrung auf 30 Tage und ergänzt Point-in-Time-Recovery — stelle deine Datenbank auf jeden beliebigen Zeitpunkt zurück, etwa fünf Minuten vor einer schlechten Änderung. Nimm dir zehn Minuten, um in Ruhe deinen Wiederherstellungsplan aufzuschreiben: Datenbank korrupt → neuestes Backup einspielen und prüfen. Das liest sich wie Paranoia, bis es sich eines Tages wie Genialität liest.
Was das alles kostet: meistens nichts
Der beruhigende Teil. Die kostenlosen Tarife sind wirklich produktionstauglich: Mein eigenes Setup betreibt 3 Produktionsseiten mit 300–500 Builds und 50–100 GB Bandbreite im Monat — für 0 € Hosting. Die Signale, dass du dem Gratis-Tarif entwachsen bist, sind konkret: eine Datenbank über 500 MB, Bandbreite über 5 GB/Monat oder der Wunsch nach längerer Backup-Aufbewahrung — dann sind es $25/Monat. Für die meisten Solo-Produkte trägt dich der Gratis-Tarif Monate oder Jahre. Die Checkliste kostet einen Nachmittag. Sie zu überspringen kann das Business kosten.
Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →Häufig gestellte Fragen
Was sollte ich prüfen, bevor ich eine SaaS launche?
Vierzehn technische Punkte in fünf Bereichen: Datenbank (Migrationen laufen, Row-Level Security aktiviert und getestet, Indizes vorhanden), Authentifizierung (für deine Live-Domain konfiguriert, gebrandete E-Mails), Sicherheit (geheime Schlüssel aus dem Code, Rate Limiting), Ausfallsicherheit (Backups verifiziert, ein geübter 30-Sekunden-Rollback) und Sichtbarkeit (Fehler-Tracking und Monitoring-Alerts an).
Brauche ich einen bezahlten Tarif, um live zu gehen?
Meist nicht. Gratis-Tarife sind produktionstauglich: unbegrenzte Bandbreite auf der Hosting-Seite, tägliche Backups mit 7 Tagen Aufbewahrung auf der Datenbank-Seite. Wechsle zum Datenbank-Tarif für $25/Monat, wenn du 500 MB Daten überschreitest oder 30 Tage Aufbewahrung mit Point-in-Time-Recovery willst. Meine eigenen drei Produktionsseiten laufen mit 0 € Hosting.
Welcher Check wird am häufigsten übersehen?
Das Testen von Row-Level Security — nicht nur das Aktivieren. Gründer schalten es ein, sehen keine Fehler und liefern aus. Aber eine falsche Policy verhält sich genau wie eine richtige, bis jemand die Daten eines anderen Kunden liest. Versuche vor dem Launch aktiv, accountübergreifend auf Daten zuzugreifen, und bestätige, dass die Datenbank es verweigert.
Wie funktionieren Backups für einen Solo-Gründer?
Automatisch, sobald verifiziert. Verwaltete Plattformen sichern deine Datenbank täglich ohne Konfiguration — 7 Tage Aufbewahrung gratis, 30 Tage plus Point-in-Time-Recovery im Tarif für $25/Monat. Deine Aufgabe ist zweifach: vor dem Launch bestätigen, dass Backups wirklich laufen, und das Wiederherstellungsverfahren aufschreiben, solange nichts brennt.
Wie gefangen bist du wirklich?
Mach den Corporate Suffocation Index – die kostenlose Einschätzung, ob du bereit bist, Solopreneur zu werden.