SaaS-Entwicklung: Was wirklich dazugehört

Die häufigste Fehleinschätzung bei SaaS-Projekten klingt harmlos: „Wir brauchen im Grunde nur eine Webanwendung mit Login." Aus dieser Annahme entstehen Angebote, die um den Faktor drei danebenliegen, und Produkte, die beim zwölften Kunden auseinanderfallen.

Der Unterschied zwischen einer Webanwendung und einem SaaS-Produkt liegt nicht in der Oberfläche. Er liegt darunter: in der Frage, wie viele voneinander getrennte Organisationen dieselbe Instanz benutzen, wer was sehen darf, wie abgerechnet wird und was passiert, wenn ein Kunde seine Daten zurückhaben will.

Dieser Beitrag geht durch die Bausteine, die jedes ernsthafte SaaS-Produkt braucht. Nicht als Featureliste, sondern mit dem Blick darauf, welche Entscheidungen früh fallen müssen, weil sie sich später nur noch teuer korrigieren lassen.

Mandantenfähigkeit ist eine Architekturentscheidung, keine Funktion

Mandantenfähigkeit bedeutet, dass mehrere Organisationen – Kitas, Pflegedienste, Handwerksbetriebe – dieselbe Anwendung nutzen, ohne je Daten der anderen zu sehen. Das klingt nach einer Spalte organisation_id in jeder Tabelle. In der Praxis ist es die Entscheidung, die am tiefsten in alles hineinreicht.

Es gibt im Wesentlichen drei Wege.

Eine Datenbank, eine Spalte pro Zeile. Alle Mandanten teilen sich dieselben Tabellen, jede Zeile trägt die Kennung ihrer Organisation. Das ist der übliche Weg, er ist am günstigsten im Betrieb und am einfachsten zu aktualisieren: ein Schema, eine Migration, fertig. Der Preis ist Disziplin. Jede einzelne Abfrage muss den Mandanten berücksichtigen. Ein vergessenes WHERE in einem Report, und ein Kunde sieht die Zahlen eines anderen.

Ein Schema pro Mandant. Die Daten liegen in derselben Datenbank, aber in getrennten Namensräumen. Die Trennung ist strukturell statt durch Sorgfalt erzwungen. Dafür wird jede Schemaänderung zu einem Vorgang, der über alle Mandanten laufen muss – bei dreißig Kunden noch angenehm, bei dreihundert ein eigenes Werkzeug.

Eine Datenbank pro Mandant. Maximale Trennung, häufig gefordert, wenn besonders schützenswerte Daten im Spiel sind oder ein Kunde eigene Backups will. Dafür vervielfacht sich der Betriebsaufwand, und Auswertungen über alle Mandanten hinweg werden zur Fleißarbeit.

Für die allermeisten Produkte im Mittelstand ist der erste Weg richtig. Entscheidend ist dann aber, die Trennung nicht der Aufmerksamkeit der Entwickler zu überlassen, sondern sie so tief wie möglich zu verankern: in Datenbankregeln, die den Mandanten erzwingen, und in einer Datenzugriffsschicht, durch die jede Abfrage muss. Wer die Prüfung in die Oberfläche legt, hat sie nicht.

Eine Sache noch, die gern übersehen wird: Nutzer gehören nicht zwingend zu genau einer Organisation. Eine Betreuungskraft arbeitet für zwei Dienste, eine Erzieherin wechselt die Einrichtung, ein Steuerberater betreut zwölf Mandanten. Wenn die Beziehung zwischen Nutzer und Organisation eine einfache Spalte im Nutzerdatensatz ist, wird der erste solche Fall zu einem Umbau. Als eigene Verknüpfungstabelle gedacht, ist es von Anfang an ein gelöstes Problem.

Rollen und Rechte: früh anfangen, klein anfangen

Der zweite Baustein, der gern unterschätzt wird. Fast jedes Produkt startet mit zwei Rollen – Verwaltung und normale Nutzer – und hat nach einem Jahr sieben. Ein Beispiel aus einer Software für Betreuungsdienste: Inhaberin, Einsatzleitung, Abrechnung, Betreuungskraft, Auszubildende mit eingeschränkter Dokumentationspflicht, externe Buchhaltung mit Lesezugriff auf Rechnungen. Jede dieser Rollen entstand aus einem konkreten Wunsch, keine war zu Beginn absehbar.

Was daraus folgt, ist nicht, zu Beginn alle Rollen zu erfinden. Es folgt, die Rechteprüfung an einer Stelle zu haben. Wenn im Code an vierzig Stellen if (nutzer.rolle === "admin") steht, kostet jede neue Rolle eine Woche und bringt drei Sicherheitslücken mit. Wenn stattdessen überall darf(nutzer, "rechnung.sehen") steht, ist eine neue Rolle eine Zeile in einer Zuordnungstabelle.

Der Aufwand für diese Abstraktion ist am Anfang ein bis zwei Tage. Sie nachträglich einzuziehen, wenn die Anwendung steht, kostet Wochen.

Authentifizierung: nicht selbst bauen, aber verstehen

Anmeldung, Passwort-Zurücksetzen, E-Mail-Bestätigung, Sitzungsverwaltung, Zwei-Faktor-Authentifizierung, Einladungen für neue Teammitglieder: Das ist kein Nachmittag Arbeit, sondern mehrere Wochen, wenn man es sauber macht. Und „sauber" heißt hier auch: sicher gegen Angriffe, die man nicht selbst erfindet.

Deshalb ist eine fertige Lösung fast immer richtig – eine Bibliothek, ein selbst betreibbarer Dienst oder ein Anbieter. Was man dabei nicht auslagern kann, ist das Verständnis. Drei Fragen sollte man vor der Entscheidung beantworten können:

• Wo liegen die Nutzerdaten? Bei einem Anbieter außerhalb der EU wird der Auftragsverarbeitungsvertrag zum Thema, und bei Gesundheits- oder Kinderdaten wird es schnell heikel.
• Was passiert beim Wechsel? Passwörter sind gehasht, die Hashes lassen sich meist migrieren – aber nicht bei jedem Anbieter. Wer das nicht prüft, sitzt fest.
• Wie verträgt sich das mit der Mandantenfähigkeit? Der Nutzer meldet sich einmal an, gehört aber möglicherweise zu mehreren Organisationen. Ein Anbieter, der das nicht kennt, erzeugt Reibung an genau der Stelle, die täglich benutzt wird.

Für Produkte, die beim Kunden laufen sollen – wie wir es handhaben – kommen zusätzlich selbst betreibbare Lösungen ins Spiel. Das schränkt die Auswahl ein, macht den Kunden aber unabhängig von einem Anbieter, den er nicht selbst gewählt hat.

Abrechnung ist selten „einfach Stripe anbinden"

Für ein klassisches Abo mit drei Tarifen ist die Anbindung eines Zahlungsanbieters tatsächlich überschaubar: ein paar Tage Arbeit. Der Aufwand entsteht nicht an der Zahlung, sondern an allem drumherum.

Was gehört wirklich dazu:

• Tarifwechsel während der Laufzeit, mit anteiliger Berechnung in beide Richtungen
• Probezeiträume und was passiert, wenn sie ablaufen, ohne dass jemand zahlt
• Fehlgeschlagene Zahlungen: Wie oft wird es erneut versucht, ab wann wird der Zugang eingeschränkt, was bleibt trotzdem lesbar
• Rechnungen mit fortlaufender Nummer, Umsatzsteuer, Reverse Charge bei EU-Kunden
• Kündigung zum Laufzeitende, mit Zugriff bis zum letzten Tag
• Preisänderungen, ohne Bestandskunden aus dem alten Tarif zu werfen

Und dann gibt es die Fälle, in denen „Abrechnung" etwas völlig anderes bedeutet. In der Pflege wird nicht das Produkt abgerechnet, sondern Leistungen gegenüber Kostenträgern – nach gesetzlichen Vorgaben, mit definierten Formaten und Fristen. Das ist keine Anbindung, das ist ein Fachmodul, und es ist oft der aufwendigste Teil des ganzen Projekts. Wer solche Anforderungen im Angebot unter „Abrechnung" zusammenfasst, hat sich verrechnet.

Das Datenmodell entscheidet über die nächsten zwei Jahre

Von allen frühen Entscheidungen ist das Datenmodell die, die man am schwersten zurücknimmt. Code lässt sich umschreiben. Daten, die seit achtzehn Monaten in einer bestimmten Struktur liegen, umzuziehen, ist ein Projekt für sich – mit Ausfallzeit, mit Migrationsskripten, mit dem Risiko, etwas zu verlieren.

Drei Muster, die sich in der Praxis bewährt haben:

Ereignisse statt Zustände speichern, wo es auf Historie ankommt. Ein Feld status auf einem Datensatz sagt, wie es jetzt ist. Es sagt nicht, wann es sich geändert hat und wer es geändert hat. Sobald jemand fragt „seit wann ist das so?" – und jemand fragt das immer – braucht man die Ereignisse. Sie nachträglich zu rekonstruieren, geht nicht.

Nie hart löschen, was jemand versehentlich löschen könnte. Ein Löschzeitpunkt statt eines gelöschten Datensatzes rettet regelmäßig Kundenbeziehungen. Wichtig ist dann allerdings, dass die DSGVO-konforme echte Löschung trotzdem möglich bleibt – das sind zwei verschiedene Vorgänge, die man auseinanderhalten muss.

Fachliche Nummern von technischen Schlüsseln trennen. Die Rechnungsnummer ist nicht die Datenbank-ID. Die Kundennummer auch nicht. Wer das vermischt, kann später keine Nummernkreise ändern, keine Daten aus einem Altsystem übernehmen und keine zwei Systeme zusammenführen.

Was wir in der Praxis beobachten

Bei kitos, unserer Kita-App, war die Mandantenfähigkeit von Anfang an gesetzt – jede Einrichtung sieht ausschließlich ihre eigenen Gruppen, Kinder und Nachrichten. Was wir unterschätzt hatten, war die Beziehung zwischen Eltern und Kindern: ein Kind mit getrennt lebenden Eltern, beide mit eigenem Zugang, unterschiedlichen Benachrichtigungen und teils unterschiedlichen Rechten. Das ist kein Sonderfall, das ist Alltag.

Bei der Alltagshilfe Software war es die Abrechnung nach §45b SGB XI. Die eigentliche Rechenlogik ist überschaubar. Aufwendig ist, dass sie stimmen muss – weil am Ende ein Kostenträger prüft und weil Fehler den Betrieb Geld kosten. Solche Module brauchen mehr Tests als der Rest der Anwendung zusammen.

Wie man daraus ein Angebot macht

Wenn Sie ein SaaS-Vorhaben kalkulieren lassen, achten Sie darauf, dass diese Punkte im Angebot einzeln auftauchen und nicht in einem Sammelposten verschwinden:

Baustein	Typischer Anteil	Häufig unterschätzt
Mandantenfähigkeit und Datenmodell	15–20 %	ja, weil unsichtbar
Authentifizierung und Rechte	10–15 %	ja
Fachliche Kernfunktionen	35–45 %	nein
Abrechnung	5–25 %	stark schwankend
Oberfläche und Bedienbarkeit	15–20 %	nein
Einrichtung und Übergabe	5–10 %	ja

Die Spanne bei der Abrechnung ist kein Ungefähr, sondern der eigentliche Punkt: Sie entscheidet oft darüber, ob ein Projekt bei 40.000 € oder bei 80.000 € landet. Wer sie im Erstgespräch nicht klärt, klärt sie später im Streit.

Was Sie mitnehmen sollten

Ein SaaS-Produkt ist zu vielleicht vierzig Prozent das, was der Kunde in der Oberfläche sieht. Der Rest ist Struktur: Trennung der Mandanten, Rechte, Abrechnung, Datenmodell, Übergabe. Diese Teile lassen sich nicht nachrüsten, ohne das Fundament anzufassen.

Die gute Nachricht: Sie müssen nicht alles zu Beginn bauen. Sie müssen es zu Beginn nur so bauen, dass es später möglich ist. Das ist ein Unterschied von wenigen Tagen zu Projektbeginn – und von mehreren Wochen, wenn man es verpasst.

Vier Bausteine, die immer später kommen als gedacht

Neben den großen Architekturfragen gibt es vier Teile, die in Angeboten fast nie auftauchen und in jedem Produkt gebraucht werden.

Benachrichtigungen

Kaum ein Produkt kommt ohne aus, und kaum eines behandelt sie als das, was sie sind: ein eigenes Teilsystem. Dazu gehören die Zustellwege – E-Mail, Push, im Produkt selbst –, die Einstellungen pro Nutzer, die Frage, was passiert, wenn dreißig Ereignisse in fünf Minuten auftreten, und Ruhezeiten.

Der Punkt, an dem es kippt, ist immer derselbe: Wenn Nutzer anfangen, Benachrichtigungen als störend zu empfinden, schalten sie alle ab – auch die wichtigen. Danach ist der Kanal tot. Deshalb ist die Bündelung mehrerer Ereignisse zu einer Nachricht keine Verfeinerung, sondern eine Grundfunktion.

Rechnen Sie für ein brauchbares Benachrichtigungssystem mit ein bis zwei Wochen. Für „wir schicken eine E-Mail, wenn etwas passiert" mit zwei Tagen – und mit dem Rest später.

Protokollierung von Änderungen

Wer hat wann was geändert? Diese Frage kommt garantiert, und sie kommt meist zu einem unangenehmen Zeitpunkt: wenn ein Datensatz falsch ist und geklärt werden muss, wie es dazu kam.

Bei besonderen Datenkategorien – Gesundheitsdaten, Daten über Kinder – ist eine Protokollierung nicht nur nützlich, sondern faktisch erwartet. Wichtig ist, sie von Anfang an mitlaufen zu lassen. Ein Protokoll, das erst ab Monat achtzehn existiert, beantwortet keine Frage zu den ersten achtzehn Monaten.

Die technische Umsetzung ist überschaubar, wenn sie zentral im Datenzugriff sitzt. Sie wird zur Plackerei, wenn sie in jeder einzelnen Funktion eingebaut werden muss – noch ein Argument dafür, den Datenzugriff nicht zu umgehen.

Import und Export

Zwei Richtungen, zwei Gründe. Der Import entscheidet darüber, wie schnell ein neuer Kunde produktiv wird. Wer seine dreihundert Bestandskunden von Hand eintippen muss, fängt gar nicht erst an. Ein Import aus einer Tabelle – auch ein unvollkommener, mit Fehlerliste und zweitem Versuch – ist oft der Unterschied zwischen Abschluss und Absage.

Der Export ist die Gegenrichtung und eine Vertrauensfrage. Ein Kunde, der seine Daten jederzeit vollständig herausbekommt, geht ein geringeres Risiko ein. Rechtlich steht die Datenübertragbarkeit ohnehin im Raum. Praktisch ist ein sauberer Export das stärkste Argument gegen die Sorge, sich abhängig zu machen.

Einrichtung neuer Mandanten

Am Anfang legt man neue Organisationen von Hand an. Das ist völlig in Ordnung – bis es der zwölfte ist und der Vorgang eine Stunde dauert, weil sechs Dinge an sechs Stellen eingetragen werden müssen.

Der Übergang von „machen wir manuell" zu „läuft von selbst" sollte geplant sein, nicht erzwungen. Ein guter Zeitpunkt ist der fünfte Kunde: Dann kennt man die Schritte, und es lohnt sich noch, sie zusammenzufassen.

Wann ein SaaS-Produkt kein SaaS-Produkt sein sollte

Zum Schluss der unbequeme Teil. Nicht jedes Vorhaben, das als SaaS geplant wird, sollte eines werden.

Wenn absehbar drei bis fünf Kunden das Produkt nutzen werden, ist Mandantenfähigkeit unter Umständen der falsche Aufwand. Fünf getrennte Installationen derselben Anwendung sind einfacher zu bauen, einfacher zu verstehen und erlauben jedem Kunden eigene Anpassungen. Der Betriebsaufwand steigt, aber nicht dramatisch.

Die Grenze verläuft ungefähr bei zehn Mandanten. Darunter überwiegt oft die Einfachheit getrennter Installationen. Darüber wird die Pflege von zehn Instanzen zum Hauptkostenblock, und Mandantenfähigkeit zahlt sich aus.

Diese Frage sollte im ersten Gespräch fallen. Sie fällt selten, weil „SaaS" gesetzt scheint – und weil sie unangenehm ist, wenn die Antwort lautet, dass das aufwendigere Modell nicht gebraucht wird.