Eine der am häufigsten gestellten Fragen vor einem SaaS-Projekt: „Was passiert, wenn wir wachsen?" Im Mittelstand wird oft mit einem kleinen Pilot gestartet – fünf Nutzer, ein Modul, eine Niederlassung. Wenn die Lösung trägt, 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-Lösung 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 Lösungen. 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. Wir setzen ausschließlich auf Open-Source-Datenbanken, damit später kein 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ätzliche Lizenzkosten bei Standard-SaaS. Wer mit 50 Nutzern und 199 €/Monat Hosting auskommt, zahlt im Vergleich zu Standard-SaaS mit 50 × 79 € = 3.950 €/Monat einen Bruchteil.
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. Lösung: Pagination, Such-Indizes in der Datenbank, vorberechnete Auswertungen.
Konkurrierende Schreibzugriffe
Bei 5 Nutzern editiert selten jemand denselben Datensatz gleichzeitig. Bei 50 schon. Lösung: 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. Wir prüfen 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 Klarspur-Projekt aus 2024 illustriert das gut: Ein Pflegedienst startete mit 8 Nutzern und einer Niederlassung. Das System verwaltete Dienstpläne, Patientenakten und Abrechnungen. Innerhalb von 18 Monaten kamen drei weitere Niederlassungen hinzu, die Nutzerzahl wuchs auf 47.
Was musste angepasst werden?
- Hosting: vom 35-Euro-Server auf zwei 100-Euro-Server mit Datenbank-Replikation
- Mehrmandanten-Funktion: war von Anfang an vorbereitet, musste nur aktiviert werden
- Schichtplan-Algorithmus: für 50 Mitarbeitende deutlich rechenintensiver als für 8 – wurde optimiert (3 Tage Aufwand)
- Mail-Volumen: vom internen Mailserver auf einen Versanddienst umgestellt
Gesamt-Aufwand für die Skalierung von 8 auf 47 Nutzer: etwa 4.500 € Anpassungen über 18 Monate. Lizenzkostenvergleich Standard-SaaS hätte im gleichen Zeitraum mehrere zehntausend Euro mehr gekostet.
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.
Bei Klarspur planen wir 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 zeigen, was sich technisch und wirtschaftlich jeweils ändert.