Eine häufige Frage vor einem SaaS-Projekt (Software, die Ihr Team im Browser nutzt und die zentral auf einem Server läuft): „Was passiert, wenn wir wachsen?“ Im Mittelstand wird oft mit einem kleinen Pilot gestartet – fünf Nutzer, ein Modul, eine Niederlassung. Wenn sich die Software bewährt, soll sie schnell auf das ganze Unternehmen ausgerollt werden. Plötzlich werden aus 5 Nutzern 50, aus einer Niederlassung fünf, aus 100 Datensätzen pro Tag 2.000.
Eine gut entworfene individuelle SaaS-Anwendung sollte das mitmachen, ohne dass alle paar Monate eine teure Neuentwicklung nötig wird. Dieser Artikel zeigt, welche Architektur-Entscheidungen am Anfang gefällt werden müssen, damit Skalierung später nicht zum Problem wird.
Drei Skalierungsdimensionen
„Skalierung“ ist ein vielschichtiger Begriff. Es lohnt sich, drei Dimensionen zu unterscheiden:
- Nutzer-Skalierung: Mehr gleichzeitige Anwender
- Daten-Skalierung: Mehr Datensätze, größere Datenbank
- Funktions-Skalierung: Mehr Module, mehr Anwendungsfälle
Diese drei Dimensionen erfordern unterschiedliche technische Antworten. Eine Architektur, die für 5 Nutzer entwickelt wurde, hält 50 Nutzer locker aus – aber nicht, wenn parallel die Datenmenge auf das Hundertfache wächst.
Architektur-Grundlagen, die später entscheidend werden
1. Trennung von Frontend und Backend
Eine moderne SaaS-Architektur trennt Oberfläche (Frontend) und Geschäftslogik (Backend) sauber. Das hat zwei Vorteile beim Skalieren: Die Last verteilt sich auf unterschiedliche Server, und die Oberfläche kann ausgetauscht werden, ohne dass die Geschäftslogik betroffen ist (z. B. wenn später eine Mobile App dazukommt).
2. Eine Datenbank, klare Modelle
Die meisten KMU-Anwendungen kommen mit einer einzelnen relationalen Datenbank (PostgreSQL, MySQL) bis weit jenseits der 100 Nutzer aus – wenn die Datenmodelle sauber sind. Ich setze ausschließlich auf Open-Source-Datenbanken, damit später keine Abhängigkeit von einem Anbieter (Lock-in) entsteht.
3. Caching von Anfang an mitdenken
Auswertungen, Berichte und Dashboards sind die ersten Stellen, an denen es bei steigender Nutzer-/Datenzahl langsam wird. Eine Cache-Schicht (z. B. Redis) wird oft erst nachträglich gebraucht – aber es ist gut, wenn die Architektur das von Anfang an erlaubt.
4. Hintergrundjobs auslagern
Lange Vorgänge (Massen-E-Mails, Reports, Datenexporte) sollten nicht im Browser-Request laufen. Eine saubere Job-Queue (z. B. mit BullMQ oder Celery) macht das System robust gegen Lastspitzen.
5. Mehrmandantenfähigkeit klären
Werden später mehrere Niederlassungen, Tochtergesellschaften oder Mandanten getrennt verwaltet? Wenn ja, sollte die Architektur das von Anfang an unterstützen – sonst ist der nachträgliche Umbau teuer.
Faustregel: Eine Architektur, die für 50 Nutzer entworfen ist, trägt typischerweise auch 200 Nutzer. Eine, die nur für 5 entworfen wurde, kommt schon bei 30 ans Limit.
Hosting-Skalierung: Was wirklich gebraucht wird
Im Mittelstand wird oft befürchtet, dass Skalierung teure Cloud-Architektur (Kubernetes, Microservices, etc.) erfordert. Das ist meist nicht der Fall.
Klein: 1–20 Nutzer
Ein einzelner Server bei einem deutschen Hoster (z. B. Hetzner, IONOS, Open Telekom Cloud). Kosten: 30–80 €/Monat. Reicht für die meisten KMU-Anwendungen über Jahre.
Mittel: 20–100 Nutzer
Ein etwas größerer Server oder zwei kleinere mit Lastverteilung. Datenbank auf separatem Server. Kosten: 150–400 €/Monat. Hier lohnt sich auch ein zweites System für Tests/Staging.
Groß: 100+ Nutzer oder mehrere Mandanten
Mehrere Anwendungs-Server hinter einem Load-Balancer, Datenbank-Cluster mit Replikation, dedizierter Cache- und Job-Server. Kosten: 500–1.500 €/Monat. Hier wird es interessant, mehrere Niederlassungen oder Mandanten parallel zu bedienen.
Wichtig: Die Server-Skalierung ist meist günstiger als die zusätzlichen Lizenzkosten bei Standard-SaaS. Selbst wenn das Hosting für 50 Nutzer einige hundert Euro im Monat kostet, ist das ein Bruchteil von Standard-SaaS mit 50 × 79 € = 3.950 €/Monat.
Performance-Themen, die beim Wachstum auftauchen
Langsame Auswertungen
Eine Liste mit 100 Datensätzen lädt schnell. Bei 10.000 Datensätzen dauert es spürbar länger. Abhilfe: Pagination (Listen seitenweise laden), Such-Indizes in der Datenbank, vorberechnete Auswertungen.
Konkurrierende Schreibzugriffe
Bei 5 Nutzern editiert selten jemand denselben Datensatz gleichzeitig. Bei 50 schon. Abhilfe: Sperr-Mechanismen, Versionierung, „Live-Update“-Hinweise im Frontend.
Mail-Versand und externe APIs
Wenn täglich 10 Mails verschickt werden, ist das einfach. Wenn täglich 5.000 Mails ausgehen, braucht es eine Mail-Queue mit Retry-Logik und einen seriösen Versanddienst (z. B. Postmark, Mailjet).
Backup-Zeiten
Eine 100-MB-Datenbank ist in Sekunden gesichert. Eine 50-GB-Datenbank braucht Strategien für inkrementelle Backups, damit der Sicherungsprozess nicht den laufenden Betrieb behindert.
Lizenzfallen, die beim Skalieren auftauchen
Selbst bei individueller SaaS gibt es indirekte Lizenzkosten, die bei steigender Nutzerzahl wachsen können. Ich prüfe das explizit:
- Karten-Dienste: Google Maps, Mapbox – ab gewissen Aufrufzahlen kostenpflichtig
- SMS-Dienste: Pro Nachricht abgerechnet
- Mailversand: Pro 1.000 Mails
- Externe APIs: Wetterdaten, Zahlungsabwicklung, Adressprüfung
- Speicher: Wenn jeder Nutzer Dateien hochlädt, summiert sich das
In einem ehrlichen Angebot werden diese Posten transparent ausgewiesen, mit Schätzungen für Klein-, Mittel- und Großbetrieb.
Beispiel: Skalierung in der Praxis
Ein Beispiel, wie das aussehen kann: Ein Pflegedienst startet mit 8 Nutzern und einer Niederlassung. Das System verwaltet Dienstpläne, Patientenakten und Abrechnungen. Innerhalb von 18 Monaten kommen drei weitere Niederlassungen hinzu, die Nutzerzahl wächst auf 47.
Was muss dann angepasst werden?
- Hosting: vom 35-Euro-Server auf zwei 100-Euro-Server mit Datenbank-Replikation
- Mehrmandanten-Funktion: ist von Anfang an vorbereitet und muss nur aktiviert werden
- Schichtplan-Algorithmus: für 50 Mitarbeitende deutlich rechenintensiver als für 8 – wird optimiert (etwa 3 Tage Aufwand)
- Mail-Volumen: vom internen Mailserver auf einen Versanddienst umstellen
Der Aufwand für diese Anpassungen bleibt überschaubar – deutlich weniger als die zusätzlichen Lizenzkosten, die Standard-SaaS bei 47 Nutzern im gleichen Zeitraum verursachen würde.
Wann eine Neuentwicklung wirklich nötig ist
Es gibt Situationen, in denen Skalierung an Grenzen stößt – auch bei guter Architektur. Typische Auslöser:
- Wenn aus einer KMU-Anwendung ein Plattform-Geschäft wird (mit zehntausenden externen Nutzern)
- Wenn das Geschäftsmodell sich grundlegend ändert
- Wenn nach 8–10 Jahren die Technologien veraltet sind
- Wenn fundamental neue Anforderungen entstehen (z. B. Echtzeit-IoT-Daten)
In solchen Fällen ist eine schrittweise Migration auf eine neue Generation sinnvoll – nicht ein Big Bang. Aus einem alten System gewinnt man Erfahrung, die in das neue einfließt.
Fazit
Skalierung individueller SaaS ist kein Geheimnis – sie braucht ein paar Architektur-Entscheidungen am Anfang und einen ehrlichen Blick auf die zu erwartende Entwicklung. Wer heute mit 5 Nutzern startet, aber langfristig 50 erwartet, sollte das im Workshop klar ansprechen. Die Mehrkosten in der Anfangsentwicklung sind überschaubar – die Einsparungen beim Wachstum oft erheblich.
Wenn ich individuelle Software entwickle, plane ich Skalierung von Anfang an mit. Nicht, weil jedes Projekt zur Plattform wird – sondern weil eine durchdachte Architektur auch im KMU-Maßstab langlebiger ist.
Sie planen ein Projekt mit unklarem Wachstum? Im Workshop entwickeln wir gemeinsam mehrere Szenarien (5/20/50/100 Nutzer), und ich zeige Ihnen, was sich technisch und wirtschaftlich jeweils ändert.