Produktionsreif (englisch „production-ready“) bedeutet nicht „funktioniert“. Es bedeutet: Die Anwendung bedient stabil, sicher und skalierbar zahlende Kunden, ohne dass dein Team ständig im Notfallmodus läuft. Eine SaaS ist produktionsreif genug, wenn sie für ihr aktuelles Risiko-Niveau stabil läuft, bekannte Sicherheitsrisiken adressiert, wachsen kann, sichtbar macht, wenn etwas schiefläuft, und sich rasch reparieren lässt.
Wichtig: Produktionsreife ist kein Schalter, sondern ein Spektrum. Eine SaaS für 100 Nutzer hat andere Anforderungen als eine für 10’000 Nutzer. Das richtige Niveau hängt von Risiko, Budget und Kundenerwartung ab.
Was ist damit gemeint: Keine SQL-Injections, XSS, CSRF, unsichere Deserialisierung. Logins sind verschlüsselt (HTTPS überall, sichere Sessions). Geheimnisse (DB-Passwörter, API-Keys) liegen nicht im Code. Der Code wird regelmässig auf bekannte Schwachstellen geprüft.
Wie wird es geprüft: Audit gegen die OWASP Top 10. Dependency-Scans (npm audit, Snyk). Statische Sicherheitsanalyse (SAST).
In Zahlen: Eine einfache Next.js-App braucht 5 bis 10 Tage für Security-Härtung.
Was ist damit gemeint: Die App ist so gebaut, dass sie mit steigender Nutzung gezielt ausgebaut werden kann. Datenbank-Abfragen sind optimiert (Indexe gesetzt, Query-Pläne geprüft), API-Latenzen werden gemessen, und die Code-Schicht lässt sich bei Bedarf horizontal skalieren (zustandslose Services).
Wie wird es geprüft: Lasttests (k6, Apache JMeter), die 1’000 gleichzeitige Nutzer simulieren. Profiling der Datenbank-Abfragen (EXPLAIN ANALYZE in Postgres). Infrastruktur als Code (Terraform, Helm) für Skalierung in Minuten.
In Zahlen: Skalierungs-Audit für eine Lovable-App: 3 bis 5 Tage. Refactoring (zum Beispiel N+1-Query-Fixes): 2 bis 7 Tage.
Was ist damit gemeint: Daten werden verschlüsselt (in der Übertragung mit TLS, im Speicher bei Personendaten). Nutzer können ihre Daten löschen lassen (DSGVO „Recht auf Vergessenwerden“, Schweizer DSG mit Löschpflicht). Datenzugriffe sind protokolliert (Audit-Logs). Du weisst, welche Daten wo liegen (Daten-Inventar).
Wie wird es geprüft: Datenschutz-Folgenabschätzung (DSFA, Privacy Impact Assessment). Datenschutz-Audit mit dem Compliance-Team. Audit-Log-Review.
In Zahlen: DSG- und DSGVO-Audit: 5 bis 10 Tage. Umsetzung (Verschlüsselung, Lösch-Workflows): 7 bis 14 Tage.
Was ist damit gemeint: Die wichtigsten Seiten und API-Endpunkte bleiben spürbar schnell. Zielwerte wie kurze Ladezeiten, niedrige p95-Latenz und gute Core Web Vitals helfen bei der Steuerung, müssen aber zum Produkt und zur Infrastruktur passen. Ein CDN-Cache reduziert die Backend-Last.
Wie wird es geprüft: Lighthouse in den Chrome DevTools. Real User Monitoring (Sentry, Datadog). Application Performance Monitoring (New Relic, Grafana).
In Zahlen: Performance-Audit: 2 bis 3 Tage. Optimierung (Bilder, Code-Splitting, Caching): 5 bis 14 Tage.
Was ist damit gemeint: Logs werden zentralisiert (zum Beispiel ELK Stack, Datadog, Vercel Logs). Metriken werden gesammelt (Anfragen pro Zeit, Fehlerrate, Antwortzeit). Traces zeigen, was eine langsame Anfrage durchläuft. Alerts warnen dich, wenn etwas schiefläuft (zum Beispiel Fehlerrate über 5 Prozent). Die vier Golden Signals: Latenz, Traffic, Fehler, Sättigung.
Wie wird es geprüft: „Kann ich sehen, warum ein Nutzer ein Problem hatte?“ — Logs und Traces. „Wann war der letzte kritische Alert?“ — Alerting-System prüfen. „Wie lange braucht das System, um auf einen Ausfall zu reagieren?“ — MTTR messen.
In Zahlen: Observability-Setup: 3 bis 5 Tage. Feintuning (Alerts, Dashboards): 2 bis 7 Tage.
Was ist damit gemeint: Die Datenbank wird täglich gesichert, mindestens einmal. Backups werden getestet — funktioniert ein Restore wirklich? Recovery Time Objective (RTO): Wie lange darf ein Ausfall dauern? Recovery Point Objective (RPO): Wie viel Datenverlust ist tragbar?
Wie wird es geprüft: Backup wiederherstellen und Datenintegrität prüfen. Was kostet ein Ausfall pro Stunde? Sind die Backups verschlüsselt?
In Zahlen: Backup- und DR-Setup: 3 bis 5 Tage. Testing und Dokumentation: 2 bis 3 Tage.
Was ist damit gemeint: Code wird per Code-Review geprüft, keine Ad-hoc-Patches. Tests existieren dort, wo Fehler teuer wären (Unit, Integration, End-to-End). Technische Schulden werden erfasst und abgebaut (Refactoring-Tickets). Dokumentation existiert (Setup-Guide, API-Doku, Runbooks).
Wie wird es geprüft: SonarQube oder DeepSource: automatische Code-Analyse. „Wie lange braucht ein neuer Entwickler, um einen Bug zu beheben?“ (Ziel: unter 2 Stunden).
In Zahlen: Refactoring zur Verbesserung der Code-Qualität: 7 bis 21 Tage, je nach Grösse der Codebasis.
Was ist damit gemeint: Es existiert ein Playbook für Vorfälle: „Server down → Runbook → Wiederherstellung“. Das Team weiss, wer reagieren muss. Nach wichtigen Vorfällen folgt ein Review mit Lessons Learned. Automatisierung reduziert Handarbeit (Auto-Scaling, Circuit Breaker).
Wie wird es geprüft: „Wie lange dauert es, bis jemand merkt, dass eine Datenbank down ist?“ „Wie lange dauert die Behebung?“ Die Zielwerte hängen davon ab, wie geschäftskritisch der Service ist.
In Zahlen: Runbook-Erstellung und Pikett-Setup: 2 bis 3 Tage. Automatisierung der Vorfallreaktion: 5 bis 10 Tage.
Was ist damit gemeint: LLM-API-Aufrufe sind kostenkontrolliert (Limits pro Tenant). Caching reduziert wiederholte API-Aufrufe (zum Beispiel Redis für Embeddings). Modell-Routing: einfache Anfragen ans günstige Modell, komplexe Anfragen ans starke Modell. Monitoring zeigt, wer Kosten verursacht und welcher Tenant aus dem Ruder läuft.
Wie wird es geprüft: „Können wir Kosten pro Feature und pro Tenant verfolgen?“ — Wenn ja, produktionsreif. „Was sind unsere fünf teuersten API-Aufrufe?“ — sichtbar im Dashboard. „Wie schnell können wir ein Feature deaktivieren, wenn es zu teuer wird?“ — Plan vorhanden.
In Zahlen: Implementierung der Kostenkontrolle: 3 bis 5 Tage. Monitoring und Alerts: 2 bis 3 Tage.
Eine App mit 10 internen Nutzern braucht weniger Härtung als eine mit 10’000 zahlenden Kunden.
| Stufe | Nutzer | Sicherheit | Skalierung | Monitoring | RTO | Einsatz |
|---|---|---|---|---|---|---|
| Alpha | 1–10 | Basis | Ein Server | Nur Logs | 24h | Intern |
| Beta | 10–100 | Mittel | App und DB getrennt | Logs und Alerts | 4h | Erste Kunden |
| Produktion | 100–1’000 | Hoch | Multi-Region-fähig | Vollständige Observability | 1h | Zahlende Kunden |
| Enterprise | 1’000+ | Sehr hoch | Auto-Scaling geplant | Echtzeit-RUM | kurz | Geschäftskritisch |
Du hast einen Prototyp mit Lovable gebaut. Hier sind die wesentlichen Punkte — nicht 30 zum Abhaken, sondern das, was wirklich zählt.
Nicht alle 9 Dimensionen in voller Tiefe. Das Minimum hängt vom Risiko ab, aber Sicherheit, Backups und Monitoring gehören früh dazu. Skalierung kann oft warten, solange du Last, Datenbank und Kosten im Blick behältst.
Viele Härtungen liegen grob bei 4 bis 8 Wochen. Es hängt von Komplexität, Grösse der Codebasis, Datenrisiko und Verfügbarkeit deines Teams ab. Kleiner und klarer ist einfacher.
Typischerweise CHF 10’000 bis 80’000 für eine einfache SaaS. Siehe /prototyp-zu-saas.
Später ist möglich, solange du dir bewusst bist: Du trägst das Risiko. Früher bedeutet weniger Code, der später umgeschrieben werden muss.
„Wir dachten, Monitoring ist optional.“ Ist es nicht. Ohne Monitoring weisst du nicht, wenn etwas kaputt ist.
Wir erstellen gerade einen Lead-Magnet mit allen 30 Items, Code-Beispielen und einer Selbst-Einschätzung (Alpha, Beta, Produktion). Bis dahin: kostenlose Code-Analyse für deinen Prototyp.