Mandantenfähig ab dem ersten Tag

Fast jede SaaS-Neuentwicklung, zu deren Rettung wir gerufen wurden, lässt sich auf dieselben drei Worte zurückführen, die das ursprüngliche Team im ersten Monat gesagt hat: «Das bauen wir später ein.» Mandantenfähigkeit, rollenbasierter Zugriff, echte Abrechnung. Sie wirken wie Dinge, die man nachrüstet, sobald man Kunden hat. Sie sind das Gegenteil — sie sind die Form des Gebäudes, und das Fundament lässt sich nicht ändern, wenn die Mauern erst einmal stehen, ohne alles abzureissen.

Wir haben Plattformen gebaut, die heute in mehr als 40 Ländern auf einer einzigen Codebasis laufen. Der Grund, warum das möglich war, ist langweilig und einhellig: Mandantenmodell, Zugriff und Abrechnung wurden am ersten Tag entschieden, vor dem ersten Feature. So sehen diese Entscheidungen aus — und das kostet es, wenn man sie aufschiebt.

01Warum Teams es überspringen (und warum das eine Falle ist)

Der Druck ist real. Sie haben einen Pilotkunden, nächste Woche eine Demo und einen Backlog voller Features, die tatsächlich nach dem Produkt aussehen. Mandantenfähigkeit ist für diesen ersten Kunden unsichtbar — er sieht sie nicht, also wirkt sie wie überflüssiger Luxus. Also baut das Team eine «vorläufig» mandantenlose App und verspricht, sie später zu verallgemeinern.

Die Falle ist, dass «vorläufig ein Mandant» eine einzige Annahme in jede Schicht sickern lässt: dass es genau eine Organisation auf der Welt gibt. Diese Annahme landet am Ende in Ihren Abfragen, Ihrer Authentifizierung, Ihren Caches, Ihren Hintergrundjobs, Ihren Dateipfaden. Sie später wieder herauszuziehen ist kein Refactoring — es ist eine Neuentwicklung, denn die Annahme steckt nicht an einer Stelle, sondern an jeder Stelle.

02Der Mandant ist die erste Spalte

Unsere Regel ist einfach: jede Zeile, die zu einem Kunden gehört, trägt eine tenant_id, und es gibt keinen Code-Pfad, der ohne sie abfragen kann. Keine Konvention, an die sich Leute erinnern — eine Einschränkung, die die Datenbank und das Framework erzwingen, sodass das Vergessen unmöglich statt bloss unerwünscht ist.

Die sauberste Variante, die wir verwenden, stützt sich auf die Datenbank selbst. Row-Level-Security-Policies bedeuten, dass die Mandantengrenze eine Schicht unterhalb Ihres Anwendungscodes erzwungen wird, dort, wo ein ORM-Bug oder eine vergessene WHERE-Klausel die Daten des einen Kunden nicht an einen anderen weitergeben kann. Die Anwendung setzt den aktuellen Mandanten auf der Verbindung; die Datenbank weigert sich, irgendetwas anderes zurückzugeben.

-- 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 mandantenübergreifende Datenleck — dauerhaft von Ihrer Sorgenliste. Es sind die zwei Tage Arbeit mit dem höchsten Hebel im ganzen Projekt.

03RBAC ist keine Einstellungsseite

Das zweite «später», das zur Neuentwicklung wird, ist die Zugriffskontrolle. Teams gehen mit einer impliziten Zwei-Rollen-Welt live — Admin und Benutzer — fest verdrahtet in if-Anweisungen, verstreut über die ganze Codebasis. Dann fragt ein Enterprise-Kunde nach einer reinen «Abrechnungs»-Rolle oder einem «schreibgeschützten Auditor», und Sie entdecken Berechtigungslogik an zweihundert Stellen.

Wir modellieren Berechtigungen von Anfang an als Daten: Rollen, Berechtigungen und die Zuweisungen dazwischen liegen in Tabellen, und jede geschützte Aktion fragt eine zentrale Instanz «darf dieser Akteur dies mit dieser Ressource tun, in diesem Mandanten?» Eine Rolle hinzuzufügen wird zu einer Zeile, nicht zu einem Release. Genau das erlaubt es 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 Mandant zusammenstellen kann, sodass zwei Kunden mit «Admin» Unterschiedliches meinen können.
• Jede Prüfung läuft durch ein Gate. Autorisierungslogik an einer Stelle ist auditierbar; verstreute if-Anweisungen sind ein Risiko.

04Abrechnung ist Produkt, nicht Installation

Abrechnung ist der Ort, an dem «das bauen wir später ein» am meisten weh tut, denn bis Sie sie einbauen, haben Sie Kunden mit Handschlag-Deals, inkonsistente Daten darüber, wer wem was schuldet, und kein sauberes Konzept eines Abonnements. Abrechnung nachzurüsten bedeutet, Geld abzustimmen — und das ist der eine Ort, an dem ein Bug nicht nur peinlich ist, sondern eine Rückerstattung, ein Streitfall oder ein Compliance-Problem.

Wir entwerfen das Abrechnungsmodell zusammen mit dem Mandantenmodell: Tarife, Abonnements, Nutzung, Rechnungen und den Lebenszyklus dazwischen. Selbst wenn die ersten Kunden manuell in Rechnung gestellt werden, ist das Datenmodell ab dem ersten Tag da, sodass das spätere Aktivieren von Self-Service-Tarifen ein Feature ist und keine Migration Ihrer gesamten Umsatzhistorie.

05Vierzig Länder, eine Codebasis

40+ 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 Mandantenmodell, das reich genug ist, um das, was sich pro Region unterscheidet, als Daten auszudrücken: Währung, Steuerregeln, Sprache, Datumsformate, der rechtliche Text auf einer Rechnung.

Wenn die Grenze zwischen «Code» und «Konfiguration» am ersten Tag richtig gezogen wird, ist ein neues Land eine Onboarding-Aufgabe, kein Engineering-Projekt. Wenn sie falsch gezogen wird, ist jeder neue Markt ein Fork, und innerhalb eines Jahres pflegen Sie ein Dutzend subtil unterschiedlicher Versionen derselben App und liefern jeden Fix ein Dutzend Mal aus. Das Ergebnis einer einzigen Codebasis ist die Folge von Entscheidungen, die vor dem ersten Kunden getroffen wurden.

06Die Checkliste für den ersten Tag

Wenn Sie in diesem Quartal eine SaaS-Plattform starten, sind dies die Entscheidungen, die Sie treffen sollten, bevor Sie ein Feature schreiben — nicht weil sie dringend sind, sondern weil sie unumkehrbar sind:

1. Setzen Sie tenant_id auf alles und erzwingen Sie es unterhalb der App. Row-Level-Security oder Äquivalent. Machen Sie eine mandantenübergreifende Abfrage unmöglich, nicht unwahrscheinlich.
2. Modellieren Sie Berechtigungen als Daten. Rollen und Zuweisungen in Tabellen, ein zentrales Autorisierungs-Gate. Eine Rolle hinzuzufügen sollte eine Zeile sein.
3. Bauen Sie das Abrechnungs-Datenmodell früh. Tarife, Abonnements, Rechnungen — auch wenn Sie zunächst von Hand abrechnen. Rüsten Sie Geld nicht nach.
4. Trennen Sie Code von Konfiguration. Alles, was sich je nach Kunde oder Region unterscheidet, sind Daten. Land Nummer 41 sollte ein Onboarding-Formular sein.
5. Schreiben Sie den Mandanten-Provisionierungspfad zuerst. Einen neuen Mandanten sauber und mit sinnvollen Voreinstellungen anzulegen, ist Ihre am häufigsten ausgeführte Operation. Automatisieren Sie sie am ersten Tag.

Nichts davon ist exotisch. Es sind ein paar Wochen Disziplin am Anfang im Tausch dafür, die Neuentwicklung nie machen zu müssen. Die Teams, die mit einer Codebasis 40 Länder 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.