--- title: "SaaS-Plattformen und Cloud-Anwendungen entwickeln | SKAFFON" description: "SaaS-Entwicklung für B2B: Mandantenmodelle im Vergleich, Row-Level-Security in PostgreSQL, Stripe-Billing, Identität mit OIDC und Kubernetes-Betrieb." url: https://skaffon.de/software/saas-entwicklung/ --- ![Nahaufnahme blauer Netzwerkkabel in einem Patchpanel eines Server-Racks](/_astro/blauer-netzwerkkabel-patchpanel-server.WRSYC4xw_ZM2W8U.jpg) 1. [Startseite](/) 2. [Software](/software/) 3. SaaS-Plattformen und Cloud-Anwendungen entwickeln SaaS-Entwicklung · mandantenfähig # SaaS-Plattformen und Cloud-Anwendungen entwickeln Sie wollen Ihre Anwendung als Dienst für eigene Kunden anbieten. Wir bauen das Produkt und treffen mit Ihnen die frühen, schwer umkehrbaren Entscheidungen zu Mandantentrennung, Identität und Abrechnung. [Projekt anfragen](/projekt-anfragen/) [Zur Mandantenmodell-Matrix](/software/saas-entwicklung/#welches-mandantenmodell-traegt-ihr-produkt) - Mandantentrennung in PostgreSQL - Identität über OpenID Connect - Optional Abrechnung über Stripe - Betrieb auf Kubernetes Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Ausgangslage ## Vier Festlegungen, die ein SaaS-Produkt ein Leben lang begleiten Bei SaaS entscheiden wenige frühe Festlegungen über Sicherheit, Kosten und Skalierbarkeit der gesamten Lebensdauer. Wer sie nachträglich ändert, ändert das Produkt. Diese Seite richtet sich an Geschäftsführung, CTOs und Produktverantwortliche, die ein Produkt aufbauen und diese Entscheidungen von Anfang an richtig treffen wollen. Für die interne Fachanwendung statt eines Produkts siehe [Individuelle Softwareentwicklung](/software/individualsoftware/). - **Mandantenmodell:** wie werden Daten verschiedener Kunden getrennt? - **Identität:** wie melden sich Nutzer an, wie werden Rollen je Mandant verwaltet? - **Abrechnung:** wie hängen Tarife, Nutzung und Zugriffsrechte zusammen? - **Betrieb:** welche Umgebung, welche Verfügbarkeitsziele, wer ist rufbereit? ![Eine Person skizziert mit Marker auf einem Whiteboard einen Ablauf mit den Stichworten APIs und Feedback](/_astro/whiteboard-architektur-skizze.BPjACt_o_ZMmppz.jpg) Mandantenmodell ## Welches Mandantenmodell trägt Ihr Produkt? Drei Wege, Kundendaten zu trennen. Keiner ist grundsätzlich richtig; er muss zu Mandantenzahl und Trennungsanforderung passen. __Mandantenmodelle im Vergleich: gemeinsames Schema, Schema je Mandant, Datenbank je Mandant__ | Kriterium | Gemeinsames Schema (Mandantenkennung je Zeile) | Schema je Mandant | Datenbank je Mandant | | ----------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------ | | Trennung | logisch, muss konsequent durchgesetzt werden | stärker, innerhalb einer Datenbank | stark, getrennte Instanzen | | Betriebsaufwand bei vielen Mandanten | gering | mittel (viele Schemas, Migrationen je Schema) | hoch (viele Datenbanken) | | Schemaänderungen | eine Migration | eine Migration je Schema | eine Migration je Datenbank | | Auswertungen über Mandanten | einfach | möglich, aufwendiger | aufwendig | | Individuelle Wiederherstellung je Mandant | schwer | möglich | einfach | | Passt, wenn | viele kleine bis mittlere Mandanten, einheitliche Anforderungen | mittlere Zahl Mandanten, höhere Trennungswünsche | wenige große Mandanten mit strengen Vorgaben (Datenort, Isolation) | | Risiko | Programmierfehler legt Fremdmandanten-Daten offen | Betriebsaufwand wächst mit Mandantenzahl | Kosten und Betriebsaufwand je Mandant | PostgreSQL ## Row-Level Security: wo die Trennung wirklich hält Beim gemeinsamen Schema setzen wir PostgreSQL [Row-Level Security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) ein: Richtlinien legen fest, welche Zeilen eine Sitzung sehen oder ändern darf, ohne Richtlinie sind standardmäßig keine Zeilen sichtbar. Wichtig: Superuser und Rollen mit `BYPASSRLS` umgehen die Sicherheit immer, Tabelleneigentümer standardmäßig auch, solange die Tabelle nicht mit `FORCE ROW LEVEL SECURITY` gesetzt ist. Deshalb verwendet die Anwendung eine eigene Rolle ohne diese Rechte, und die Mandantenkennung wird pro Verbindung oder Transaktion gesetzt und im Test gegengeprüft. Datenbankdetails: [PostgreSQL-Beratung und Datenbankarchitektur](/daten/postgresql-datenbanken/). Abnahmekriterien ## Acht Prüfpunkte, bevor ein Mandant echte Daten einträgt - Jede Tabelle mit Mandantendaten trägt die Mandantenkennung oder liegt im Schema des Mandanten. - Trennung wird in der Datenbank durchgesetzt (Row-Level Security), nicht nur in der Anwendung. - Anwendungsrolle ist weder Eigentümer noch Superuser noch `BYPASSRLS`. - Automatisierte Tests prüfen aktiv, dass Mandant A keine Daten von Mandant B lesen, ändern oder löschen kann, auch über Verknüpfungen, Hintergrundjobs und Exporte. - Caches, Suchindizes, Dateiablagen und Protokolle sind ebenfalls mandantengetrennt. - Administrative und Support-Zugriffe laufen über eigene, protokollierte Wege. - Sicherung und Wiederherstellung sind je Mandant beschrieben (Granularität, Dauer), soweit zugesagt. - Löschung und Datenexport eines Mandanten sind als Funktion vorhanden. Architektur ## Der Weg einer Anfrage durch die Plattform Vom Nutzer eines Mandanten über Identität und Anwendung bis in die Datenbank. Die Vertrauensgrenze zwischen Mandant A und Mandant B verläuft durch alle Schichten. Schichtenbild einer mandantenfähigen SaaS-Plattform Schichtenbild einer mandantenfähigen SaaS-Plattform Identität ## Anmeldung, Rollen und Single Sign-On je Mandant Anmeldung über OpenID Connect, wahlweise mit Anbindung an Kunden-Identitätssysteme (Single Sign-On je Mandant), Rollen und Berechtigungen je Mandant, Prüfung der Mandantenzugehörigkeit bei jedem Zugriff. Das Zugriffsmodell richtet sich nach [IAM und Zero Trust](/cybersecurity/iam-zero-trust/). Abrechnung ## Stripe-Webhooks: der Teil, der in der Praxis Fehler verursacht Wenn Sie Abonnements oder Nutzung abrechnen, binden wir Stripe an. Nach der [Stripe-Dokumentation zu Webhooks](https://docs.stripe.com/webhooks) gelten unter anderem diese Regeln, die wir umsetzen. Tarife und Berechtigungen werden aus dem Abrechnungszustand abgeleitet und in Ihrer Datenbank geführt; die Zuordnung eines Ereignisses zu Ihrem Mandanten erfolgt über eigene Kennungen, nicht über Annahmen. Ob Stripe oder ein anderer Dienst passt, klären wir mit Ihnen; Stripe ist optional. - Die Signatur jedes Ereignisses wird mit dem Signaturgeheimnis des Endpunkts geprüft, auf Basis des unveränderten Roh-Bodys. - Der Endpunkt antwortet schnell mit 2xx, bevor aufwendige Logik läuft; die Verarbeitung erfolgt asynchron über eine Warteschlange. - Doppelte Zustellungen werden über die Ereignis-ID erkannt (bereits verarbeitete IDs werden protokolliert). - Die Reihenfolge der Ereignisse ist nicht garantiert; die Verarbeitung darf nicht von ihr abhängen. - Nur die tatsächlich benötigten Ereignistypen werden abonniert. ![Aufgeklappter Laptop mit Entwicklungsumgebung und Programmcode auf einem Holztisch](/_astro/aufgeklappter-laptop-entwicklungsumgebung-programmcode.Badmi_cx_Z1hBnJe.jpg) Betrieb ## Absichern, ausliefern, betreiben Verfügbarkeitszusagen an Ihre Kunden setzen wir erst, wenn Architektur und Betrieb sie tragen. - ### [Absicherung in der Pipeline](/cybersecurity/devsecops-supply-chain/) Geheimnisse außerhalb des Codes, Prüfungen in der Lieferkette: [DevSecOps und Software-Lieferketten](/cybersecurity/devsecops-supply-chain/). - ### [Härtung auf Kubernetes](/cybersecurity/kubernetes-security/) Netzwerkbeschränkung und Härtung: [Kubernetes Security](/cybersecurity/kubernetes-security/). - ### [Auslieferung per CI/CD](/leistungen/ci-cd-pipelines/) Automatisierte Auslieferung und, wo gewünscht, GitOps: [CI/CD-Pipelines](/leistungen/ci-cd-pipelines/). - ### [Plattform Ihrer Wahl](/stackit/) Betrieb auf Kubernetes in Ihrer Umgebung oder auf [STACKIT](/stackit/) bzw. in einer [Private Cloud](/infrastruktur/private-cloud/). - ### [Betrieb durch SKAFFON](/managed-services/managed-kubernetes/) Auf Wunsch: [Managed Kubernetes](/managed-services/managed-kubernetes/) und [Managed PostgreSQL](/managed-services/managed-postgresql/). - ### [Cloud-native Muster](/software/cloud-native-entwicklung/) Architekturmuster für Dienste, Beobachtbarkeit und Resilienz: [Cloud-native Entwicklung](/software/cloud-native-entwicklung/). Projektablauf ## Vom Produktzuschnitt bis zur Übergabe 1. 01 ### Produktzuschnitt Ergebnis: ADRs Zielkunden, Mandantenanforderungen, Tarifmodell, Betriebsanforderungen; Entscheidungen als ADR. 2. 02 ### Fundament Ergebnis: Plattform Mandantenmodell, Identität, Pipeline, Plattformanbindung, Beobachtbarkeit. 3. 03 ### Kernfunktionen Etappen Umsetzung in Etappen mit Demonstration; Billing-Anbindung, wo gewünscht. 4. 04 ### Härtung Ergebnis: Nachweise Mandanten-Isolationstests, Lasttests, Sicherheitsprüfungen, Wiederherstellungstest. 5. 05 ### Übergabe Ergebnis: Betrieb Übergabe an Ihr Team oder in den Betrieb durch SKAFFON. Technologie ## Womit wir SaaS-Produkte bauen Sprachen - Go - TypeScript Daten und Plattform - PostgreSQL - Kubernetes Identität und Abrechnung - OIDC - Stripe (optional) Passung ## Wann Sie kein individuelles SaaS-Projekt brauchen Aufwand bestimmen Funktionsumfang, Mandantenmodell, Zahl der Integrationen (Identität, Billing, Fremdsysteme), Anforderungen an Verfügbarkeit, Isolation und Datenort sowie der Betriebsanteil. ### Das passt zu uns - Sie bauen ein eigenes Produkt mit mandantenfähiger Architektur. - Sie wollen die schwer umkehrbaren Entscheidungen früh und dokumentiert treffen. ### Das passt nicht - Eine bestehende SaaS-Standardlösung deckt Ihr Geschäftsmodell ab. - Sie suchen Produktstrategie oder Marketing, nicht technische Umsetzung. - Sie erwarten einen Festpreis für ein Produkt, dessen Funktionsumfang noch nicht abgegrenzt ist. ## Häufige Fragen Warum reicht Mandantentrennung in der Anwendung allein nicht? Ein einzelner Programmierfehler kann dann Daten eines anderen Mandanten offenlegen. Deshalb wird die Trennung in der Datenbank durchgesetzt, etwa mit Row-Level Security, und mit automatisierten Tests gegengeprüft. Ist Stripe für die Abrechnung Pflicht? Nein. Stripe ist eine gängige Wahl, aber kein Bestandteil, den wir voraussetzen. Wir wählen den Zahlungsdienst gemeinsam mit Ihnen nach Zielmärkten und Abrechnungsmodell. Nennen Sie Verfügbarkeitszahlen für meine Kunden? Nicht pauschal. Eine Zahl, die Sie Ihren Kunden zusagen, muss durch Architektur, Wiederherstellungstests und Betriebsmodell gedeckt sein. Erst dann sagen wir sie zu. Wer betreibt das Produkt nach dem Start? Entweder Ihr Team nach der Übergabe oder auf Wunsch SKAFFON, zum Beispiel über [Managed Kubernetes](/managed-services/managed-kubernetes/). ## Beschreiben Sie Produkt, Zielkunden und Abrechnungsmodell Mit diesen drei Angaben können wir die Mandantenfrage und den Projektzuschnitt konkret besprechen. Weitere Leistungen: [Software Engineering](/software/). [Projekt anfragen](/projekt-anfragen/)