SaaS oder individuelle Software: Wann wird Eigenentwicklung wirtschaftlich?

SaaS ist oft der wirtschaftlichere Start: Sie nutzen ein bestehendes Produkt, statt Entwicklung und Betrieb selbst zu organisieren. Das gilt aber nicht automatisch für einen Prozess, der stark von Standardabläufen abweicht. Wenn Mitarbeitende Daten manuell übertragen, Sonderfälle außerhalb des Systems verwalten oder mehrere Dienste aufwendig verbinden müssen, können laufende Aufwände und Einschränkungen den Lizenzvorteil aufzehren. Für Geschäftsführung, Projekt- und Produktverantwortliche sowie technische Leitungen lautet die Entscheidung deshalb nicht „Software kaufen oder bauen?“, sondern: Welche Gesamtkosten und Risiken entstehen mit jeder Option über die vorgesehene Nutzungsdauer? Eigenentwicklung wird wirtschaftlich, wenn sie relevante Reibung beseitigt und die Organisation die Verantwortung für Betrieb und Weiterentwicklung tragen kann. Entscheidend sind Prozesspassung, Ausnahmen, Datenflüsse, Änderungsbedarf und die Kosten des Nichtstuns.

Kurz gesagt

SaaS passt, wenn Ihr Prozess weitgehend dem Standard des Produkts entspricht und notwendige Integrationen sowie Datenzugriffe verlässlich abgedeckt sind. Individuelle Software kann wirtschaftlicher sein, wenn wiederkehrende Ausnahmen, manuelle Arbeit oder mehrere unverbundene Systeme einen wesentlichen Teil des Prozesses ausmachen. Vergleichen Sie nicht nur Lizenz und Entwicklung, sondern auch Integration, Betrieb, Wartung, interne Arbeit und die Folgen eingeschränkter Datenhoheit. Eine Mischform ist oft sinnvoll: Standardfunktionen bleiben im SaaS, während nur der differenzierende oder verbindende Teil individuell umgesetzt wird.

Ausgangslage

SaaS verschiebt einen Teil der technischen Verantwortung zum Anbieter. Dieser entwickelt, betreibt und aktualisiert das Produkt; die Organisation bezahlt für Nutzung und vereinbarte Leistungen. Das reduziert den Bedarf, ein eigenes System von Grund auf aufzubauen. Es bedeutet aber auch, dass Prozesse, Datenzugriff und Änderungsmöglichkeiten durch Produktumfang und Vertragsbedingungen begrenzt sein können.

Bei individueller Software ist die Passung potenziell höher. Anforderungen, Datenmodell und Abläufe lassen sich gezielt abbilden. Dafür muss die Organisation Entwicklung, Betrieb, Sicherheit, Fehlerbehebung und Weiterentwicklung dauerhaft ermöglichen – selbst oder mit einem verlässlichen technischen Partner.

Der Vergleich wird oft verzerrt, weil nur sichtbare Kosten gegenübergestellt werden: eine SaaS-Lizenz gegen ein Entwicklungsangebot. Damit fehlen auf SaaS-Seite etwa Integrations- und manuelle Aufwände. Auf der Eigenentwicklungsseite fehlen häufig Betrieb, Wartung und spätere Änderungen. Beide Optionen haben außerdem Wechselkosten: Daten müssen migriert, Schnittstellen angepasst und Arbeitsweisen verändert werden.

Wirtschaftlichkeit ist daher keine feste Eigenschaft eines Produkts. Sie hängt davon ab, wie gut es zum konkreten Prozess passt und wie stabil dieser Prozess voraussichtlich bleibt.

Entscheidungskriterien

1. Wie viel des Prozesses ist tatsächlich Standard?

Beschreiben Sie den Ablauf vom Eingang eines Vorgangs bis zu seinem Abschluss. Markieren Sie, welche Schritte das SaaS direkt unterstützt, welche Konfiguration benötigen und welche außerhalb des Systems stattfinden.

Ein einzelner Sonderfall ist nicht automatisch ein Grund für Eigenentwicklung. Relevant wird er, wenn Ausnahmen häufig sind, wichtige Entscheidungen betreffen oder regelmässig manuelle Arbeit auslösen. Prüfen Sie auch, ob der Prozess selbst vereinheitlicht werden kann, bevor Sie Software an bestehende Sonderwege anpassen.

2. Welche Arbeit bleibt neben dem System bestehen?

Erfassen Sie nicht nur Klicks innerhalb des Produkts. Berücksichtigen Sie Übertragungen zwischen Anwendungen, Tabellen als Nebenregister, doppelte Dateneingaben, manuelle Prüfungen und Rückfragen, die durch fehlende Informationen entstehen.

Fragen Sie, wer diese Arbeit erledigt, an welcher Stelle sie anfällt und ob sie mit der vorgesehenen Lösung verschwindet. Wenn eine neue Plattform nur das bestehende System ergänzt, ohne den gesamten Ablauf zu verändern, kann zusätzlicher Pflegeaufwand entstehen statt einer Entlastung.

3. Welche Lizenz- und Nutzungskosten wachsen mit?

Prüfen Sie, wie sich die Abrechnung bei zusätzlichen Nutzerinnen und Nutzern, Funktionen, Datenvolumen oder verbundenen Systemen verändert. Berücksichtigen Sie auch getrennte Produkte, die für den vollständigen Ablauf benötigt werden.

Eine Lizenz ist nur ein Teil der laufenden Kosten. Für den Vergleich zählt, was die Organisation insgesamt bezahlen und intern betreiben muss. Legen Sie dabei keine künstlich genaue Prognose zugrunde, wenn Nutzung und künftige Anforderungen noch unklar sind. Arbeiten Sie stattdessen mit nachvollziehbaren Szenarien: heutiger Bedarf, erwartbare Erweiterung und ein Fall mit zusätzlichen Anforderungen.

4. Wie aufwendig sind Integrationen und Datenflüsse?

Klären Sie, welche Systeme Daten bereitstellen oder entgegennehmen müssen. Gibt es dokumentierte Schnittstellen? Können Informationen automatisch und in beide Richtungen synchronisiert werden? Wie werden Fehler, Dubletten und Änderungen behandelt?

Eine Integration ist nicht allein mit dem ersten Datentransfer erledigt. Sie muss auch bei Änderungen an den beteiligten Systemen funktionieren und überprüfbar bleiben. Wenn kritische Abläufe von nicht stabilen Schnittstellen, manuellen Exporten oder schwer kontrollierbaren Workarounds abhängen, gehört dieses Risiko in den Vergleich.

5. Wie wichtig sind Datenhoheit und Portabilität?

Klären Sie, welche Daten Sie exportieren können, in welcher Struktur und mit welchen Einschränkungen. Prüfen Sie außerdem, ob Ihre Daten mit anderen Systemen genutzt werden dürfen und wie ein späterer Wechsel ablaufen würde.

Datenhoheit ist nicht nur eine Frage des Speicherorts. Sie betrifft auch Zugriff, Nutzungsrechte, Änderbarkeit und die Möglichkeit, Daten in einer brauchbaren Form weiterzuverwenden. Wenn diese Punkte für Ihren Prozess entscheidend sind, sollten sie vor einer Auswahl vertraglich und technisch geprüft werden. Datenschutz- und andere rechtliche Anforderungen sind im jeweiligen Einzelfall zu klären; dieser Beitrag ersetzt keine Rechtsberatung.

6. Wie viel Kontrolle brauchen Sie über Änderungen?

Ein SaaS-Anbieter bestimmt, wann Funktionen geändert oder entfernt werden und welche Anpassungen möglich sind. Das kann für standardisierte Prozesse ausreichen. Bei individuellen Abläufen kann es zum Engpass werden, wenn benötigte Änderungen nicht zeitnah oder gar nicht umgesetzt werden können.

Mit individueller Software gewinnen Sie Einfluss auf Prioritäten und Ausgestaltung. Das bedeutet nicht, dass jede Änderung sofort oder ohne Aufwand erfolgt. Sie brauchen klare Zuständigkeiten, eine gepflegte Dokumentation und einen Prozess für Tests und Freigaben.

7. Kann die Organisation Wartung dauerhaft tragen?

Eigenentwicklung endet nicht mit der ersten produktiven Version. Abhängigkeiten müssen aktualisiert, Fehler behoben und Anforderungen bewertet werden. Auch Betrieb, Backups, Zugriffsrechte und Sicherheitsprüfungen brauchen Zuständigkeiten.

SaaS nimmt einen Teil dieser Aufgaben ab, aber nicht alle. Die Organisation bleibt beispielsweise verantwortlich für Konfiguration, Berechtigungen, Datenqualität und die Einbindung in eigene Abläufe. Vergleichen Sie also nicht „Wartung“ mit „keiner Wartung“, sondern unterschiedliche Verteilungen der Verantwortung.

Optionen im Vergleich

Option	Passt eher, wenn …	Prüfen Sie besonders …
SaaS unverändert nutzen	der Prozess dem vorgesehenen Standard entspricht	Datenexport, Berechtigungen, Leistungsumfang und Vertragsbedingungen
SaaS konfigurieren	Standardfunktionen passen, aber Felder, Rollen oder Abläufe angepasst werden müssen	Grenzen der Konfiguration, Erweiterbarkeit und Kosten zusätzlicher Module
SaaS integrieren	das Kernprodukt passt, aber Daten zwischen Systemen fließen müssen	Schnittstellen, Fehlerbehandlung, Synchronisation und laufende Pflege
Individuelle Software entwickeln	Prozesslogik, Datenmodell oder Nutzerrollen nicht sinnvoll in Standardsoftware passen	Betrieb, Wartung, Dokumentation, Verantwortlichkeiten und spätere Änderungen
Mischform umsetzen	Standardfunktionen mit einem individuell entwickelten Teil verbunden werden können	klare Systemgrenzen, Datenhoheit und langfristige Integrationskosten

SaaS unverändert nutzen

Das ist meist die schlankste Variante, wenn der Nutzen ohne umfangreiche Anpassungen erreichbar ist. Sie vermeiden eigene Produktentwicklung und können die Lösung am tatsächlichen Bedarf prüfen. Achten Sie darauf, dass nicht wichtige Prozessschritte dauerhaft in Tabellen, E-Mails oder anderen Nebensystemen verbleiben.

SaaS konfigurieren oder integrieren

Konfiguration und Schnittstellen können die Lücke zwischen Standard und Prozess schließen. Die Lösung bleibt dabei teilweise vom Anbieter abhängig. Prüfen Sie vorab, ob die benötigte Anpassung mit unterstützten Funktionen möglich ist und wer sie bei Produktänderungen betreut.

Individuelle Software entwickeln

Diese Option bietet sich an, wenn zentrale Geschäftslogik, Datenstrukturen oder Rollen spezifisch sind und sich nicht sinnvoll in ein Standardprodukt pressen lassen. Beginnen Sie nicht mit einer langen Wunschliste. Definieren Sie den kleinsten produktiven Umfang, der einen nachweisbaren Engpass beseitigt, und planen Sie Betrieb sowie Weiterentwicklung von Anfang an mit.

Eine Mischform wählen

Nicht jedes System muss vollständig individuell sein. Ein SaaS kann beispielsweise die Standardverwaltung übernehmen, während eine eigene Anwendung spezifische Daten aufbereitet, Prozesse verbindet oder eine besondere Nutzeroberfläche bereitstellt. Die Trennung muss jedoch klar sein: Welches System ist für welche Daten und Entscheidungen verantwortlich? Ohne diese Festlegung entstehen doppelte Datenhaltung und schwer nachvollziehbare Zuständigkeiten.

Vorgehen für einen belastbaren Vergleich

1. Prozess erfassen: Dokumentieren Sie den heutigen Ablauf, die beteiligten Rollen, Datenquellen und Ausnahmen.
2. Aufwände sichtbar machen: Halten Sie Lizenz- und Integrationsaufgaben sowie manuelle Arbeit und interne Betreuung getrennt fest.
3. Anforderungen priorisieren: Unterscheiden Sie zwischen zwingenden Anforderungen, sinnvollen Verbesserungen und optionalen Wünschen.
4. Szenarien vergleichen: Prüfen Sie mindestens die Nutzung des SaaS im Standard, eine konfigurierte oder integrierte Variante und eine individuelle oder hybride Lösung.
5. Annahmen offenlegen: Benennen Sie, was noch unklar ist, etwa künftige Nutzerzahlen, Schnittstellenverfügbarkeit oder Änderungsbedarf.
6. Verantwortung festlegen: Bestimmen Sie, wer Daten, Betrieb, Zugriffe, Fehler und Weiterentwicklung verantwortet.
7. Entscheidung überprüfbar machen: Definieren Sie, woran Sie nach Einführung erkennen, ob die gewählte Lösung den Prozess tatsächlich verbessert.

So wird die Entscheidung nicht auf ein einmaliges Angebot reduziert. Sie bleibt nachvollziehbar, wenn sich Anforderungen oder Nutzung verändern.

Typische Fehler

• Nur Lizenz und Entwicklung vergleichen: Damit bleiben interne Arbeit, Integration und Betrieb unsichtbar.
• Jede Ausnahme als Sonderentwicklung behandeln: Manchmal lässt sich der Prozess vereinfachen oder mit einer Konfiguration abbilden.
• SaaS als wartungsfrei betrachten: Konfiguration, Datenqualität, Zugriffsverwaltung und Integrationen brauchen weiterhin Betreuung.
• Eigenentwicklung als einmalige Ausgabe planen: Nach dem Start bleiben Betrieb, Sicherheitsupdates und fachliche Änderungen bestehen.
• Eine vollständige Eigenlösung voraussetzen: Oft genügt eine gezielte Ergänzung um ein passendes Standardprodukt.
• Datenexport erst beim Wechsel prüfen: Ein späterer Ausstieg kann aufwendiger werden, wenn Format und Vollständigkeit vorher nicht geklärt wurden.
• Anforderungen ohne Priorität sammeln: Eine lange Liste von Funktionen macht die Entscheidung nicht belastbarer, wenn der geschäftliche Nutzen ungeklärt bleibt.
• Erfolg nur an der Inbetriebnahme messen: Entscheidend ist, ob Ausnahmen, manuelle Arbeit oder Integrationsprobleme im Alltag tatsächlich abnehmen.

Praxisbeispiel

Wendewerk zeigt, wie spezifische Daten, Rollen und Abläufe eine Plattform prägen können: Das WordPress-System verarbeitet Krankenkassen- und Leistungsdaten. Es umfasst Rollen für Krankenkassen, Experten, Präventionsanbieter und Versicherte sowie Vergleichs- und Beitragsrechner. Satzungstexte werden KI-gestützt extrahiert; die Ergebnisse durchlaufen ein Staging und ein Review, bevor sie zusammengeführt werden. Eine token-authentifizierte REST-API stellt Daten für eine App bereit.

Das Beispiel belegt nicht, dass Eigenentwicklung in jedem vergleichbaren Fall wirtschaftlicher wäre. Es verdeutlicht vielmehr, welche Anforderungen in einer Architekturentscheidung zu prüfen sind: mehrere Rollen, ein spezifisches Datenmodell, kontrollierte Verarbeitung und eine angebundene Anwendung. Wendewerk-Projekt ansehen

Empfehlung

• Wenn Ihr Ablauf weitgehend dem Produktstandard entspricht, notwendige Daten exportierbar sind und Schnittstellen ausreichen, dann starten Sie mit SaaS.
• Wenn der Standard passt, aber klar abgrenzbare Lücken bestehen, dann prüfen Sie zuerst Konfiguration oder Integration.
• Wenn wiederkehrende Ausnahmen, manuelle Übertragungen oder zentrale Prozessregeln die tägliche Arbeit prägen, dann vergleichen Sie eine gezielte Eigenentwicklung mit einer Mischform.
• Wenn Datenmodell, Rollen und Geschäftslogik eng zusammenhängen und sich mit SaaS nur durch dauerhafte Workarounds abbilden lassen, dann kann individuelle Software wirtschaftlicher werden – sofern Betrieb und Wartung dauerhaft gesichert sind.
• Wenn Anforderungen, Nutzung oder Zuständigkeiten noch unklar sind, dann verschieben Sie die Grundsatzentscheidung nicht mit einer vorschnellen Vollentwicklung. Erfassen Sie zuerst den Prozess und testen Sie die kritischsten Annahmen.

Checkliste

• Ist der heutige Prozess einschließlich Ausnahmen und manueller Zwischenschritte dokumentiert?
• Sind Muss-Anforderungen von optionalen Funktionen getrennt?
• Ist sichtbar, welche Arbeiten außerhalb des SaaS verbleiben?
• Sind Lizenz-, Integrations- und interne Betreuungsaufwände berücksichtigt?
• Wurden Schnittstellen und Fehlerbehandlung geprüft?
• Sind Export, Weiterverwendung und Wechselbarkeit der Daten geklärt?
• Ist festgelegt, wer Konfiguration, Betrieb und Wartung verantwortet?
• Wurden Standardnutzung, Konfiguration, Integration und Eigenentwicklung verglichen?
• Gibt es Kriterien, mit denen sich die Wirkung der gewählten Lösung später überprüfen lässt?

Häufige Fragen

Ist SaaS immer günstiger als individuelle Software?

Nein. SaaS kann Entwicklung und Betrieb vereinfachen, aber Lizenz-, Integrations- und manuelle Aufwände bleiben Teil des Gesamtbilds. Eigenentwicklung verursacht ihrerseits laufende Kosten und Verantwortung.

Wann ist eine Eigenentwicklung zu früh?

Wenn der Prozess noch nicht verstanden ist, Anforderungen häufig wechseln oder der erwartete Nutzen nicht klar benannt werden kann. Erfassen und priorisieren Sie zuerst die Abläufe und prüfen Sie, ob Standardsoftware die wichtigsten Anforderungen abdeckt.

Muss eine individuelle Lösung komplett neu entwickelt werden?

Nein. Eine Mischform kann ein SaaS mit einem eigenen Datenmodell, einer Schnittstelle oder einer spezifischen Anwendung verbinden. Wichtig sind klare Zuständigkeiten und nachvollziehbare Datenflüsse.

Wie lässt sich die Wirtschaftlichkeit nach der Einführung prüfen?

Vergleichen Sie die vorher festgelegten Kriterien mit dem Betrieb: etwa verbliebene manuelle Schritte, Ausnahmen, Integrationsfehler und Betreuungsaufwand. So wird sichtbar, ob die Lösung den erwarteten Engpass tatsächlich reduziert.

Weiterführend

• CMS, Static Site oder Web-App? Die richtige Architektur für digitale Projekte
• WordPress oder Webanwendung: Wann reicht ein CMS nicht mehr?
• API-first: Wann eine API wirklich zur Architektur gehören sollte
• Datenmodelle statt Plugin-Stapel