Multi-Tenant-SaaS bauen: Was wir bei TrainerFoundry gelernt haben

Wer eine SaaS-Plattform bauen lässt, will wissen, ob sein Dienstleister die Entscheidungen auch selbst tragen würde. Bei TrainerFoundry, der Software für Personal Trainer, tun wir genau das: Wir entwickeln und betreiben das Produkt selbst — für Trainer, die einen erstaunlichen Teil ihrer Woche mit Verwaltung statt Training verbringen. Technisch ist TrainerFoundry eine Multi-Tenant-SaaS, in der jeder Trainer sein Geschäft in einem eigenen, abgeschotteten Mandanten führt. Dieser Beitrag zeigt, welche Architekturentscheidungen wir getroffen haben und welche Lehren daraus auch für Ihr eigenes SaaS-Vorhaben gelten.

Das Problem: vier Werkzeuge für einen Beruf

Ein selbstständiger Personal Trainer braucht eine Klientenverwaltung, einen Kalender, einen Weg, bezahlt zu werden, und einen stetigen Strom neuer Interessenten — in der Praxis oft vier Werkzeuge plus Tabellen und Zettel. TrainerFoundry bündelt Terminplanung, Zahlungen, Klienten-CRM, eine Lead-Pipeline und eine Frühwarnung, wenn Klienten abzuspringen drohen, in einer Plattform. Der Trainer arbeitet in einer eigenen Oberfläche, seine Klienten in einer zweiten, mobil ausgerichteten App. Für den Trainer heißt das weniger Verwaltung: Seine Klienten buchen selbst, erhalten für jede Kartenzahlung automatisch eine Rechnung in seinem Namen, und TrainerFoundry nimmt auf ihre Zahlungen keine Provision.

Der Stack im Überblick

• Backend: .NET 10 und EF Core 10 auf Azure SQL, eine Anwendung auf Azure Container Apps.
• Frontends: zwei Progressive Web Apps mit React 19, dazu eine Website mit Astro 5.
• Identität: Azure Entra External ID.
• Zahlungen: Stripe für unsere eigene Abrechnung, Stripe Connect für die Zahlungen der Klienten an ihren Trainer.
• Hosting: Microsoft Azure, Rechenzentrumsregion Germany West Central (Frankfurt).

Lehre 1: Ein modularer Monolith trägt weiter, als man denkt

TrainerFoundry besteht aus acht fachlichen Modulen, die gemeinsam in einem Prozess laufen und eine Datenbank teilen. Die Modulgrenzen sichert der Compiler über Projektreferenzen ab, nicht das Netzwerk: Ein Modul kann den Code eines anderen nur über definierte Schnittstellen und Benachrichtigungen erreichen.

Microservices hätten den Betriebsaufwand vervielfacht, ohne dass es einen Treiber dafür gab: ein Team, ein Kundenprofil, eine Laufzeitumgebung. Die grundsätzliche Abwägung beschreiben wir in Modularer Monolith vs. Microservices; die Disziplin sitzt in den Modulgrenzen, nicht in der Deployment-Topologie.

Lehre 2: Mandantenfähigkeit gehört in die Infrastruktur

In TrainerFoundry ist jede Organisation ein Mandant. Die naheliegende und gefährliche Lösung wäre, in jeder einzelnen Abfrage an den Filter auf die Organisation zu denken. Wir haben das umgedreht: Ein globaler Abfragefilter in der gemeinsamen Basisklasse des Datenzugriffs beschränkt jede mandantenbezogene Tabelle automatisch auf die Organisation des angemeldeten Nutzers, und beim Speichern wird sie ebenfalls automatisch gesetzt. Wer ein neues Feature baut, muss die Trennung nicht aktiv herstellen — er müsste sie aktiv umgehen. Genau so herum sollte eine Sicherheitsgrenze funktionieren.

Lehre 3: Zwei Geldflüsse, die gleich klingen

TrainerFoundry hat zwei vollständig getrennte Zahlungssysteme. Im ersten bezahlt der Trainer uns für sein Abonnement — über unser eigenes Stripe-Konto und mit unserer Steuerregistrierung. Im zweiten bezahlen seine Klienten ihn für Sitzungen und Pakete — über sein eigenes Stripe-Connect-Konto, mit seiner Steuerregistrierung und mit Rechnungen in seinem Namen.

Beide Systeme haben Abonnements, Rechnungen, Steuern und eine Währung. Genau das macht sie gefährlich: Die Begriffe sind identisch, die Eigentümer nicht. Eine Frage zur Steuer auf das Trainer-Abonnement lässt sich mühelos — und völlig plausibel klingend — mit Wissen über die Rechnungen des Trainers an seine Klienten beantworten. Deshalb gilt bei uns eine einfache Regel: Jedes Ticket, jeder Code-Kommentar und jeder Kundentext zu Geld, Steuern oder Rechnungen nennt ausdrücklich, welcher der beiden Flüsse gemeint ist. Getrennte Webhooks und Code-Bereiche erzwingen die Trennung auch technisch.

Lehre 4: Zwei Zielgruppen, dieselben Wörter

Dasselbe Muster wiederholt sich bei den Menschen. Jede Oberfläche, jede E-Mail und jeder Rechtstext richtet sich entweder an den Trainer, unseren Kunden, oder an dessen Klienten — mit unterschiedlichem Absender, unterschiedlichen Rechten und oft unterschiedlicher Sprache. Weil beide Seiten dieselben Begriffe kennen, kann Code samt seinen Tests korrekt aussehen und trotzdem die falsche Person adressieren. Deshalb beantworten wir die Frage für wen ist das? bei jeder Änderung ausdrücklich, bevor gebaut wird.

Lehre 5: Vier Länder sind mehr als eine Übersetzung

TrainerFoundry startet in Deutschland, Österreich, der Schweiz und Australien — in Euro, Franken und australischen Dollar. Die Rechnungen der Trainer an ihre Klienten müssen deshalb vier Steuersysteme abbilden, jeweils unter der Steuerregistrierung des einzelnen Trainers. Unsere eigenen Abo-Rechnungen an die Trainer laufen dagegen unter einer einzigen Steuerregistrierung: unserer in Deutschland. Drei Entscheidungen haben sich bewährt:

1. Die Steuer auf jeder Rechnung berechnet Stripe Tax — in beiden Geldflüssen. Ob Rechnung des Trainers an seinen Klienten oder unsere Abo-Rechnung an den Trainer: Der Steuerbetrag kommt von Stripe.
2. Die Region ist eine Tatsache, keine Vorliebe. Die Sprache wählt der Nutzer, die Region folgt aus dem Land. Ein Schweizer Trainer, der Englisch bevorzugt, bekommt englische Texte mit Schweizer Formaten.
3. Dokumente merken sich ihre Sprache. Rechnungen des Trainers an seine Klienten halten die Sprache fest, in der sie ausgestellt wurden; ein späterer Sprachwechsel schreibt keine alte Rechnung um.

Was das für Ihr SaaS-Vorhaben bedeutet

Ob Sie überhaupt selbst bauen sollten, klärt unsere Entscheidungshilfe zu Make or Buy. Fällt die Wahl auf eine eigene SaaS, sollten vor der ersten Zeile Code fünf Fragen beantwortet sein:

1. Wer ist der Mandant? Organisation, Team oder einzelner Nutzer?
2. Wo wird die Trennung durchgesetzt? In jeder Abfrage oder in der Infrastruktur?
3. Wie viele Geldflüsse gibt es? Und wer ist in jedem davon Merchant of Record?
4. Welche Zielgruppe bekommt welche Texte? Mit eindeutigem Absender und Empfänger.
5. Welche Länder und Währungen gehören zum Start? Daran hängen Steuern und Formate.

Auf diese fünf Fragen kommt es an — unabhängig von Branche und Stack.

Fazit: Wo Multi-Tenant-SaaS wirklich schiefgeht

Keine dieser Lehren aus TrainerFoundry ist spektakulär, und genau das ist der Punkt. Die teuren Fehler in einer Multi-Tenant-SaaS entstehen selten bei der Wahl des Frameworks, sondern dort, wo zwei Dinge gleich heißen und verschieden sind: zwei Mandanten, zwei Geldflüsse, zwei Zielgruppen, zwei Sprachen. Eine Architektur, die diese Unterschiede ausdrücklich macht — im Code, in den Tests und in der Sprache des Teams —, trägt weiter als jede Technologiewahl.

---

Tech42 baut SaaS-Plattformen für den Mittelstand — von der Software-Architektur über Mandantenfähigkeit und Zahlungsintegration bis zum Betrieb auf Azure. Wenn Sie ein eigenes Produkt planen, ist unsere individuelle Softwareentwicklung der passende Einstieg. Welche dieser Lehren auf Ihr Vorhaben zutreffen, klären wir im kostenlosen Erstgespräch — unverbindlich und auf Ihr Produkt bezogen.