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 — Gesundheit & Wohlbefinden, Bildung & Wissenstransfer, 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 die Plattform in drei Sätzen — User-Anzahl, Branche, Top-3-Workflows — über das Kontaktformular. 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 in 24 Stunden. 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.