SaaS-Plattform-Engineering: vom MVP zur Skalierung, mit eingebetteten KI-Funktionen

Dieser Leitfaden richtet sich an Gründer, Product Leader und CTOs, die ein neues SaaS-Produkt planen oder eines retten möchten, das seiner ersten Architektur entwachsen ist. Er erklärt die Entscheidungen, die früh günstig und später teuer zu ändern sind – in der Reihenfolge, in der Sie ihnen begegnen –, einschließlich der Integration von KI-Funktionen in ein mandantenfähiges Produkt. Als Praxisbeispiel dient Printcart, das Web-to-Print-SaaS, das Netbase entworfen, gebaut hat und als eine seiner Business Divisions betreibt.

Inhaltsübersicht

• Die zwei Hälften jeder SaaS-Plattform
• Wahl des Mandantenmodells
• Abrechnung, Metering und Berechtigungen
• Cloud-Kosten und Stückkosten
• KI-Funktionen in einem mandantenfähigen Produkt
• Sicherheit ab dem ersten Release
• Vom MVP zur Skalierung: Phasen und Zeitrahmen
• Foundation bauen oder wiederverwenden
• Praxisbeispiel: Printcart
• Checkliste für Architekturentscheidungen
• Häufige Fehler
• Grenzen dieses Leitfadens
• Häufig gestellte Fragen
• Wie dieser Leitfaden entstanden ist
• Nächster Schritt

Die zwei Hälften jeder SaaS-Plattform

Ein SaaS-Produkt besteht aus zwei Systemen, die gemeinsam ausgeliefert werden. Die Anwendungsebene ist das, wofür Kunden zahlen: Ihre Funktionen, Workflows und Daten. Die Steuerungsebene macht daraus einen Service: Registrierung und Onboarding, Mandanten-Provisionierung, Identität, Rollen, Pläne, Abrechnung, Metering, Admin-Tools und Betriebsüberwachung.

Teams, die diese Unterscheidung übergehen, bauen die Steuerungsebene versehentlich auf – eine Abkürzung nach der anderen – und zahlen dafür, wenn der hundertste Kunde eintrifft. Teams, die sie bewusst planen, können Preise ändern, Kunden ohne Entwickler onboarden und sehen, welcher Mandant was kostet.

Das AWS SaaS Lens macht denselben Punkt von der anderen Seite: Selbst wenn Mandanten dedizierte Ressourcen haben, ist eine SaaS-Umgebung noch immer auf gemeinsame Identität, Onboarding und Betrieb angewiesen. Diese gemeinsame Schicht ist es, die ein SaaS-Produkt von der Bereitstellung separater Software-Kopien für jeden Kunden unterscheidet.

Wahl des Mandantenmodells

Die Mandantenfähigkeit ist die folgenreichste Architekturentscheidung im SaaS-Bereich, da sie gleichzeitig Kosten, Isolation, Compliance und Betrieb beeinflusst. AWS beschreibt drei Muster:

Für die meisten neuen Produkte ist ein gepoolter Kern mit der Option, einzelne Mandanten oder Dienste zu isolieren, der praktische Ausgangspunkt. Er hält den MVP günstig im Betrieb und lässt einen Pfad für Unternehmenskunden offen, die dedizierten Datenspeicher benötigen. Unser Leitfaden zur mandantenfähigen SaaS-Architektur vertieft die Themen Isolation, Abrechnung und Skalierung.

Unabhängig vom gewählten Modell gelten drei Praktiken:

• Mandantenkontext überall mitführen. Jede Anfrage, jeder Job, jede Log-Zeile und jede Metrik sollte wissen, zu welchem Mandanten sie gehört – entnommen aus der authentifizierten Identität, niemals aus einem Wert, den der Client ändern kann.
• Isolation unterhalb der Anwendung erzwingen. Verwenden Sie Datenbankrichtlinien, scoped Credentials oder mandantenspezifische Schlüssel, damit ein fehlender Filter in einer Abfrage nicht die Daten eines anderen Mandanten exponieren kann.
• Für Noisy Neighbours planen. Rate-Limits, mandantenspezifische Kontingente und Fairness bei Hintergrundprozessen verhindern, dass ein ressourcenintensiver Mandant die übrigen verlangsamt.

Abrechnung, Metering und Berechtigungen

Pricing ist eine Produktentscheidung, die sich häufig ändert. Die Architektur sollte es dem Business ermöglichen, sie ohne Entwickler zu ändern.

• Berechtigungen von Plänen trennen. Code sollte fragen: „Hat dieser Mandant Berechtigung für Funktion X bis Limit Y?“ – niemals: „Ist dieser Mandant im Pro-Plan?“ Pläne werden dann zu Konfiguration, die auf Berechtigungen abbildet.
• Metering ab dem ersten Release. Nutzungsereignisse pro Mandant und Funktion erfassen, auch wenn das erste Pricing ein Flat-Abo ist. Nutzungsdaten zeigen später, wie man preist und was jeder Mandant kostet.
• Zahlungsanbieter für Kartendaten verwenden. Lassen Sie den Anbieter Kartenerfassung, Tokenisierung und wiederkehrende Zahlungen übernehmen, und halten Sie Kartendaten aus Ihren eigenen Systemen heraus.
• Den Lebenszyklus planen, nicht nur die Belastung. Testphasen, Upgrades, Downgrades, Prorata-Abrechnung, fehlgeschlagene Zahlungen, Kulanzzeiten, Kündigungen und Datenaufbewahrung benötigen alle definiertes Verhalten vor dem Launch.
• Finance einen Überblick geben. Umsatz-, Churn- und Zahlungsausfall-Berichte gehören in die Admin-Konsole, nicht in manuelle Exporte.

Cloud-Kosten und Stückkosten

Im SaaS-Bereich sind Cloud-Kosten Teil der Herstellungskosten. Die Frage lautet nicht nur „Was kostet die Plattform?“, sondern „Was kostet jeder Mandant, und deckt sein Preis das?“.

Die FinOps Foundation definiert FinOps als operatives Framework und kulturelle Praxis, die den Geschäftswert von Technologie maximiert und durch Zusammenarbeit zwischen Engineering, Finance und Business-Teams finanzielle Verantwortung schafft. Für ein SaaS-Produkt wird daraus eine Reihe konkreter Gewohnheiten:

Die Wahl des Providers ist weniger entscheidend als diese Gewohnheiten. Netbase arbeitet mit AWS, Google Cloud, DigitalOcean und Cloudflare; das Produkt läuft in dem Cloud-Konto, das der Kunde wählt – es wird kein Cloud-Partner-Tier beansprucht. Ein kleines Produkt kann mit einfacherer Infrastruktur starten und bei Bedarf durch Last-, Compliance- oder regionale Anforderungen zu einem größeren Provider wechseln, sofern die Anwendung portabel gebaut ist. Unser Leitfaden zu Cloud-Kostenkontrolle für SaaS macht diese Gewohnheiten zu funktionierenden Steuerungsmechanismen.

KI-Funktionen in einem mandantenfähigen Produkt

Kunden erwarten heute, dass SaaS-Produkte innerhalb des Workflows, für den sie zahlen, zusammenfassen, suchen, entwerfen und Fragen beantworten. Diese Funktionen berühren alle oben genannten Entscheidungen: Sie lesen Mandantendaten, kosten Geld pro Aufruf und können Informationen leaken oder erfinden. Planen Sie sie in die Plattform ein, statt sie nachträglich auf einem Bildschirm zu ergänzen.

• Mandantenspezifisches Retrieval. Ein Assistent, der Dokumente durchsucht, darf nur die Daten des aktuellen Mandanten abfragen – und nur das, was der Nutzer sehen darf. Führen Sie einen separaten Index oder einen obligatorischen Mandantenfilter unterhalb der Anwendung, genau wie bei der Datenbank.
• Standardmäßig kein mandantenübergreifendes Lernen. Kein gemeinsames Modell auf den Daten eines Kunden feinabstimmen und keinen Modellanbieter damit trainieren lassen. Bieten Sie ein mandantenspezifisches Opt-in an, wo Lernen aus der Nutzung Mehrwert schafft, und schreiben Sie es in die Bedingungen.
• Modellkosten pro Mandant. Modellaufrufe und Token pro Mandant und Funktion messen, auf Berechtigungen abbilden und Obergrenzen setzen. KI ist oft die erste Funktion, bei der ein ressourcenintensiver Mandant die Marge eines Plans aufzehren kann – deshalb als Add-on, Nutzungsgebühr oder Limit bepreisen.
• Modellwahl hinter einer Schnittstelle. Modellaufrufe hinter einer eigenen Serviceschicht kapseln, damit Modell oder Anbieter je Funktion gewechselt werden können, wenn sich Preise und Qualität verändern – und um einem Unternehmenskunden zu dienen, der eine bestimmte Region oder ein privates Deployment benötigt.
• Evaluierung und menschliche Kontrolle. KI-Ausgaben vor jedem Release an einem festen Evaluierungsset testen, Nutzern anzeigen, wo Inhalte KI-generiert sind, und eine Bestätigung durch eine Person verlangen, wenn Aktionen Daten oder Geld verändern.

Netbase baut diese Funktionen mit produktspezifisch gewählten Modellen, nicht gebunden an einen KI-Anbieter; KI- und Datendienste decken die weitergehenden Arbeiten ab.

Sicherheit ab dem ersten Release

Mandantenisolation ist ein Zugriffskontrollproblem – und Zugriffskontrolle ist der häufigste Schwachpunkt von Webanwendungen: Die OWASP Top 10:2025 listet Broken Access Control an erster Stelle. Bei einem SaaS-Produkt kann eine einzige fehlende Mandantenprüfung die Daten eines Kunden einem anderen offenbaren – für viele junge Produkte ein geschäftskritisches Ereignis.

Diese Punkte sollten vom ersten Release an eingebaut sein:

• Mandantenspezifische Autorisierung an jedem Endpunkt und Hintergrundjob, mit automatisierten Tests, die versuchen, die Daten eines anderen Mandanten zu lesen.
• Starke Authentifizierung mit Multi-Faktor-Authentifizierung für Administratoren und Single Sign-on für Geschäftskunden, die es verlangen.
• Verschlüsselung im Transit und im Ruhezustand, mit Schlüsseln, die außerhalb des Anwendungscodes verwaltet werden.
• Sichere Auslieferung: Code-Review, Dependency-Scanning und ein Protokoll darüber, was wo deployt ist.
• Logging und Alerting, das die Frage beantworten kann: „Wer hat auf die Daten dieses Mandanten zugegriffen, und wann?“
• Backups und Recovery, getestet durch Wiederherstellung – nicht nur durch Ausführung des Backup-Jobs.
• KI-Eingaben als nicht vertrauenswürdig behandeln, damit ein Dokument oder Prompt einen Assistenten nicht anweisen kann, die Daten eines anderen Mandanten preiszugeben oder eine Genehmigung zu überspringen.

Unsere SaaS-Sicherheitscheckliste gliedert diese Liste in zehn Bereiche, jeweils mit den erforderlichen Nachweisen.

Die Netbase-Lieferpraxis folgt diesem Maßnahmenset: sicheres Code-Review und Versionskontrolle, TLS im Transit und AES im Ruhezustand, rollenbasierte Zugriffskontrolle, MFA für Admin-Dashboards, Schwachstellen-Scanning und Penetrationstests sowie Disaster-Recovery-Planung – NDAs, DPAs und SLAs auf Anfrage. Netbase hält die ISO-27001-Zertifizierung für Informationssicherheitsmanagement und eine SOC-2-Type-II-Attestierung. Diese decken ab, wie Netbase selbst arbeitet; Ihr Produkt und Hosting benötigen weiterhin eigene Kontrollen, Nachweise und – sofern Kunden es verlangen – eigene Audits.

Vom MVP zur Skalierung: Phasen und Zeitrahmen

Skalierung ist eine Abfolge unterschiedlicher Probleme, nicht ein einziges wachsendes Problem. Jede Phase sollte etwas beweisen, bevor die nächste beginnt.

Dies sind typische Bereiche von Netbase, keine Angebote. Die Anzahl der Workflows, Integrationen, Compliance-Anforderungen und die Reife der Produktentscheidungen bestimmen, wo ein Projekt landet. Ein MVP bleibt nur dann innerhalb von 8 bis 12 Wochen, wenn sein Umfang diszipliniert ist: ein Kern-Job, gut umgesetzt, mit den Grundlagen der Steuerungsebene. Unser SaaS-MVP-Architekturleitfaden behandelt diesen Umfang und die frühen Entscheidungen eingehend.

Was in den MVP gehört und was warten kann:

Foundation bauen oder wiederverwenden

Die Steuerungsebene sieht produktübergreifend ähnlich aus – daher ist sie der beste Kandidat für Wiederverwendung. Die Wiederverwendung produktisierter Module kann die Entwicklungszeit um bis zu 60 % reduzieren; die Einsparung hängt davon ab, wie viel des Produkts die Module abdecken, und gilt für die Modulwiederverwendung, nicht für das gesamte Produkt. Ihre Domänenfunktionen müssen weiterhin für Sie konzipiert und gebaut werden. Wenn das Produkt ein Shop statt eines mandantenfähigen Services ist, ist der Leitfaden zur individuellen E-Commerce-Plattform der bessere Ausgangspunkt.

Wiederverwendung ergibt Sinn, wenn:

• die Module Accounts, Mandanten, Rollen, Abrechnung, Admin und Integrationen abdecken, ohne Ihr Produkt in ihre Form zu zwingen;
• Sie das Eigentum am für Ihr Produkt erstellten Code behalten und die Lizenzbedingungen für wiederverwendete Module klar sind;
• die Module bereits in der Produktion laufen, nicht nur in einer Demo.

Netbase verpackt diesen Ansatz als SaaS-Produkt-Accelerator und baut die Produktfunktionen durch Web-Anwendungsentwicklung in agilen Sprints mit wöchentlichen Reviews, API-first, mit Sicherheit, die vom ersten Release an eingebaut ist. Gesamte Produkte, vom MVP bis zur Skalierung, werden durch SaaS-Entwicklung realisiert.

Praxisbeispiel: Printcart

Printcart ist ein Web-to-Print-SaaS, das Netbase entworfen, gebaut hat und betreibt. Es ist eine der fünf Netbase Business Divisions, neben CMSmart, Cloodo, Poslor und Storelly. Die öffentliche Produktwebsite beschreibt, was es tut: ein Online-Design-Studio für Kundenpersonalisierung, druckfertige Dateien für jede Bestellung, Druckauftragsmanagement mit Rechnungsstellung und Echtzeit-Status, Apps für Shopify, Wix und WooCommerce, eine REST-API mit Webhooks, Multi-Store- und Multi-Vendor-Betrieb sowie eine Druckauftrags-Fulfillment-API. Printcart läuft im eigenen Shop eines Händlers oder als Shopify-, Wix- und WooCommerce-App, mit einer Einrichtung in ca. 7 Tagen, und bedient 2.000+ Stores.

Auf die Entscheidungen dieses Leitfadens abgebildet, zeigt das Produkt, warum jede einzelne wichtig ist:

Die Lektion für andere Produkte ist die Integrationswahl. Printcart trifft Händler dort, wo sie bereits verkaufen – über Store-Apps – und bedient individuelle Builds dennoch über eine API. Viele B2B-SaaS-Produkte benötigen dieselben zwei Wege: einen gebündelten Connector für die gängigen Plattformen und eine API für alle anderen.

Der Printcart-Portfolio-Eintrag behandelt Umfang, Stack und Betrieb; es werden keine Performance-Kennzahlen veröffentlicht. Für den Branchenkontext siehe Druck und Verpackung, und für die druckseitige Architektur und die Build-or-Buy-Entscheidung den Web-to-Print-Plattform-Leitfaden.

Checkliste für Architekturentscheidungen

Verwenden Sie diese Fragen in der Architekturphase, vor dem ersten Sprint. Jede hat einen Verantwortlichen und eine schriftliche Antwort.

Wenn eine Frage keinen Verantwortlichen hat, ist sie ein Risiko, keine Entscheidung. Die Antworten in das Architekturprotokoll eintragen und bei jedem Phasenwechsel überprüfen, denn die richtige Antwort für einen MVP ist oft die falsche für eine Enterprise-Plattform.

Häufige Fehler

• Single-Tenant-Abkürzungen in einem mandantenfähigen Produkt. Hart codierte Kundeneinstellungen und nicht abgegrenzte Abfragen sind in Woche zwei günstig und in Jahr zwei teuer.
• Pricing im Code. Wenn eine Planänderung ein Release erfordert, warten Sales und Product bei jedem Experiment auf Engineering.
• Kein Metering bis nutzungsbasiertes Pricing gebraucht wird. Dann gibt es keine Historie, auf der man den Preis aufbauen könnte.
• Sicherheit als Launch-Aufgabe. Mandantenisolation, die am Ende hinzugefügt wird, ist schwer zu belegen und leicht zu übersehen.
• Skalieren vor Retention. In Enterprise-Funktionen zu investieren, bevor Kunden bleiben, bedeutet, auf der falschen Phase zu spenden.
• Ein KI-Index für alle Mandanten. Ein gemeinsamer Retrieval-Index ohne erzwungene Mandantenfilter verwandelt einen hilfreichen Assistenten in ein Datenleck.
• Kosten pro Mandant ignorieren. Ein Plan, der bei intensiven Nutzern Verluste macht, steigert seine Verluste mit seinem Erfolg.

Grenzen dieses Leitfadens

Dies ist praxisorientierte Orientierung aus Netbase-Liefererfahrung, keine Originalforschung oder Benchmark. Die Referenzen zu Mandantenfähigkeit, FinOps und Sicherheit beschreiben allgemeine Frameworks; ihre Anwendung hängt von Ihrem Produkt, Markt und Ihren Vorschriften ab. Zeitrahmen sind typische Bereiche, die vom Umfang abhängen, und die Wiederverwendungseinsparung von bis zu 60 % ist eine Obergrenze, die an Modulwiederverwendung gebunden ist. KI-Modellpreise und -fähigkeiten ändern sich schnell; der KI-Abschnitt gibt Designprinzipien, keine Kostenzahlen. Das Printcart-Beispiel beschreibt öffentlich genannte Fähigkeiten und Zahlen; dieser Leitfaden legt keine interne Implementierung offen. Netbases eigene Zertifizierungen erstrecken sich nicht auf das Produkt oder Hosting eines Kunden.

Wie dieser Leitfaden entstanden ist

Das Netbase Editorial Team hat diesen Leitfaden aus den veröffentlichten SaaS-, Sicherheits- und Modulbibliotheksseiten von Netbase, der Printcart-Produktwebsite und öffentlichen Frameworks von AWS, der FinOps Foundation und OWASP erstellt; David (CEO) hat alle Netbase-Fakten geprüft. Externe Quellen sind mit Zugriffsdaten zitiert. Der Entwurf wurde mit KI-Unterstützung erstellt (Claude); jede Netbase-Zahl ist auf einen verifizierten Unternehmenseintrag zurückführbar. Sein Zweck ist, einem Produktteam zu helfen, die frühen SaaS-Entscheidungen bewusst zu treffen, bevor sie teuer zu ändern sind.

Nächster Schritt

Wenn Sie ein SaaS-Produkt planen oder überarbeiten, teilen Sie Ihre Produktidee, Zielkunden und aktuelle Architektur mit, und wir vereinbaren ein Solution-Review, um Mandantenfähigkeit, Abrechnung und Lieferplan zu kartieren. Sie können auch den zugehörigen Service ansehen oder mehr Netbase Insights lesen.

Verwandte Leistungen und Lösungen