SaaS-Architektur: Was nicht-technische Gründer vor dem Aufbau wissen müssen

Es gibt eine besondere Art von Bedauern, die SaaS-Gründer etwa achtzehn Monate nach Projektbeginn ereilt. Das Produkt ist live, erste Kunden nutzen es — und dann sagt jemand: „Bevor wir X umsetzen können, müssten wir die Art und Weise, wie wir Mandanten verwalten, grundlegend umstrukturieren." Oder: „Das Abrechnungssystem wurde nicht für nutzungsbasierte Preisgestaltung entwickelt — ein Umbau würde drei Monate in Anspruch nehmen." Oder, am schlimmsten: „Diese Compliance-Anforderung erfordert eine datenbankbasierte Datenisolierung pro Kunde, aber das gesamte System teilt sich eine Datenbank."

Das sind keine Bugs. Es sind Architekturentscheidungen, die zu Beginn vernünftig erschienen und nun sehr kostspielig rückgängig zu machen sind.

Der Grund, warum dies so häufig vorkommt, liegt nicht daran, dass die Entwickler unachtsam waren. Es liegt daran, dass die Gründer nicht genügend Kontext hatten, um vor Beginn der Entwicklung die richtigen Fragen zu stellen — und das Entwicklungsteam deshalb das Schnellste, Einfachste oder Vertrauteste wählte, anstatt das, was für den angestrebten Produktweg am geeignetsten war.

Sie müssen kein Software-Architekt werden. Aber Sie brauchen ein ausreichendes Verständnis der wichtigsten Architekturentscheidungen in einem SaaS-Produkt, um an der Diskussion teilzunehmen, Annahmen zu hinterfragen und fundierte Abwägungen zu treffen. Dafür ist dieser Leitfaden gedacht.

---

Was ist SaaS-Architektur?

SaaS-Architektur bezeichnet die Designentscheidungen, die bestimmen, wie ein Softwareprodukt aufgebaut, gehostet und gewartet wird, sodass es mehrere Kunden gleichzeitig bedienen, Abonnements und Abrechnung automatisch verwalten, Nutzer ohne manuellen Eingriff einbinden und skalieren kann — ohne einen vollständigen Neuaufbau zu erfordern.

Ein gut entworfenes SaaS-Produkt weist fünf charakteristische Eigenschaften auf:

• Multi-Tenancy — mehrere Kunden (Mandanten) teilen sich die gleiche Anwendungsinfrastruktur, wobei ihre Daten angemessen voneinander getrennt werden
• Abonnementabrechnung — Kunden zahlen auf wiederkehrender Basis, und das Abrechnungssystem verwaltet Tarife, Testphasen, Upgrades, Downgrades und Verlängerungen automatisch
• Self-Service-Onboarding — Nutzer können sich anmelden, ihr Konto einrichten und das Produkt nutzen, ohne dass auf Ihrer Seite ein Mensch eingreifen muss
• API-First-Design — der Kern des Produkts wird über eine gut strukturierte API bereitgestellt, die Integrationen, mobile Apps und zukünftige Erweiterbarkeit unterstützt
• Cloud-gehostete Infrastruktur — das Produkt läuft auf Cloud-Infrastruktur, die je nach Bedarf hoch- oder herunterskaliert werden kann, anstatt auf festen Servern

Dies sind keine Funktionen, die später hinzugefügt werden können. Es handelt sich um Architekturmerkmale — entweder von Anfang an eingebaut oder später mühsam nachgerüstet. Die Entscheidungen, die bestimmen, ob Ihr Produkt diese Eigenschaften aufweist, werden in den ersten Wochen des Projekts getroffen.

---

Multi-Tenancy: Die wichtigste Entscheidung

Multi-Tenancy ist das grundlegende Architekturmerkmal von SaaS. Es ist auch die Entscheidung mit den weitreichendsten Konsequenzen — für Ihre Kostenstruktur, Ihre Compliance-Positionierung, Ihre Fähigkeit, Enterprise-Kunden individuell zu bedienen, und die Komplexität Ihrer Codebasis.

Es gibt drei primäre Modelle:

Das Pool-Modell (Geteilte Infrastruktur)

In einer Pool-Modell-Architektur teilen sich alle Kunden eine einzige Datenbank (und oft eine einzige Anwendungsinstanz). Ihre Daten werden durch eine Mandanten-ID-Spalte in jeder Datenbanktabelle getrennt. Eine Zeile gehört zu Unternehmen A, die nächste zu Unternehmen B — alles in derselben Tabelle.

Vorteile: Am günstigsten im Betrieb. Anfangs am einfachsten aufzubauen. Die Datenbankinfrastruktur skaliert einmalig anstatt einmal pro Kunde. Deployments und Updates erfolgen an einem einzigen Ort.

Nachteile: Eine falsch konfigurierte Abfrage kann die Daten eines Mandanten einem anderen zugänglich machen. Compliance-Frameworks, die Datenisolierung voraussetzen (SOC 2, ISO 27001, bestimmte Anforderungen im Gesundheitswesen), sind schwieriger zu erfüllen. Noisy-Neighbour-Probleme sind real — ein Mandant mit einer aufwendigen Abfrage kann alle anderen beeinträchtigen. Mandantenspezifische Konfigurationen werden kompliziert.

Das Silo-Modell (Vollständige Isolation)

In einer Silo-Modell-Architektur erhält jeder Kunde eine eigene isolierte Infrastruktur — eine eigene Datenbankinstanz, manchmal eine eigene Anwendungsumgebung. Die Daten eines Mandanten berühren die Daten eines anderen auf Infrastrukturebene niemals.

Vorteile: Echte Datenisolierung durch Design. Einfachere Erfüllung von Enterprise-Compliance-Anforderungen. Ein Problem in der Umgebung eines Mandanten kann andere nicht beeinträchtigen. Sie können verschiedene Produktversionen für unterschiedliche Enterprise-Kunden betreiben.

Nachteile: Im Betrieb bei wachsender Kundenzahl deutlich teurer. Das Management von Hunderten von Datenbankinstanzen ist operativ komplex. Deployments und Updates müssen über alle Silo-Umgebungen koordiniert werden. Mandantenübergreifende Analysen der eigenen Nutzungsdaten sind schwierig durchzuführen.

Das Bridge-Modell (Geteilte App, separate Schemata)

Das Bridge-Modell liegt zwischen den beiden anderen. Alle Mandanten nutzen dieselbe Anwendungsschicht, aber jeder Mandant erhält ein eigenes Datenbankschema (oder in manchen Implementierungen eine separate Datenbank innerhalb eines gemeinsam genutzten Clusters). Die Daten sind physisch getrennt, ohne den vollen Betriebsaufwand des Silo-Modells.

Vorteile: Bessere Datenisolierung als das Pool-Modell. Einfacher zu betreiben als vollständige Silos. Geeignet für Mittelstands- und Enterprise-Kunden mit moderaten Compliance-Anforderungen.

Nachteile: Komplexer aufzubauen als das reine Pool-Modell. Das Management von Datenbank-Migrationen wird schwieriger — Sie müssen dieselbe Migration über viele Schemata hinweg anwenden. Manche Tools unterstützen Multi-Schema-Setups nicht zuverlässig.

Modell	Infrastrukturkosten	Datenisolierung	Compliance-Eignung	Operative Komplexität
Pool (Geteilte DB)	Niedrig	Nur logisch	Grundlegend	Niedrig
Bridge (Geteilte App, separate Schemata)	Mittel	Physisch pro Mandant	Mittelstand/Enterprise	Mittel
Silo (Isoliert)	Hoch	Vollständige Isolation	Enterprise/Reguliert	Hoch

Die richtige Antwort hängt von Ihrem Markt ab. Wenn Sie an KMU verkaufen und keine Enterprise-Kunden aus regulierten Branchen erwarten, ist ein gut implementiertes Pool-Modell durchaus sinnvoll. Wenn Ihr Produkt-Roadmap den Verkauf an Finanzdienstleister, Gesundheitsunternehmen oder große Unternehmen mit Sicherheitsfragebögen umfasst, ist die Antwort fast sicher ein Bridge- oder Silo-Ansatz — und die Kosten für eine nachträgliche Datenisolierung sind enorm.

Dies ist eine Entscheidung, die getroffen werden muss, bevor eine einzige Codezeile geschrieben wird.

---

Authentifizierung und Identität

Authentifizierung — die Überprüfung der Benutzeridentität — klingt nach einem gelösten Problem. Ein Login-Formular hinzufügen, Passwörter hashen, fertig. Bei einer Consumer-App mag das zutreffen. Bei einem SaaS-Produkt ist es erheblich aufwendiger.

Ein produktionsreifes SaaS-Produkt muss Folgendes unterstützen:

• Benutzername- und Passwort-Authentifizierung mit sicherer Speicherung, Passwort-Reset-Workflows und Schutz vor Brute-Force-Angriffen
• OAuth / Social Login (Google, Microsoft, GitHub) — was Nutzer zunehmend erwarten
• Multi-Faktor-Authentifizierung (MFA) — von jedem Enterprise-Käufer erwartet und von vielen Compliance-Frameworks gefordert
• Single Sign-On (SSO) über SAML 2.0 oder OIDC — von nahezu jedem Enterprise-Kunden ab einer bestimmten Größe gefordert, oft als nicht verhandelbare Beschaffungsanforderung
• Team-Einladungen — ein Nutzer lädt andere in sein Konto ein, mit Rollenzuweisung
• Rollenbasierte Zugriffskontrolle (RBAC) — Administratoren sehen alles, Leser sehen nur, was sie sollen, und alles dazwischen
• Session-Management — Sitzungen angemessen aktiv halten, gleichzeitige Sitzungen verwalten, erzwungener Logout bei Passwortänderung
• Audit-Logging von Authentifizierungsereignissen — wer hat sich wann von wo eingeloggt und was wurde getan

All dies von Grund auf neu zu entwickeln ist kostspielig und birgt reale Sicherheitsrisiken. Jede benutzerdefinierte Auth-Implementierung hat das Potenzial, Schwachstellen einzuführen, die speziell entwickelte Systeme bereits gelöst haben.

Unsere Standardempfehlung ist die Verwendung einer verwalteten Identitätsplattform — Auth0, Clerk oder Supabase Auth sind die drei, die wir am häufigsten einsetzen. Diese Dienste übernehmen die aufwendige Arbeit der Authentifizierungsprotokoll-Compliance, MFA, SSO und Session-Management und bieten SDKs, die sich nahtlos in moderne Anwendungsstacks integrieren. Bei größerem Umfang sind sie nicht kostenlos, aber die Kosten für eine fehlerhafte Auth-Implementierung — in Entwicklungszeit, bei Sicherheitsvorfällen oder durch verlorene Enterprise-Deals, weil SAML SSO nicht unterstützt wird — sind weit höher.

Die wichtigste Architekturfrage, die vor dem Aufbau zu beantworten ist: Wie sieht Ihr Enterprise-Käufer-Profil aus? Wenn Sie planen, an Unternehmen mit einer IT-Abteilung zu verkaufen, ist SSO-Unterstützung keine Option, und Sie benötigen eine Auth-Schicht, die dies unterstützen kann.

---

Abrechnungsarchitektur für Abonnements

Abrechnung ist der zweite Bereich, in dem Gründer die Komplexität dramatisch unterschätzen. Der einfache Fall — Kunde registriert sich, gibt Kartendaten ein, zahlt monatlich — ist unkompliziert. Alles andere ist es nicht.

Im größeren Maßstab muss ein SaaS-Abrechnungssystem Folgendes verarbeiten:

• Kostenlose Testphasen (mit oder ohne Kreditkartenpflicht, Konvertierung von Test zu Bezahlung)
• Mehrere Preismodelle mit unterschiedlichen Funktionen und Limits
• Upgrades und Downgrades, einschließlich anteiliger Gebühren mitten im Abrechnungszeitraum
• Nutzungsbasierte Abrechnung — Gebühren basierend auf dem Verbrauch (API-Aufrufe, Plätze, Speicher, Transaktionen)
• Jährliche vs. monatliche Abrechnung mit entsprechenden Rabatten
• Rechnungsstellung für Kunden, die per Rechnung statt per Karte zahlen
• Handhabung fehlgeschlagener Zahlungen, Mahnprozesse und Nachfristen
• Rückerstattungen und Gutschriften
• Steuerberechnung (insbesondere USt./GST über verschiedene Rechtsgebiete)
• Webhooks von Ihrem Zahlungsanbieter, um den Anwendungsstatus synchron zu halten

Ein Abrechnungssystem zu entwickeln, das all dies korrekt handhabt, ist ein erhebliches Engineering-Projekt. Die Fehlerszenarien sind kostspielig — sowohl finanziell (falsch angewendete Gebühren, fehlgeschlagene Upgrades) als auch hinsichtlich des Kundenvertrauens.

Unsere Standardempfehlung ist Stripe Billing als zentrale Abrechnungsinfrastruktur. Stripe übernimmt die finanzielle Komplexität — Rechnungsstellung, anteilige Berechnung, Mahnwesen, Zahlungsmethoden, Steuern in unterstützten Regionen — und stellt dies über eine gut gestaltete API bereit. Die Aufgabe Ihrer Anwendung besteht dann darin, Plan-Berechtigungen zu verwalten (welche Funktionen ein Kunde mit einem bestimmten Tarif nutzen kann) und auf Stripe-Webhooks zu reagieren, um Ihre Datenbank mit dem Abrechnungsstatus synchron zu halten.

Die Versuchung, das Abrechnungssystem intern zu entwickeln, ist fast immer ein Fehler. Selbst wenn Stripes Preisgestaltung im Verhältnis zu Ihren frühen Umsätzen hoch erscheint, rechtfertigen die eingesparte Entwicklungszeit — und die Korrektheitszusicherungen, die Sie erhalten — diese Entscheidung für nahezu jedes SaaS-Produkt.

---

Datenarchitektur für SaaS

Wir haben oben die Multi-Tenancy-Datenmodelle angesprochen, aber die Datenarchitektur geht über die Frage hinaus, wo Daten gespeichert werden. Im größeren Maßstab bestimmt die Struktur Ihrer Daten, wie schnell Ihr Produkt weiterentwickelt werden kann, wie sicher Sie Änderungen vornehmen können und ob Sie Ihre Verpflichtungen gegenüber Kunden erfüllen können.

Einige Dinge, die von Anfang an bewusst gestaltet werden sollten:

Schema-Migrationen im größeren Maßstab. In einer Einzeldatenbank-Anwendung ist das Ausführen einer Datenbankmigration ein einziger Vorgang. In einer Multi-Schema- oder Multi-Datenbank-Architektur bedeutet dieselbe Migration, sie korrekt auf jede Mandantenumgebung anzuwenden. Ohne eine robuste Migrationsstrategie (und entsprechende Tools) wird dies zu einem Deployment-Engpass, wenn Sie wachsen.

Soft Deletes vs. Hard Deletes. In den meisten SaaS-Anwendungen sollten Daten nie wirklich verschwinden, wenn ein Nutzer etwas „löscht". Soft Deletes (einen Datensatz als gelöscht markieren, ohne ihn zu entfernen) ermöglichen Rückgängig-Funktionen, Audit-Logs und Datenwiederherstellung — und sind von Anfang an weit einfacher zu implementieren als nachträglich einzubauen.

Backups und Disaster Recovery. Was ist Ihr Recovery Time Objective (RTO), wenn die Datenbank ausfällt? Was ist Ihr Recovery Point Objective (RPO) — wie viel Datenverlust können Sie sich leisten? Dies sind Geschäftsentscheidungen mit architektonischen Auswirkungen. Automatisierte tägliche Backups sind ein Mindeststandard; Point-in-Time-Recovery ist das richtige Ziel für jedes Produkt, bei dem Datenverlust ernsthafte Konsequenzen hätte.

Datenexport und -löschung für die DSGVO. Jedes SaaS-Produkt, das an Kunden in Großbritannien oder der EU verkauft, muss die Daten eines bestimmten Kunden in einem maschinenlesbaren Format exportieren und auf Anfrage dauerhaft löschen können. Wenn Ihr Datenmodell nicht von Anfang an darauf ausgelegt wurde, ist die manuelle Erfüllung dieser Anfragen im größeren Maßstab mühsam.

---

API-Design

Ein API-first SaaS-Produkt behandelt seine API als erstklassiges Produkt — nicht als Nachgedanken für Integrationen, sondern als Fundament, auf dem sowohl das Frontend als auch Drittanbieter aufgebaut sind. Das ist wichtig, weil:

• Ihre Kunden Automatisierungen auf der Basis Ihres Produkts aufbauen möchten
• Enterprise-Käufer in Beschaffungsgesprächen nach Ihrer API fragen werden
• Mobile Apps, Browser-Erweiterungen und Partner-Integrationen alle von der API-Qualität abhängen
• Ihre eigenen internen Tools (Dashboards, Admin-Panels), die auf derselben API aufgebaut sind, Konsistenz sicherstellen

Die zwei dominanten API-Paradigmen sind REST und GraphQL. REST ist einfacher, weiter verbreitet und einfacher zu cachen — es ist der richtige Standard für die meisten SaaS-Produkte. GraphQL bietet Vorteile, wenn die Datenanforderungen des Frontends komplex und hochvariabel sind, fügt jedoch operative Komplexität hinzu, die die meisten frühen Produkte nicht benötigen.

API-Versionierung ist eine Architekturentscheidung, die leicht aufgeschoben und schmerzhaft nachträglich hinzugefügt werden kann. Von Anfang an sollte Ihre API versioniert sein (typischerweise /v1/ im URL-Pfad oder über einen Header), sodass Sie bei Breaking Changes dies tun können, ohne alle bestehenden API-Konsumenten zu einer sofortigen Aktualisierung zu zwingen. Die Integration eines Kunden zu unterbrechen, weil Sie das Format einer API-Antwort geändert haben, ist ein ernstes Vertrauensproblem.

---

Skalierbarkeit und Infrastruktur

„Es muss skalierbar sein" ist etwas, das nahezu jeder Gründer in Entdeckungsgesprächen sagt. Was das tatsächlich bedeutet, variiert enorm, und für die falsche Skalierungsebene zu entwerfen, ist ebenso problematisch wie gar nicht für Skalierung zu planen.

Vertikale Skalierung bedeutet, Ihren Servern mehr Ressourcen zu geben — mehr CPU, mehr Arbeitsspeicher, mehr Speicherplatz. Es ist einfach, erfordert keine Code-Änderungen und funktioniert gut bis zu einem gewissen Punkt.

Horizontale Skalierung bedeutet, mehrere Instanzen Ihrer Anwendung gleichzeitig hinter einem Load Balancer zu betreiben. Dies bewältigt erheblich höhere Verkehrsspitzen, setzt jedoch voraus, dass Ihre Anwendung zustandslos ist — das heißt, keine Informationen über eine bestimmte Benutzersitzung werden im Arbeitsspeicher des Anwendungsservers gespeichert. Sitzungsdaten müssen in einem gemeinsam genutzten Speicher (Redis, einer Datenbank) gespeichert sein, auf den alle Instanzen zugreifen können.

Die ehrliche Wahrheit über Skalierbarkeit für die meisten SaaS-Produkte: Sie müssen am ersten Tag nicht für horizontale Skalierung entwerfen. Ein gut strukturierter Monolith, der auf angemessen dimensionierter Cloud-Infrastruktur läuft, kann Zehntausende von Nutzern bedienen, bevor Skalierung zum Engpass wird. Der richtige Ansatz ist, mit Skalierbarkeit im Hinterkopf zu entwickeln — zustandslose Sessions, Datenbankabfragen, die Indizes korrekt verwenden, Hintergrundjobs asynchron verarbeiten — ohne für eine Skalierung überzuentwickeln, die Sie möglicherweise jahrelang nicht erreichen werden.

Was Sie vom ersten Tag an investieren sollten, ist Observability: Anwendungsmonitoring (Fehlerraten, Antwortzeiten, Crash-Reporting), Infrastrukturmonitoring (CPU, Arbeitsspeicher, Datenbankverbindungsanzahl) und Alerting, das jemanden alarmiert, bevor Kunden ein Problem bemerken.

---

Die Architekturentscheidungen vor Tag 1

Bevor Ihr Entwicklungsteam eine einzige Zeile Anwendungscode schreibt, sollten diese Entscheidungen getroffen und dokumentiert sein:

• Multi-Tenancy-Modell — Pool, Bridge oder Silo? (Bestimmt durch Ihren Zielmarkt und Compliance-Anforderungen)
• Auth-Strategie — verwaltete Identitätsplattform (Auth0, Clerk) oder benutzerdefiniert? SSO von Tag eins an erforderlich?
• Abrechnungsinfrastruktur — Stripe Billing als Single Source of Truth, mit Ihrer App für das Entitlement-Management?
• Ziel-Cloud-Anbieter — AWS, GCP oder Azure? Beeinflusst Tooling, Lieferantenbeziehungen und den Talentpool
• Frontend-Framework — Next.js, Nuxt, SvelteKit? Wichtig für die langfristige Teamzusammensetzung
• Primäre Datenbank — PostgreSQL ist der richtige Standard für die meisten SaaS-Produkte; NoSQL hat spezifische Anwendungsfälle
• API-Design-Standard — REST oder GraphQL? Versionierungsstrategie?
• Anforderungen an die Datenresidenz — müssen die Daten bestimmter Kunden innerhalb einer bestimmten geografischen Region verbleiben?
• Deployment-Architektur — Monolith zum Start, mit klaren Grenzen, falls Microservices später benötigt werden

---

Häufige Architekturprobleme bei SaaS-Produkten

Nach der Entwicklung von SaaS-Produkten in den Bereichen Fintech, Gesundheitswesen, Logistik und professionelle Dienstleistungen haben wir ein klares Bild davon, was schiefläuft — und wann.

Verfrühte Microservices. Ein Produkt in Microservices aufzuteilen, bevor die Domänengrenzen klar verstanden sind, schafft enorme operative Komplexität ohne die entsprechenden Vorteile. Beginnen Sie mit einem gut strukturierten Monolith. Extrahieren Sie Dienste, wenn Sie einen klaren Grund haben — eine Teamverantwortungsgrenze, ein deutlich anderes Skalierungsprofil, eine Compliance-Grenze. Nicht vorher.

Kein Audit-Logging. Enterprise-Kunden erwarten zu wissen, wer was wann in Ihrem Produkt getan hat. Regulatoren verlangen es manchmal. Das nachträgliche Einbauen von Audit-Logging in ein Datenmodell, das nicht dafür entwickelt wurde, ist mühsam und oft unvollständig. Bauen Sie es von Anfang an ein.

Fest codierte Mandantenannahmen. Wir sehen häufig Produkte, bei denen tenant_id zu einigen Tabellen, aber nicht zu anderen hinzugefügt wurde, oder bei denen einige Hintergrundjobs Daten global statt pro Mandant verarbeiten. Diese Inkonsistenzen sind Bugs, die darauf warten, aufzutauchen, und sie werden schwieriger zu beheben, je mehr Daten im System vorhanden sind.

Keine Planung für Datenexport (DSGVO und Kundenfluktuation). Kunden gehen. Nach britischem/EU-Recht sind Sie möglicherweise gesetzlich verpflichtet, ihre Daten in einem portablen Format bereitzustellen. Gestalten Sie Ihr Datenmodell und Ihre APIs so, dass dies von Anfang an möglich ist — nicht als Notfallprojekt, wenn das Rechtsteam Ihres ersten Enterprise-Kunden danach fragt.

Falsches Koppeln von Abrechnungs- und Anwendungsstatus. Stripe als Abrechnungs-Single-Source-of-Truth zu verwenden und gleichzeitig den Planstatus in Ihrer eigenen Datenbank zu pflegen ist in Ordnung — solange beide über Webhook-Handling synchron gehalten werden. Wir sehen regelmäßig Produkte, bei denen diese zwei Quellen der Wahrheit still auseinanderlaufen und Kunden Zugang zu Funktionen haben, für die sie nicht bezahlen, oder — schlimmer — von Funktionen ausgesperrt sind, für die sie zahlen.

---

Wie wir SaaS-Architektur bei Cyberbeak gestalten

Unser SaaS-Discovery-Prozess läuft in der Regel zwei bis drei Wochen, bevor die Entwicklung beginnt. In dieser Zeit behandeln wir:

Markt- und Compliance-Mapping. Wer sind die Zielkäufer? In welchen Branchen sind sie tätig? Welche Compliance-Frameworks werden wahrscheinlich in Beschaffungsgesprächen auftauchen? Die Antworten auf diese Fragen bestimmen das Multi-Tenancy-Modell und die Auth-Anforderungen, bevor eine andere Entscheidung getroffen wird.

Datenmodell-Design. Wir gestalten das Kernschema mit Multi-Tenancy, Soft Deletes, Audit-Logging und DSGVO-Export von Anfang an. Dies geschieht in enger Zusammenarbeit mit dem Gründerteam, damit alle die Datenbeziehungen verstehen.

Integrations-Mapping. Womit muss das Produkt sich verbinden? Womit sollen andere Produkte sich mit ihm verbinden? Dies bestimmt die API-Design-Prioritäten und die frühesten Integrationsverpflichtungen.

Infrastruktur-Design. Wir wählen einen Cloud-Anbieter aus, definieren die Umgebungsstruktur (Entwicklung, Staging, Produktion), etablieren eine CI/CD-Pipeline und richten Monitoring und Alerting ein, bevor das erste Anwendungsfeature entwickelt wird.

Unser Standard-Stack für neue SaaS-Produkte in dieser Phase ist Next.js (Frontend), Node.js oder Python auf dem Backend je nach Teamzusammensetzung und Produktanforderungen, PostgreSQL als primäre Datenbank, Stripe Billing für Zahlungen, Auth0 oder Clerk für Identität und AWS für die Infrastruktur. Dies ist keine starre Vorlage — wir passen auf Basis der Anforderungen an — spiegelt aber jahrelange Erfahrung bei der Entwicklung und Wartung von SaaS-Produkten in der Produktion wider.

Das Ziel des Discovery-Prozesses ist nicht, einen perfekten Plan zu erstellen. Es geht darum, die Entscheidungen aufzudecken, die teuer umzukehren sind, sie explizit und bewusst zu treffen und dem Entwicklungsteam ein Fundament zu geben, auf dem es mit Zuversicht aufbauen kann.

---

FAQ

Wie lange dauert die SaaS-Architekturplanung?

Für die meisten frühen SaaS-Produkte dauert eine ordentliche Discovery- und Architekturphase zwei bis drei Wochen. Bei komplexeren Produkten — insbesondere solchen mit Enterprise-Compliance-Anforderungen, komplexen Datenmodellen oder mehreren Integrationsabhängigkeiten — kann es vier bis sechs Wochen dauern. Diese Investition amortisiert sich vielfach, indem sie teure Nacharbeiten in späteren Sprints verhindert.

Können wir mit einer einfacheren Architektur starten und später upgraden?

Einige Entscheidungen können aufgeschoben werden — Sie brauchen keine automatische Skalierung vom ersten Tag an, und viele Integrationen können hinzugefügt werden, wenn das Produkt reift. Aber die grundlegenden Entscheidungen — Multi-Tenancy-Modell, Auth-Strategie, Abrechnungsinfrastruktur — sind sehr kostspielig zu ändern, sobald Kundendaten im System sind. Wir empfehlen immer, diese Entscheidungen bewusst zu Beginn zu treffen, auch wenn die anfängliche Implementierung einfach ist.

Benötigen wir Microservices für ein SaaS-Produkt?

Fast sicher nicht am ersten Tag, und möglicherweise jahrelang nicht. Microservices lösen echte Probleme, bringen aber erhebliche operative Komplexität mit sich. Ein gut strukturierter Monolith ist der richtige Ausgangspunkt für die überwiegende Mehrheit der SaaS-Produkte. Wir entwerfen Monolithen mit klaren internen Grenzen, sodass das spätere Extrahieren von Diensten — falls es wirklich notwendig wird — ein handhabbares Projekt und kein Neuschreiben ist.

Was ist der größte Architekturfehler, den Gründer machen?

Der mit Abstand häufigste und teuerste Fehler ist, Architektur als das Problem des Entwicklungsteams zu behandeln und nicht als gemeinsame Entscheidung. Wenn Gründer nicht an der Architektur-Diskussion beteiligt sind, sind die gewählten Standards oft für die einfachste Interpretation des Produkts geeignet — nicht für das, wohin das Produkt tatsächlich gehen muss. Präsent zu sein, Fragen zu stellen und die wichtigsten Entscheidungen bewusst zu treffen, ist eines der Dinge mit dem höchsten Wirkungsgrad, das ein nicht-technischer Gründer vor Beginn einer Entwicklung tun kann.

---

Wenn Sie gerade dabei sind, ein SaaS-Produkt zu definieren, und sicherstellen möchten, dass die Architekturentscheidungen stimmen, bevor die Entwicklung beginnt, sprechen wir gerne mit Ihnen. Unser Discovery-Prozess ist speziell darauf ausgerichtet, diese Entscheidungen frühzeitig aufzudecken, sie klar zu erläutern und Ihnen ein Fundament zu geben, das nicht neu aufgebaut werden muss, wenn Ihr erster Enterprise-Kunde die richtigen Fragen stellt. Nehmen Sie Kontakt mit dem Cyberbeak-Team auf, um das Gespräch zu beginnen.