SaaS-Entwicklung

Bei einem SaaS-Produkt entscheiden zwei Weichenstellungen über die nächsten Jahre, und beide werden ganz am Anfang gestellt: Wie werden Kundendaten voneinander getrennt, und wie kommt die Abrechnung an die Nutzung heran.

Wer das zu spät klärt, merkt es an einem bestimmten Punkt sehr deutlich. Meistens dann, wenn der erste größere Kunde eigene Anforderungen an Datenhaltung oder Zugriffsrechte stellt.

Die Mandantentrennung legt man einmal fest

Für die Trennung der Kundendaten gibt es zwei gängige Wege. Entweder teilen sich alle Mandanten eine Datenbank und jede Tabelle trägt eine Spalte mit der Mandanten-Kennung. Oder jeder Mandant bekommt ein eigenes Schema. Der erste Weg ist im Betrieb günstiger und bei Migrationen deutlich einfacher zu handhaben. Der zweite macht es leichter, einen einzelnen Kunden zu sichern, zu exportieren oder auf Verlangen vollständig zu löschen.

Für die meisten Produkte fällt die Wahl auf die geteilte Datenbank. Damit dabei niemand die Daten eines anderen Kunden zu sehen bekommt, läuft die Prüfung auf den richtigen Mandanten bei jedem Zugriff automatisch mit (globale Query-Scopes). Ein Entwickler kann sie also nicht vergessen, solange er über den üblichen Weg auf die Daten zugreift. Kommen später Kunden aus stark regulierten Branchen dazu, kann ein eigenes Schema pro Kunde trotzdem die bessere Wahl sein. Ein Wechsel im laufenden Betrieb ist teuer, deshalb gehört diese Frage in die erste Woche und nicht in das zweite Jahr.

Die Abrechnung braucht eine belastbare Datenquelle

Ein Tarifmodell ist schnell ausgedacht. Schwierig wird es dort, wo ein Preis auf eine gemessene Größe trifft. Wenn Sie nach aktiven Nutzern abrechnen, muss definiert sein, was aktiv bedeutet und zu welchem Stichtag gezählt wird. Für Tarifwechsel mitten im Abrechnungszeitraum brauchen Sie eine Regel zur anteiligen Berechnung. Die Abo-Verwaltung binde ich in der Regel an einen Zahlungsdienstleister an, weil Steuerberechnung und Rechnungsversand dort bereits abgebildet sind. Bei Ihnen bleibt die Zuordnung: Welcher Zustand im Zahlungsdienst führt zu welchem Zugriffsrecht in der Anwendung. Diese Abbildung sichere ich mit Tests ab. Ein Fehler an dieser Stelle kostet Sie entweder Umsatz oder sperrt einem zahlenden Kunden den Zugang.

Rollen und Rechte wachsen schneller als geplant

Zu Beginn reichen zwei Rollen. Nach einem Jahr wollen Kunden einen Nutzer anlegen, der nur lesen darf, und einen Abrechnungskontakt, der die Fachdaten nicht sieht. Wenn Berechtigungen verstreut im Code liegen, wird jede dieser Anfragen zur Suchaktion durch das ganze Projekt. Ich lege Rechte deshalb von Anfang an als eigene Ebene an, auf der jede Berechtigung an genau einer Stelle definiert ist (üblicherweise über Laravels Policies mit einer Rechtetabelle dahinter). Der Mehraufwand am Anfang liegt meist im Bereich weniger Tage.

Betrieb, der auch bei „Kunde zweihundert“ noch trägt

Alles, was länger als eine Sekunde dauert, wandert in eine Warteschlange. Berichte, Exporte, E-Mail-Versand, die Verarbeitung eingehender Webhooks. Das hält die Oberfläche schnell und macht die Last planbar, weil sich Worker unabhängig von den Webservern hochfahren lassen. Für den Betrieb liefere ich Container-Images, deren Konfiguration sich zwischen Testumgebung und Produktion nur über Umgebungsvariablen unterscheidet. Zur Überwachung gehören Fehlerprotokollierung und einige wenige Kennzahlen, die man auch wirklich ansieht: fehlgeschlagene Jobs, Antwortzeiten der langsamsten Endpunkte, Fehlerquote bei Zahlungen.

Eine Verwaltungsoberfläche für Ihren eigenen Alltag

Jedes SaaS-Produkt braucht eine interne Ansicht. Wer Kundenkonten nur über direkten Datenbankzugriff verwalten kann, bindet dauerhaft Entwicklerzeit für Aufgaben, die der Support selbst erledigen könnte. Ich baue deshalb früh eine schlichte Verwaltung: Konten suchen, Tarif ändern, Zugang sperren, sich zu Supportzwecken auf ein Konto aufschalten. Das ist unspektakuläre Arbeit und spart im Alltag mehr Zeit als die meisten Funktionen, die auf der Wunschliste weiter oben stehen.