Eigene Plattform bauen vs. SaaS mieten

„Sollen wir das selbst bauen oder gibt es das nicht schon als SaaS?” ist die berechtigte Frage zu Beginn jedes Plattform-Projekts. Die ehrliche Antwort: SaaS deckt in den meisten Fällen 80 % ab. Die fehlenden 20 % sind oft genau die, an denen das Geschäft hängt. Hier ist die Heuristik, mit der wir die Entscheidung mit Auftraggeber:innen durchgehen.

Was SaaS gut kann

Standard-SaaS ist eine starke Default-Option. Die Gründe, warum es so viele gute SaaS-Plattformen gibt, sind real:

• Time-to-Live ist kurz. Konto buchen, User einladen, los. Statt Monaten der Entwicklung sind es Tage des Setups.
• Operativ-Last ist outsourced. Hosting, Backups, Sicherheits-Patches, Compliance-Updates passieren beim Anbieter, du zahlst dafür eine Monatslizenz.
• Feature-Roadmap ist gemeinschaftlich finanziert. Tausende Kund:innen treiben die Roadmap, du profitierst von Features, die du nie selbst priorisiert hättest.
• Tooling-Ökosystem. Etablierte SaaS-Plattformen haben Integrationen, Marketplaces und Drittanbieter-Add-ons.

Wenn dein Use-Case ins mittlere Drittel der Anbieter-Zielgruppe fällt, und das ist häufiger der Fall, als man denkt, ist SaaS der richtige Pfad. Punkt. Custom-Dev gegen einen passenden SaaS-Anbieter zu stemmen, ist meist Verschwendung.

Wo SaaS klemmt

Die Reißpunkte tauchen nicht an einem einzelnen Tag auf, sondern wachsen. Vier Muster, die wir immer wieder sehen:

1. Domänenspezifische Workflows

SaaS optimiert für den Median-Use-Case. Wenn deine Branche Sonderfälle hat, die der Anbieter nie gebaut hat, landest du in Workarounds: Custom-Felder, External-Integrations, manuelle Schritte zwischen zwei Tools, Excel-Brücken. Jeder Workaround kostet Zeit und führt zu Datenverlust an den Übergängen.

Beispiel aus unserer Praxis: ein CoWorking-Workspace-Setup, das mit Plattformen wie OfficeRnD oder Cobot startet, an Hardware-Integrationen (Türöffnung, Heizungssteuerung, IoT-Sensorik) und an Branding-/Multi-Standort-Anforderungen aber strukturell scheitert. Die Plattform funktioniert für 80 % der Buchung, die fehlenden 20 % sind die, die den Service-Unterschied ausmachen.

2. Daten-Hoheit und Self-Host

DSGVO-kritische Branchen wie Gesundheit & Wohlbefinden, Bildung & Wissenstransfer oder Teile des öffentlichen Sektors kommen früher oder später an den Punkt, an dem Self-Hosting nicht mehr verhandelbar ist. Entweder weil eine Aufsicht es verlangt, ein Großkunde es als Vertragsbedingung setzt oder eine Datenschutz-Folgenabschätzung das eigene Hosting empfiehlt.

Standard-SaaS lässt sich hier oft nicht überreden. Manche bieten On-Prem-Tarife, die kosten dann aber häufig mehr als ein Eigenbau über drei Jahre.

3. Multi-Tenant-Branding und Reseller-Logik

Wer eine eigene Lösung an mehrere Endkunden ausrollt (Franchise-Geber, B2B-Plattform-Betreiber, Agenturen), braucht echtes Whitelabel mit Tenant-Isolation. Standard-SaaS lässt das selten zu. „Custom-Logo” und „eigene Domain” reichen nicht, sobald Tenant-spezifische Workflows, Daten-Trennung und Reseller-Abrechnungen ins Spiel kommen.

Beispiel: ein Franchise-System mit 30+ Standorten, das jedem Standort ein eigenes Backoffice mit eigenem Reporting-Set geben will. SaaS-Plattformen für Franchise gibt es, aber sie geben den Datenzugriff selten so frei, dass eine zentrale Auswertung sauber funktioniert.

4. Integrationspflichtige Workflows

Sobald deine Plattform mit drei oder mehr externen Systemen sprechen muss (ERP, Buchhaltung, branchenspezifische Software, eigene Hardware), kippt das SaaS-Modell. Jede Integration über die Standard-API hinaus kostet entweder Workaround-Aufwand oder Custom-Development am Rand der SaaS-Plattform. Beides skaliert schlecht.

Sobald die Mehrzahl der Anpassungen außerhalb der SaaS-Plattform liegt, ist die SaaS-Plattform nicht mehr die Plattform, sondern eine Komponente, und meist die teuerste.

TCO über drei Jahre eine ehrliche Rechnung

Der Lizenzpreis allein vergleicht sich schlecht. Eine sauberere Rechnung, die wir in Workshops einsetzen:

SaaS-Pfad (3 Jahre):

• Lizenzkosten × User × 36 Monate
• Customizing-Stunden für Ersteinrichtung und kontinuierliche Anpassungen
• Integrationskosten zu deinen anderen Systemen (oft per Anbieter abgerechnet)
• Eigene Stunden für Workarounds, Excel-Brücken, manuelle Daten-Übergänge
• Migration-Risiko-Aufschlag, falls der Anbieter seine Bedingungen ändert oder die Plattform abkündigt

Eigenbau-Pfad (3 Jahre):

• Initiales Build-Budget (typisch 30–150 k€ je nach Scope)
• Laufendes AppCare (ab 149 €/Monat für aktive Plattformen)
• Hosting (oft im AppCare enthalten oder im niedrigen dreistelligen Bereich/Monat)
• Geringe oder keine Lizenz-Skalierung mit User-Zahl

Faustregel aus unserer Praxis: ab etwa 30–50 aktiven Plattform-Nutzer:innen mit nicht-trivialer Workflow-Tiefe rechnet sich der Eigenbau über drei Jahre. Bei wenigen User:innen oder hochstandardisierten Workflows gewinnt SaaS klar.

Entscheidungs-Heuristik

Vier Fragen, wenn du auf zwei oder mehr mit „ja” antwortest, lohnt sich ein Eigenbau-Workshop:

• Hat dein Geschäft einen domänenspezifischen Workflow, den die SaaS-Anbieter strukturell nicht abbilden (nicht: nicht abgebildet haben, sondern strukturell nicht passen)?
• Verlangt eine Aufsicht oder ein Großkunde Daten-Hoheit, die nur Self-Hosting liefert?
• Skaliert der Lizenzpreis mit Endkund:innen oder Tenants in einer Weise, die den TCO über 3 Jahre erkennbar nach oben zieht?
• Sind drei oder mehr externe Integrationen Pflicht, die über die Standard-API der SaaS-Plattform hinausgehen?

Wenn null oder eine der Fragen mit „ja” beantwortet wird: SaaS bleibt der bessere Pfad. Custom-Dev wäre Premature-Optimization.

Hybrid-Pfade, die in der Praxis tragen

Die saubere Trennung „SaaS oder Eigenbau” ist häufig falsch. Drei Hybrid-Setups, die wir gebaut haben:

• SaaS für Standard-Funktionen, Eigenbau für die Differenzierung. Die kritischen 20 % laufen auf einer Custom-Plattform, die mit einer SaaS-Standard-Lösung über API verheiratet ist.
• Eigenbau mit klar definiertem Migrationspfad. Wer heute Custom baut, ohne saubere Daten-Export-Pfade vorzusehen, baut sich denselben Lock-in, vor dem er bei SaaS warnt. Daten-Hoheit heißt: Daten gehen jederzeit in offenen Formaten raus.
• SaaS-Pilot, dann Migration. In Phase 1 zwölf Wochen mit einem SaaS-Tool starten, um den Workflow zu validieren und User-Feedback zu sammeln. In Phase 2 Eigenbau auf Basis dessen, was wirklich gebraucht wurde, nicht auf Basis dessen, was im ersten Konzept stand.

Wenn du unsicher bist, beschreib uns über das Kontaktformular, wie viele User die Plattform hat, in welcher Branche sie läuft und was die Top-3-Workflows sind. Wir sagen ehrlich, ob SaaS, Eigenbau oder Hybrid in deinem Fall trägt, und welcher SaaS-Anbieter aus unserer Sicht in Frage käme, falls Eigenbau nicht der Pfad ist. Antwort zeitnah. Mehr Kontext zur Stack-Wahl: Native vs. Cross-Plattform vs. PWA. Wenn nach dem Build die Wartungs-Frage kommt: AppCare vs. Stundenbasis vs. interner Entwickler.