Fast jede SaaS-Neuschreibung, zu deren Rettung wir gerufen wurden, führt auf dieselben drei Worte zurück, die das ursprüngliche Team im ersten Monat sagte: «Das machen wir später.» Multi-Tenancy, rollenbasierte Zugriffe, echtes Billing. Sie fühlen sich an wie Dinge, die man anschraubt, sobald man Kunden hat. Sie sind das Gegenteil — sie sind die Form des Gebäudes, und man kann das Fundament nicht ändern, wenn die Wände stehen, ohne es abzureissen.
Wir haben Plattformen gebaut, die heute weltweit auf einer einzigen Codebasis laufen. Der Grund, warum das möglich war, ist langweilig und einstimmig: Tenancy, Zugriff und Billing wurden am ersten Tag entschieden, vor dem ersten Feature. So sehen diese Entscheidungen aus — und das kostet es, sie aufzuschieben.
Warum Teams es überspringen (und warum es eine Falle ist)
Der Druck ist real. Sie haben einen Pilotkunden, nächste Woche eine Demo und ein Backlog voller Features, die tatsächlich nach Produkt aussehen. Multi-Tenancy ist für diesen ersten Kunden unsichtbar — er kann sie nicht sehen, also fühlt sie sich wie Goldrand an. Also baut das Team eine Single-Tenant-App «für jetzt» und verspricht, sie später zu verallgemeinern.
Die Falle: «Single-Tenant für jetzt» lässt eine Annahme in jede Schicht sickern — dass es genau eine Organisation auf der Welt gibt. Diese Annahme landet in Ihren Queries, Ihrer Auth, Ihren Caches, Ihren Hintergrundjobs, Ihren Dateipfaden. Sie später wieder herauszuziehen ist kein Refactoring — es ist eine Neuschreibung, denn die Annahme sitzt nicht an einer Stelle. Sie sitzt an jeder.
Die Kosten-Asymmetrie:
Tenancy am ersten Tag kostet vielleicht zwei Wochen Architektur und Disziplin. Sie im zweiten Jahr nachzurüsten — mit echten Kunden, echten Daten und echten Uptime-Erwartungen — ist eine monatelange Neuschreibung unter Last, mit einer Datenmigration, die nicht schiefgehen darf. Die Arbeit verschwindet durch Aufschieben nicht. Sie verzinst sich.
Der Tenant ist die erste Spalte
Unsere Regel ist simpel: Jede Zeile, die einem Kunden gehört, trägt eine tenant_id, und es gibt keinen Codepfad, der ohne sie abfragen kann. Keine Konvention, an die sich Leute erinnern — eine Einschränkung, die Datenbank und Framework erzwingen, sodass das Vergessen unmöglich ist statt bloss unerwünscht.
Die sauberste Version, die wir verwenden, stützt sich auf die Datenbank selbst. Row-Level-Security-Policies bedeuten: Die Tenant-Grenze wird eine Schicht unterhalb Ihres Anwendungscodes durchgesetzt — dort, wo ein ORM-Bug oder eine vergessene WHERE-Klausel die Daten des einen Kunden nicht mehr an einen anderen leaken kann. Die Anwendung setzt den aktuellen Tenant auf der Verbindung; die Datenbank weigert sich, irgendetwas anderes zurückzugeben.
postgres · row-level security
-- the boundary lives below the app, not inside it ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders USING (tenant_id = current_setting('app.tenant')::uuid);
-- app sets the tenant per request; a forgotten WHERE -- clause now returns zero rows instead of someone else's data SET app.tenant = 'a91f…'; SELECT * FROM orders; -- only this tenant's orders, always
Diese eine Entscheidung entfernt eine ganze Klasse katastrophaler Bugs — das kundenübergreifende Datenleck — dauerhaft von Ihrer Sorgenliste. Es sind die zwei Arbeitstage mit dem grössten Hebel im ganzen Projekt.
Der teuerste Bug im SaaS ist der, der einem Kunden die Daten eines anderen zeigt. Bauen Sie so, dass er nicht passieren kann — nicht so, dass er unwahrscheinlich ist.
— Über Isolation als Einschränkung
RBAC ist keine Einstellungsseite
Das zweite «später», das zur Neuschreibung wird, ist die Zugriffskontrolle. Teams liefern mit einer impliziten Zwei-Rollen-Welt aus — Admin und Nutzer — hartkodiert in if-Anweisungen quer durch die Codebasis. Dann verlangt ein Enterprise-Kunde eine «Nur-Billing»-Rolle oder einen «Read-only-Auditor», und Sie entdecken Berechtigungslogik an zweihundert Stellen.
Wir modellieren Berechtigungen von Anfang an als Daten: Rollen, Berechtigungen und die Zuordnungen dazwischen leben in Tabellen, und jede geschützte Aktion fragt eine zentrale Autorität: «Darf dieser Akteur diese Sache mit dieser Ressource tun, in diesem Tenant?» Eine Rolle hinzuzufügen wird eine Zeile, kein Release. Genau das erlaubt einer Plattform, zum Organigramm des Enterprise-Kunden Ja zu sagen, ohne Anwendungscode anzufassen.
- Berechtigungen sind Verben auf Ressourcen —
invoice:read,invoice:void— keine vagen Stufen wie «Manager». - Rollen sind Bündel von Berechtigungen, die ein Tenant zusammenstellen kann — zwei Kunden dürfen mit «Admin» Verschiedenes meinen.
- Jede Prüfung läuft durch ein Tor. Autorisierungslogik an einem Ort ist auditierbar; verstreute
if-Anweisungen sind eine Haftung.
Billing ist Produkt, nicht Rohrleitung
Beim Billing tut «machen wir später» am meisten weh — denn wenn Sie es nachrüsten, haben Sie Kunden auf Handschlag-Deals, inkonsistente Daten darüber, wer was schuldet, und kein sauberes Konzept eines Abos. Billing nachzurüsten heisst Geld abzustimmen — und das ist der eine Ort, an dem ein Bug nicht bloss peinlich ist, sondern eine Rückerstattung, ein Disput oder ein Compliance-Problem.
Wir entwerfen das Billing-Modell neben dem Tenant-Modell: Pläne, Abos, Verbrauch, Rechnungen und der Lebenszyklus dazwischen. Auch wenn die ersten Kunden von Hand fakturiert werden — das Datenmodell ist ab Tag eins da. Self-Service-Pläne später einzuschalten ist dann ein Feature, keine Migration Ihrer gesamten Umsatzhistorie.
Länder live —
Eine Codebasis, ein Deployment-Modell, viele Tenants.
Codebasis —
Kein Kunden-Fork, den man pflegen oder auseinanderdriften lassen müsste.
Kundenübergreifende Leaks —
Isolation in der Datenbank erzwungen, nicht per Konvention.
Viele Länder, eine Codebasis
Viele Länder zu erreichen klingt nach einer Skalierungsgeschichte. In Wahrheit ist es eine Konfigurationsgeschichte. Die Plattform hat keine länderspezifischen Code-Zweige — sie hat ein Tenant-Modell, das reich genug ist, um das, was sich pro Region unterscheidet, als Daten auszudrücken: Währung, Steuerregeln, Sprache, Datumsformate, der Rechtstext auf einer Rechnung.
Wird die Grenze zwischen «Code» und «Konfiguration» am ersten Tag richtig gezogen, ist ein neues Land eine Onboarding-Aufgabe, kein Engineering-Projekt. Wird sie falsch gezogen, ist jeder neue Markt ein Fork — und binnen eines Jahres pflegen Sie ein Dutzend subtil verschiedener Versionen derselben App und liefern jeden Fix zwölfmal aus. Das Ein-Codebasis-Ergebnis ist die Folge von Entscheidungen vor dem ersten Kunden.
Der echte Gewinn:
Der Nutzen, das am ersten Tag zu tun, zeigt sich nicht im ersten Monat — er zeigt sich im dritten Jahr, wenn Sie ein Feature einmal ausliefern und jeder Markt es gleichzeitig bekommt, während Ihr Single-Tenant-Wettbewerber es noch in seinen siebten Kunden-Fork merged.
Die Tag-eins-Checkliste
Wenn Sie dieses Quartal eine SaaS-Plattform starten: Das sind die Entscheidungen, die vor dem ersten Feature zu treffen sind — nicht weil sie dringend wären, sondern weil sie unumkehrbar sind:
tenant_idauf alles, durchgesetzt unterhalb der App. Row-Level Security oder Äquivalent. Machen Sie eine kundenübergreifende Query unmöglich, nicht unwahrscheinlich.- Berechtigungen als Daten modellieren. Rollen und Zuordnungen in Tabellen, ein zentrales Autorisierungstor. Eine neue Rolle sollte eine Zeile sein.
- Das Billing-Datenmodell früh bauen. Pläne, Abos, Rechnungen — auch wenn Sie anfangs von Hand fakturieren. Rüsten Sie Geld nicht nach.
- Code von Konfiguration trennen. Alles, was pro Kunde oder Region variiert, ist Daten. Das nächste Land sollte ein Onboarding-Formular sein.
- Den Tenant-Provisionierungspfad zuerst schreiben. Einen neuen Tenant sauber anzulegen, mit vernünftigen Defaults, ist Ihre häufigste Operation. Automatisieren Sie sie am ersten Tag.
Nichts davon ist exotisch. Es sind ein paar Wochen Disziplin am Anfang im Tausch dafür, die Neuschreibung nie zu machen. Die Teams, die viele Länder auf einer Codebasis erreichen, hatten kein Glück — sie haben sich nur geweigert, bei den drei Dingen «später» zu sagen, die sich nicht später hinzufügen lassen.
Diese drei "kann man später nicht nachrüsten"-Entscheidungen sind die erste Woche jeder SaaS-Plattform, die wir bauen — darunter eine, die heute Kunden in mehreren Ländern aus einer Codebasis bedient. Planen Sie Ihre? Reden wir, bevor das Schema existiert.
