SaaS-Entwicklung: vom MVP zur Produktion (Phasen, Zeitrahmen, Kosten)

Wer ein SaaS-Produkt vom MVP in die Produktion bringt, ergänzt, was eine Demo weglassen kann: Trennung zwischen den Kunden, ein sicheres Login, ein Billing, das mit fehlgeschlagenen Zahlungen umgehen kann, ein Admin-Backoffice, Monitoring, getestete Backups und einen sicheren Weg, Änderungen auszuliefern. Der Weg hat fünf Phasen. Wie lange jede dauert, hängt stärker von Integrationen, Benutzerrollen und Compliance ab als von der Zahl der Screens. Dieser Leitfaden richtet sich an Gründerinnen, Gründer und Product Owner in der Schweiz mit einer validierten Idee oder einem funktionierenden MVP. Er behandelt die Phasen, die schwer umkehrbaren Entscheide, eine Checkliste für die Produktionsreife nach OWASP ASVS, NIST SSDF und der AWS Well-Architected SaaS Lens, Datenschutz und Hosting.

Welche Phasen führen vom MVP zum produktiven SaaS?

Es gibt fünf Phasen: das Problem validieren, das MVP abgrenzen und bauen, es für den Produktivbetrieb härten, launchen und stabilisieren, dann betreiben und wachsen. Die Spannen unten gehen von einem B2B-Webprodukt aus, das ein kleines Senior-Team entwickelt. Projekte rutschen wegen Integrationen, Benutzerrollen und Sicherheitsanforderungen ans obere Ende, selten wegen der Zahl der Screens.

Phase	Ziel	Typisches Ergebnis	Spanne	Was die Dauer bestimmt
1. Problemvalidierung	Bestätigen, dass jemand für die Lösung des Problems bezahlt	Kundeninterviews, klickbarer Prototyp, Preistest, Zusagen für Pilotprojekte	2–6 Wochen	Zugang zu Zielkunden
2. MVP abgrenzen und bauen	Eine Kernaufgabe durchgängig für einen Benutzertyp lösen	Registrierung, Kern-Workflow, einfache Administration, ausgeliefertes Produkt	6–16 Wochen	Integrationen, Billing ab dem ersten Tag, Zahl der Rollen
3. Härtung für den Produktivbetrieb	Sicherer Betrieb für viele Kunden	Tests der Mandantentrennung, Sicherheitsreview, Monitoring, Backups, CI/CD, rechtliche Dokumente	4–10 Wochen, teilweise parallel zu Phase 2	Von Kunden verlangtes Sicherheitsniveau; Sensibilität der Daten
4. Launch und Stabilisierung	Erste zahlende Kunden ohne Vorfälle	Supportprozess, Statusseite, Runbooks, Korrekturen aus dem echten Einsatz	2–6 Wochen	Zahl der ersten Kunden und ihre Datenmigrationen
5. Betreiben und wachsen	Kunden halten und ausbauen	Roadmap, Kennzahlen, regelmässige Releases	Laufend	Produktstrategie

In der Validierung kostet ein Kurswechsel am wenigsten. Wenn Zielkunden das Problem nicht in eigenen Worten beschreiben können oder keiner von ihnen sich auf einen bezahlten Pilot einlässt, hilft mehr Code nicht.

Was gehört ins MVP, und was kann warten?

Ins MVP gehört eine Kernaufgabe, durchgängig gelöst für einen Benutzertyp, dazu die Entscheide, die sich nur teuer nachrüsten lassen: das Mandantenmodell, das Berechtigungsmodell und das Datenmodell für das Billing. Verschieben Sie, was nur einzelne Kunden brauchen, etwa Single Sign-on, individuelle Rollen, eine öffentliche API oder native Apps, es sei denn, Ihre ersten Kunden können ohne sie nicht kaufen.

Im MVP bauen	Jetzt entscheiden, später bauen	Verschieben
Registrierung, Login, Passwort-Reset, optionale MFA	Modell der Mandantentrennung	SSO (SAML, OpenID Connect) und Benutzer-Provisioning
Der Kern-Workflow, durchgängig	Modell für Rollen und Berechtigungen	Individuelle Rollen pro Kunde
Datenexport für Kunden	Billing-Modell: Lizenzplätze, Nutzung oder Pauschale	Experimente mit nutzungsbasierten Preisen
Einfache Administration: Mandanten, Benutzer, Pläne	Format des Audit-Logs	Öffentliche API und Webhooks, ausser die API ist das Produkt
Fehler-Tracking und strukturierte Logs	Datenstandort	Multi-Region-Setup, native Apps

Welche Architekturentscheide lassen sich später nur schwer ändern?

Vier Entscheide sind teuer umzukehren: wie Mandanten getrennt werden, wie Identität und Berechtigungen funktionieren, wie das Billing modelliert ist und wo die Daten liegen. Treffen Sie sie bewusst im MVP, auch wenn die erste Umsetzung einfach ist. Wenn Integrationen Teil des Nutzens sind, planen Sie auch die API früh, denn andere Systeme und KI-Agenten werden von ihrer Form abhängen.

Mandantentrennung. Die AWS Well-Architected SaaS Lens beschreibt drei Modelle. Im Silo-Modell erhält jeder Mandant dedizierte Ressourcen. Im Pool-Modell teilen sich die Mandanten die Infrastruktur, und die Trennung wird in Code und Daten durchgesetzt. Das Bridge-Modell kombiniert beide, zum Beispiel eine gemeinsame Anwendung mit separaten Datenbanken für regulierte Kunden. Die meisten B2B-MVPs starten im Pool, mit einer Mandanten-ID auf jeder mandantenbezogenen Zeile. PostgreSQL Row-Level Security kann diesen Filter in der Datenbank durchsetzen, statt sich auf jede einzelne Abfrage zu verlassen, und automatisierte Tests sollten belegen, dass ein Mandant nie die Daten eines anderen lesen kann.

Identität und Zugriff. Schreiben Sie Passwortspeicherung und Session-Handling nicht selbst. Nutzen Sie ein bewährtes Framework oder einen Identity Provider, bieten Sie Multi-Faktor-Authentifizierung von Anfang an an und entwerfen Sie Rollen, bevor der zweite Kunde danach fragt. Grössere Kunden werden Single Sign-on verlangen; eine Identitätsschicht auf Basis von Standardprotokollen macht daraus eine Konfiguration statt eines Neubaus.

Billing. Abos bringen Pläne, Testphasen, Upgrades und Downgrades mit anteiliger Verrechnung, fehlgeschlagene Zahlungen, Rechnungen mit korrekter MWST und Kündigungen mit sich. Ein Billing-Anbieter wie Stripe Billing übernimmt vieles davon. Ihr Produkt braucht aber trotzdem eine Prüfung der Nutzungsrechte, die entscheidet, was jeder Mandant nutzen darf, und eine zuverlässige Verarbeitung der Webhooks des Anbieters: signiert, mit Wiederholungen und ohne Duplikate, wie im Beitrag CRM-Automatisierung: Wo anfangen? beschrieben.

Admin-Backoffice. Ihr Support muss einen Mandanten finden, seinen Plan und seine Nutzung sehen, Zugänge zurücksetzen und, mit Einwilligung des Kunden, das Produkt so sehen können, wie der Kunde es sieht. Jede solche Aktion gehört in ein Audit-Log. Ohne Backoffice wird jedes Support-Ticket zu einer Datenbankabfrage für einen Entwickler.

Observability und APIs. Strukturierte Logs mit Mandanten- und Request-IDs, Metriken, Traces und Alarme zeigen ein Problem, bevor Kunden es melden. Als wir ein Verzeichnis von Kommunikations-APIs gebaut haben, stellten wir dieselben Daten über eine öffentliche REST-API mit OpenAPI-Dokument und über einen MCP-Server mit reinem Lesezugriff bereit. So fragen Entwickler und KI-Agenten dieselben Fakten ab, die auch die Website zeigt.

Wie sieht eine Checkliste für die Produktionsreife aus?

Ein SaaS ist produktionsreif, wenn jemand es an einer anerkannten Referenz prüfen könnte und es weitgehend bestehen würde. Ordnen Sie Ihre Checkliste drei Referenzen zu: NIST SSDF für den Entwicklungsprozess, OWASP ASVS für die Sicherheitsmassnahmen der Anwendung und die AWS Well-Architected SaaS Lens für Mandantentrennung, Betrieb und Kosten. Die Tabelle zeigt, was «bereit» in jedem Bereich konkret heisst.

Bereich	«Bereit» heisst	Referenz
Sicherer Entwicklungsprozess	Review jeder Änderung, Scans auf Abhängigkeiten und Secrets, geschützter Main-Branch, dokumentierter Release-Prozess, ein Kanal für Meldungen von Schwachstellen	NIST SP 800-218 (SSDF 1.1): Organisation vorbereiten, Software schützen, gut gesicherte Software produzieren, auf Schwachstellen reagieren
Anwendungssicherheit	Authentifizierung, Sessions, Zugriffskontrolle, Eingabeverarbeitung und Logging geprüft gegen das ASVS-Level, zu dem Sie sich verpflichten	OWASP ASVS 5.0
Mandantentrennung	Trennung unterhalb des Anwendungscodes durchgesetzt; automatisierte Tests gegen mandantenübergreifende Zugriffe	SaaS Lens: Silo-, Pool- und Bridge-Modell
Zuverlässigkeit	Automatische Backups, planmässig getestete Wiederherstellungen, definierte Ziele für Recovery Point und Recovery Time, Health Checks	Well-Architected, Säule Zuverlässigkeit
Betrieb	Logs mit Mandanten- und Request-IDs, Alarme, die bei einer Person ankommen, Runbooks, eine Statusseite	SaaS Lens, Operational Excellence
Auslieferung	Tests in der CI bei jeder Änderung, eine Staging-Umgebung, Migrationen in der Pipeline, Rollback	DORA-Kennzahlen zur Softwareauslieferung
Datenschutz	Verzeichnis der Bearbeitungstätigkeiten, Verträge mit Auftragsbearbeitern, Datenschutzerklärung, Verfahren für Datenschutzverletzungen	DSG und DSGVO (nächster Abschnitt)
Kosten	Kosten pro Mandant sichtbar; Budgets und Alarme	SaaS Lens, Kostenoptimierung

Wir messen die Systeme, die wir bauen, an derselben Liste. Dieses API-Verzeichnis durchläuft vor jedem Deploy mehrere Prüfungen (Datenschema, Verifikation der Scores, Link-Audit, Inhaltsprüfungen und ein Vertraulichkeits-Scan), und ein Pre-Commit-Hook blockiert jeden Commit, der einen Secret-Wert enthält. Eine Outreach-Plattform, die wir für einen SaaS-Kunden gebaut haben, folgt dem Fail-closed-Prinzip: Ihr Dashboard startet ohne Authentifizierung nicht auf einer öffentlichen Adresse. Passwörter werden gehasht, wiederholte Fehlversuche beim Login führen zu einer Sperre, und schreibende Aktionen sind nach Rolle eingeschränkt.

Was verlangen DSG und DSGVO von einem SaaS-Produkt?

Das revidierte Datenschutzgesetz (DSG) gilt für Bearbeitungen, die sich in der Schweiz auswirken (Art. 3). Die DSGVO gilt zusätzlich, wenn Sie das Produkt Personen in der EU anbieten. Beide verlangen Datenschutz durch Technik und datenschutzfreundliche Voreinstellungen, Verträge mit Auftragsbearbeitern, ein Verzeichnis der Bearbeitungstätigkeiten und ein Verfahren für Datenschutzverletzungen. Als Anbieter sind Sie für die Daten Ihrer Kunden meist Auftragsbearbeiter und für Ihre eigenen Konto- und Billing-Daten Verantwortlicher.

• Technik und Voreinstellungen: Art. 7 DSG, Art. 25 DSGVO. Erheben Sie nur, was die Funktion braucht, und machen Sie die datenschutzfreundliche Einstellung zum Standard.
• Auftragsbearbeiter: Kunden erwarten von Ihnen einen Auftragsbearbeitungsvertrag (Art. 9 DSG, Art. 28 DSGVO). Sie selbst brauchen einen mit jedem Unterauftragsbearbeiter, etwa für Hosting, E-Mail-Versand, Helpdesk und Analytics. Nach DSG darf ein Auftragsbearbeiter die Bearbeitung nur mit vorgängiger Genehmigung des Verantwortlichen einem Dritten übertragen.
• Verzeichnis der Bearbeitungstätigkeiten: Art. 12 DSG, mit Ausnahmen für Unternehmen unter 250 Mitarbeitenden, deren Bearbeitung ein geringes Risiko birgt; Art. 30 DSGVO.
• Verletzungen der Datensicherheit: Nach DSG meldet der Verantwortliche dem EDÖB so rasch als möglich, wenn eine Verletzung voraussichtlich zu einem hohen Risiko führt (Art. 24), und Auftragsbearbeiter müssen den Verantwortlichen informieren. Die DSGVO setzt möglichst 72 Stunden (Art. 33).
• Export: Das DSG gibt betroffenen Personen ein Recht auf Datenherausgabe und -übertragung (Art. 28). Bauen Sie den Datenexport deshalb früh.
• KI-Funktionen: Nutzt das Produkt KI und wird es in der EU angeboten, prüfen Sie, ob die EU-KI-Verordnung (Verordnung (EU) 2024/1689) auf Ihren Anwendungsfall zutrifft.

Wo sollte ein Schweizer SaaS gehostet werden?

Das Schweizer Recht verlangt kein Hosting in der Schweiz. Das DSG erlaubt die Bekanntgabe in Staaten, denen der Bundesrat einen angemessenen Datenschutz attestiert, darunter alle EU- und EWR-Staaten, und in andere Staaten mit Garantien wie anerkannten Standardvertragsklauseln. Hosting in der Schweiz wird zur Anforderung, wenn Kunden es verlangen, etwa manche im Finanz- oder Gesundheitswesen oder in der öffentlichen Verwaltung. Fragen Sie deshalb Ihre ersten Kunden, bevor Sie sich entscheiden.

Option	Passt zu	Zu beachten
Hyperscaler-Region in der Schweiz (AWS Zürich seit November 2022; Google Cloud Zürich)	Produkten, die Managed Services und Datenhaltung in der Schweiz brauchen	Prüfen, ob die benötigten Managed Services in dieser Region verfügbar sind
Schweizer Hosting-Anbieter	Kunden, die neben dem Schweizer Standort auch einen Schweizer Anbieter wollen	Weniger Managed Services, mehr Betriebsaufwand
EU-Region oder EU-Anbieter	Den meisten B2B-SaaS ohne Anforderung an Hosting in der Schweiz	Standort in Datenschutzerklärung und Verzeichnis offenlegen

Der Datenstandort betrifft mehr als die Hauptdatenbank. Backups, Logs, E-Mail-Versand, Fehler-Tracking, Support-Tools und Analytics sind ebenfalls Auftragsbearbeiter, und jeder davon gehört auf dieselbe Liste.

Was ändert sich nach dem Launch?

Nach dem Launch verschiebt sich die Arbeit vom Bauen neuer Funktionen zum Betreiben eines Service. Sie brauchen einen Supportprozess mit Reaktionszeiten, einen Weg, aus Vorfällen zu lernen, Kennzahlen, die zeigen, ob Kunden bleiben, und eine Roadmap, die Kapazität für Sicherheitsupdates und technische Schulden reserviert. Budgetieren Sie das vor dem Launch: Ein SaaS zu betreiben ist ein monatlicher Kostenpunkt, kein einmaliges Projekt.

Verfolgen Sie zwei Arten von Kennzahlen. Produktkennzahlen zeigen, ob das Geschäft funktioniert: Aktivierung, Kundenbindung, Churn und monatlich wiederkehrender Umsatz (MRR). Delivery-Kennzahlen zeigen, ob das Team das Produkt weiterhin sicher verändern kann; DORA definiert derzeit fünf: Change Lead Time, Deployment-Frequenz, Wiederherstellungszeit nach fehlgeschlagenen Deployments, Change Fail Rate und Deployment Rework Rate.

Was bestimmt die Kosten einer SaaS-Entwicklung?

Die Kosten folgen der Komplexität, nicht der Zahl der Screens. Die wichtigsten Treiber sind die Zahl der Benutzerrollen und Berechtigungen, Integrationen, die Komplexität des Billings, das Sicherheitsniveau, das Ihre Kunden verlangen, das Mandantenmodell, Sprachen, Datenmigration aus bestehenden Tools und allfällige KI-Funktionen. Preislisten veröffentlichen wir nicht; nach einer kurzen Analysephase erhalten Sie eine Offerte zum Festpreis oder in Etappen für das MVP und die Härtungsphase.

Das billigste MVP wird bei der Korrektur oft am teuersten. Wer das Mandantenmodell oder das Berechtigungskonzept überspringt, verschiebt diese Kosten in die Härtungsphase, wenn echte Kundendaten jede Änderung riskanter machen.

Welche Fehler passieren am häufigsten?

Holprige Übergänge vom MVP in die Produktion haben meist dieselben Fehler gemeinsam: bauen, bevor validiert ist, Mandantentrennung nachträglich einbauen, Authentifizierung selbst schreiben, Billing als Checkout-Button behandeln, Staging und Restore-Tests auslassen, Personendaten in Logs schreiben und ein kleines Produkt zu früh in viele Services aufteilen. Jeder dieser Fehler lässt sich im MVP günstig vermeiden und wird teuer, sobald zahlende Kunden vom System abhängen.

Wie Sensaria ein SaaS vom MVP in die Produktion bringt

Wir entwerfen Mandantenmodell, Berechtigungen und Billing während des MVP und ordnen Sicherheits- und Betriebsarbeiten vor dem Launch ASVS, SSDF und der SaaS Lens zu. Das Verzeichnis von Kommunikations-APIs, das wir gebaut haben, zeigt den Ansatz: ein Datenmodell mit einer belegten Quelle pro Feld, eine öffentliche API und ein MCP-Server sowie Prüfungen, die vor jedem Deploy laufen.

Haben Sie ein MVP, einen Prototyp oder eine No-Code-Version, die zur produktiven Plattform werden soll? Lesen Sie mehr zur SaaS-Entwicklung oder schicken Sie uns ein kurzes Briefing.