SaaS vs. Individualsoftware: Die Entscheidungsmatrix für den Mittelstand

Stand: 2. September 2026

Die meisten Build-vs-Buy-Entscheidungen werden auf der falschen Achse getroffen. Es wird über den Preis gestritten, Lizenz pro Monat gegen einmaliges Projektbudget, und am Ende gewinnt die Zahl, die im ersten Jahr kleiner aussieht. Das ist der teuerste Denkfehler in der ganzen Digitalisierung des Mittelstands. Denn die Frage „SaaS oder Individualsoftware?" ist keine Kostenfrage. Sie ist die Frage, welche Prozesse dich von deinem Wettbewerb unterscheiden und welche einfach nur laufen müssen.

Das Worst-Case-Szenario kennt jeder, der schon einmal danebengelegen hat: Du bezahlst eine sechsstellige Eigenentwicklung, die am Ende exakt das nachbaut, was es als Standard-Abo für 49 Euro im Monat gegeben hätte. Oder du sitzt zwei Jahre später in einem gekauften System fest, das grob 80 Prozent der Arbeit gut macht und die entscheidenden 20 Prozent gar nicht. Wer die richtige Achse kennt, trifft die Entscheidung in zwanzig Minuten. Wer sie nicht kennt, zahlt für den Irrtum jahrelang.

Hier ist die Achse, auf der du wirklich entscheiden solltest, eine Matrix zum Durchgehen, und der dritte Weg, den fast jeder übersieht und der meistens der richtige ist.

Warum der Preisvergleich in die Irre führt

Standardsoftware als SaaS kostet im ersten Jahr fast immer weniger. Du buchst, du loggst dich ein, du zahlst pro Nutzer und Monat. Eine Individualentwicklung verlangt vorab ein Projektbudget, bevor überhaupt etwas läuft. Auf den ersten Blick ist der Fall klar. Genau hier kippen die meisten Rechnungen.

Was in der ersten Rechnung fehlt, ist alles, was nach dem Kaufmonat passiert. Bei SaaS skaliert der Preis mit jedem Nutzer, jeder dazugebuchten Funktion und jeder API-Anbindung, die du brauchst, um das System überhaupt in deine Landschaft zu integrieren. Rechne es einmal durch: Aus 49 Euro pro Nutzer und Monat werden mit 30 Mitarbeitern, zwei Pflicht-Integrationen und dem Enterprise-Tier, der die Schnittstellen erst freischaltet, schnell ein Vielfaches des Listenpreises. Die Zahl auf der Landingpage ist der Einstiegspreis, nicht der Betriebspreis.

Bei Individualsoftware kippt die Rechnung in die andere Richtung. Der größte Kostenblock ist nicht die Entwicklung, sondern die Wartung über die Jahre.

Die Softwaretechnik-Literatur beziffert den Anteil von Betrieb, Pflege und Weiterentwicklung seit Jahrzehnten übereinstimmend auf einen Großteil der Lebenszykluskosten. Die klassische Größenordnung, die in der Literatur immer wieder auftaucht, sind 60 bis 80 Prozent der Lebenszykluskosten — so bei George Stark (MITRE) im Journal CrossTalk, der sich dabei unter anderem auf die Untersuchung von Lientz und Swanson aus dem Jahr 1978 stützt. Robert Glass nennt in „Facts and Fallacies of Software Engineering" eine Spanne von 40 bis 80 Prozent bei einem Mittelwert von 60.

Ehrlich dazugesagt: Das sind alte Zahlen, eine belastbare aktuelle Messung dieser Kennzahl gibt es nicht. Als Größenordnung für die eigene Kalkulation taugen sie trotzdem, weil sich am Grundmuster nichts geändert hat. Die initiale Erstellung ist nur die Spitze. Wer eine Eigenentwicklung budgetiert und die laufende Wartung vergisst, baut sich eine Altlast auf, deren Sanierung später ein eigenes Projekt wird.

Kurz gesagt: SaaS hat niedrige Einstiegskosten und eine Kostenkurve, die mit deinem Wachstum steigt. Individualsoftware hat hohe Einstiegskosten und eine flachere Kurve, die aber nie auf null fällt.

Und die SaaS-Kurve ist seit 2025 unruhiger geworden: Im internationalen SaaS Management Index 2026 berichten 78 Prozent der befragten IT-Verantwortlichen von unerwarteten Zusatzkosten, die konkret an verbrauchsabhängigen oder KI-basierten Preismodellen hingen. 61 Prozent mussten deshalb Vorhaben streichen. Diese beiden Werte stammen aus einer Befragung von 218 IT-Verantwortlichen, die dem Index vom Januar 2026 zugrunde liegt.

Die Zahlen stammen aus einem stark US- und Enterprise-geprägten Panel eines Anbieters von SaaS-Management-Software, sind also weder neutral noch ein Mittelstandsbefund. Das Muster kennen wir aus Projekten trotzdem: Der Preis, auf dessen Basis du entschieden hast, ist selten der Preis, den du in Jahr drei zahlst.

Für den deutschen Mittelstand gibt es inzwischen eine neutralere Zahl. Der Bitkom Cloud Report 2026 (603 befragte Unternehmen ab 20 Beschäftigten, repräsentativ, Erhebung Frühjahr 2026) hält fest: 64 Prozent der cloudnutzenden Unternehmen sahen 2025 steigende Betriebskosten, 54 Prozent erwarten für 2026 weitere Steigerungen. Das ist der deutsche Normalfall, erhoben in Deutschland. Übersetzt auf deine Kalkulation: Wer SaaS mit einem stabilen Monatspreis rechnet, rechnet gegen die Erfahrung von zwei Dritteln des Marktes.

Zurück zu den beiden Kurven von oben: Wo sie sich schneiden, liegt der eigentliche Entscheidungspunkt. Mit dem Preis im ersten Monat hat er nichts zu tun.

Die eine Achse, die wirklich zählt: Differenzierung

Vergiss den Preis für einen Moment. Stell dir bei jedem Prozess, jeder Anwendung, jedem Modul nur eine Frage: Unterscheidet mich dieser Prozess von meinem Wettbewerb, oder muss er einfach nur zuverlässig funktionieren?

Deine Buchhaltung unterscheidet dich von niemandem. Dein Lohnabrechnungssystem auch nicht. Niemand kauft bei dir, weil deine Gehaltsabrechnung eleganter läuft. Solche Prozesse sind reine Hygiene: Sie müssen korrekt, gesetzeskonform und wartungsarm sein, mehr nicht. Für sie eine Eigenentwicklung zu bauen, ist verbranntes Geld. Hier gewinnt Standardsoftware immer.

Dann gibt es die Prozesse, die dein Geschäft tatsächlich ausmachen. Die spezielle Art, wie du Aufträge konfigurierst. Die Logik, mit der du Produktion, Lager und Versand verzahnst. Das Kundenportal, das deinen Service vom Rest der Branche abhebt. Diese Prozesse kannst du nicht von der Stange kaufen. Denn wenn du sie als Standardprodukt kaufen könntest, könnte dein Wettbewerb das auch, und der Vorteil wäre weg. Hier rechtfertigt sich Individualsoftware, weil sie etwas abbildet, das es als Produkt nicht gibt und nicht geben soll.

Das ist die Achse. Nicht „teuer oder günstig", sondern „differenzierend oder Hygiene". Alles andere ist nachgelagert.

Die Entscheidungsmatrix: SaaS, Hybrid oder Individualsoftware?

Kreuze die Differenzierungs-Achse mit dem Standardisierungsgrad eines Prozesses, also damit, wie gut der Markt diesen Prozess bereits in fertigen Produkten abbildet. Es entstehen vier Felder. Geh deine zentralen Anwendungen einmal durch und sortiere jede in eines davon.

Die beiden Ränder sind einfach. Oben links, wenig Differenzierung und viel Standard, kaufst du und hörst auf nachzudenken. Unten rechts, hohe Differenzierung und kein brauchbarer Standard, baust du, weil es nichts zu kaufen gibt. Das Geld verdienst oder verbrennst du in der Mitte.

Nimm die mittlere Zeile, das Branchen-ERP. Ein Maschinenbauer braucht 90 Prozent dessen, was ein Standard-ERP kann: Stammdaten, Bestellungen, Lager, Buchungslogik. Aber seine Angebotskalkulation für Sondermaschinen, mit hunderten Varianten und kundenspezifischen Aufschlägen, bildet kein Standard-ERP sauber ab.

Die falsche Reaktion ist, das ganze ERP zu ersetzen, nur um diese eine Funktion zu bekommen. Die teure Reaktion ist, das Standard-ERP so lange zu customizen, bis jedes Update zum Risiko wird. Die richtige Reaktion: Standard-ERP behalten, die Kalkulation als eigenes Modul daneben bauen, beide über eine Schnittstelle verbinden. Genau dieser Schnitt ist die Arbeit, um die es in diesem Artikel geht.

Der dritte Weg, den fast jeder übersieht

Die Frage wird fast immer als Entweder-oder gestellt: ganz Standard oder ganz Eigenbau. In der Praxis ist die beste Antwort für mittelständische Unternehmen meistens keine von beiden, sondern die Kombination. Du nimmst bewährte Standardsysteme für alles, was Hygiene ist, und entwickelst individuell nur dort, wo du dich unterscheidest. Verbunden wird das Ganze über APIs.

So sieht das konkret aus: Ein Unternehmen behält sein Standard-ERP und die DATEV-Anbindung für Buchhaltung und Stammdaten, weil daran nichts zu differenzieren ist. Den Produktkonfigurator, der den eigentlichen Vertriebsvorteil ausmacht, baut es selbst. Eine schlanke Integrations-Schicht hält beide Welten synchron, sodass eine Bestellung aus dem Konfigurator ohne manuelles Nachtippen im ERP landet. Standard, wo Standard reicht. Eigenbau, wo es zählt.

Dieser Ansatz hat in den letzten Jahren einen Namen bekommen: Composable Architecture. Statt einer monolithischen Allzwecksoftware, die alles ein bisschen kann, setzt du einen Verbund aus spezialisierten Komponenten zusammen. Das Bindeglied ist eine saubere Systemarchitektur mit klar definierten Schnittstellen. Ohne die wird aus dem Verbund schnell ein Integrations-Albtraum, in dem jedes System mit jedem über eine eigene Brücke spricht und niemand mehr weiß, welche Daten wo führend sind.

Der Vorteil ist handfest. Du zahlst keine Eigenentwicklung für Buchhaltung, die niemanden interessiert. Du sitzt nicht in einem Standard-ERP fest, das deinen Kernprozess nicht abbilden kann. Und wenn ein Standardbaustein irgendwann nicht mehr passt, tauschst du ihn aus, ohne das ganze System neu zu bauen. Der Preis dafür ist Disziplin bei den Schnittstellen. Die Integration ist der Teil, an dem solche Projekte scheitern, wenn man sie unterschätzt.

Data Act: was sich am Lock-in-Argument 2027 ändert

Ein Argument in dieser Debatte hat ein Ablaufdatum bekommen. Der klassische Vendor Lock-in, kurz: „aus dem SaaS kommst du nie wieder raus", stimmte lange auch deshalb, weil der Ausstieg Geld kostete: Exit-Gebühren, Egress-Kosten für den Datenabzug, Migrationsaufwand beim Anbieter.

Der EU Data Act räumt einen Teil davon ab. Seine allgemeinen Pflichten gelten seit dem 12. September 2025; die eigentliche Zäsur kommt am 12. Januar 2027: Ab dann dürfen Anbieter von Cloud- und Datenverarbeitungsdiensten (IaaS, PaaS und SaaS) für den Wechsel zu einem anderen Anbieter keine Wechselentgelte mehr verlangen. In der Übergangszeit bis dahin dürfen sie nur noch die tatsächlichen direkten Kosten weiterreichen, nicht mehr frei kalkulieren. Die Pflicht trifft jeden Anbieter mit EU-Kunden, auch die US-Hyperscaler.

Wie groß der Rest der Hürde ist, zeigt derselbe Bitkom Cloud Report 2026: Lock-in-Effekte sind mit 59 Prozent die meistgenannte Wechselbarriere unter den cloudnutzenden Unternehmen — vor fehlendem strategischem Bedarf (49 Prozent) sowie personellem Aufwand und Anwendungskomplexität (je 45 Prozent). Und 43 Prozent sagen, für ihre Anforderungen gebe es derzeit gar keine gleichwertige europäische Alternative zu den US-Hyperscalern. Der Data Act senkt die Rechnung. Gegen Migrationsaufwand und fehlende europäische Alternativen hilft er nicht.

Was das für die Entscheidung heißt, ist nüchterner, als es klingt. Die vertragliche Wechselhürde sinkt, die technische bleibt. Wer seine Kernprozesse in die proprietären Datenmodelle und Automatisierungen eines Anbieters gegossen hat, kommt auch ohne Ausstiegsgebühr nicht schnell heraus. Der Data Act macht den Wechsel billiger, nicht einfach. Für die Praxis lohnt trotzdem eine konkrete Frage an jeden SaaS-Anbieter im Auswahlprozess: Wie sieht dein Exit-Pfad ab Januar 2027 aus, in welchem Format bekomme ich meine Daten, und was davon steht im Vertrag?

Ein Detail kann sich noch verschieben. Im Rahmen des Digital Omnibus liegt ein Änderungsvorschlag zum Data Act auf dem Tisch, der Anfang September 2026 noch nicht verabschiedet ist. Er würde proportionale Vertragsstrafen bei vorzeitiger Kündigung laufzeitgebundener Verträge ausdrücklich erlauben und zwei eng gefasste Bestandsschutz-Ausnahmen einführen — für Altverträge von vor dem 12. September 2025 und für kleinere Anbieter außerhalb der Infrastrukturdienste.

Am Stichtag 12. Januar 2027 und am Kern des Artikel 29, dem Entgeltverbot, ändert der Entwurf nach derzeitigem Stand nichts; offen ist nur die Reichweite einzelner Absätze bei Altverträgen. Für dich heißt das: Auf den Januar 2027 kannst du planen, auf die Details noch nicht. Und nicht zu verwechseln mit dem KI-Omnibus, der seit dem 27. Juli 2026 in Kraft ist — das sind zwei verschiedene Pakete.

Fünf Fragen, bevor du entscheidest

Bevor du dich für SaaS, Individualsoftware oder den Hybrid entscheidest, beantworte diese fünf Fragen ehrlich. Sie fangen die Fehler ab, die später teuer werden.

Wie nah ist der Standard an deinem realen Prozess? Deckt ein verfügbares Produkt deinen Ablauf zu deutlich über vier Fünfteln ab, kauf es und passe deinen Prozess an die fehlenden Stellen an. Das ist billiger als jede Eigenentwicklung. Klafft die Lücke dagegen breit auf, wird Customizing am Standard schnell teurer und fragiler als ein gezielter Eigenbau. Der Fehler, den du vermeiden willst: ein Standardprodukt so lange verbiegen, bis es teurer ist als eine saubere Eigenentwicklung und trotzdem nicht passt.

Wem gehören deine Daten und dein Prozess? Bei reiner SaaS liegen deine Daten beim Anbieter (was der Data Act ab 2027 vertraglich entschärft, nicht technisch), und du folgst seiner Roadmap. Bei einem Hygiene-Prozess ist das völlig in Ordnung. Bei deinem Kernprozess solltest du dir sehr genau überlegen, ob du dessen Zukunft an die Produktentscheidungen eines Dritten koppeln willst.

Wie schnell musst du dich verändern können? Standardsoftware ändert sich im Takt des Anbieters. Wenn dein Markt dich zwingt, einen Prozess in sechs Wochen umzubauen, der Anbieter aber zwei Releases pro Jahr fährt, hast du ein Problem, das kein Preisvergleich auffängt.

Was kostet es über fünf Jahre, nicht über eins? Rechne SaaS mit realistischem Nutzer- und Funktionswachstum durch und Individualsoftware mit der laufenden Wartung. Erst diese Kurve über die Jahre — die Total Cost of Ownership — sagt dir, was wirklich günstiger ist, nicht der Preis im ersten Monat.

Und was ist mit KI in der Entwicklung? Das Argument, KI-gestützte Entwicklung mache Eigenbau pauschal billig, hält der Prüfung nicht stand. Der DORA-Report 2025 beschreibt KI als Verstärker: Sie hebt vorhandene organisatorische Stärken und legt vorhandene Schwächen offener. Der Ertrag kommt nicht aus dem Werkzeug, sondern aus Plattformqualität, klaren Abläufen und einem Team, das weiß, was es baut. Übersetzt auf Build vs. Buy: KI verschiebt die Rechnung, sie kippt sie nicht.

Noch relevanter ist eine Zahl, die der DORA-ROI-Report vom Frühjahr 2026 aufgreift und InfoQ ausgewertet hat: Eine Untersuchung von Stanfords Software-Engineering-Productivity-Programm misst 35 bis 40 Prozent Produktivitätsgewinn bei einfachen Neuentwicklungen auf der grünen Wiese — bei komplexem Bestandscode dagegen 10 Prozent oder weniger. Genau dort, wo bei einer Eigenentwicklung über die Jahre der Aufwand entsteht, hilft KI also am wenigsten. Wer ohne Betriebskonzept und ohne Ownership entwickelt, baut mit KI nur schneller eine Altlast.

Was wir empfehlen

Unsere Haltung ist klar und sie ist keine Verkaufslogik: Kaufe alles, was dich nicht unterscheidet, und entwickle nur das, was dich unterscheidet. In den allermeisten Mittelstandsprojekten heißt das in der Praxis ein Hybrid. Standardsysteme als stabiler Unterbau, gezielte Individualentwicklung für die zwei, drei Prozesse, die dein Geschäft tatsächlich tragen, sauber über APIs verbunden.

Wer mit einer reinen „alles selbst bauen"-Strategie startet, zahlt für das Nachbauen von Commodity-Funktionen und bindet sich Wartungslast ans Bein, die nichts zur Differenzierung beiträgt. Wer umgekehrt sein ganzes Geschäft in ein einziges Standardprodukt presst, verliert irgendwann genau den Prozess, der ihn besonders macht.

Die eigentliche Arbeit steckt im Schnitt dazwischen, und der ist weder trivial noch beliebig. Er beginnt damit, jeden zentralen Prozess ehrlich auf der Differenzierungs-Achse einzuordnen, statt aus Bequemlichkeit alles in einen Topf zu werfen. Er verlangt eine klare Entscheidung, welches System für welche Daten führend ist, bevor die erste Schnittstelle gebaut wird.

Und er steht und fällt mit der Disziplin, einen gekauften Standard nicht doch wieder zu verbiegen, sobald er an einer Stelle zwickt. Wer diesen Schnitt sauber zieht, hat ein System, das mitwächst. Wer ihn schludert, hat in drei Jahren genau die Altlast, die er vermeiden wollte.

Wenn du vor genau dieser Entscheidung stehst und sie auf der Differenzierungs-Achse statt auf der Preis-Achse treffen willst, lohnt sich ein Gespräch über individuelle Softwareentwicklung. Nicht, um dir etwas zu bauen, das es als Standard gibt, sondern um den Schnitt zwischen Kaufen und Bauen für deinen konkreten Fall richtig zu legen. Und wenn die Altlast schon da ist, ein gewachsenes System, das niemand mehr anfassen will, ist deren Modernisierung der eigentliche erste Schritt, bevor überhaupt über neue Software geredet wird.

Die Entscheidung SaaS vs. Individualsoftware ist am Ende keine Frage des Budgets. Sie ist die Frage, welche Teile deines Unternehmens austauschbar sind und welche nicht. Beantworte die zuerst. Der Preis sortiert sich danach von selbst.

Häufige Fragen zu SaaS und Individualsoftware

Was ist der Unterschied zwischen SaaS und Individualsoftware?

SaaS ist fertige Standardsoftware, die du als Abo mietest und dir mit anderen Kunden teilst — der Anbieter betreibt und entwickelt sie weiter. Individualsoftware ist eine Eigenentwicklung, die exakt deinen Prozess abbildet und dir gehört. SaaS punktet bei Hygiene-Prozessen, die Eigenentwicklung dort, wo du dich vom Wettbewerb unterscheidest.

Wann lohnt sich eine Individualsoftware-Eigenentwicklung?

Eine Eigenentwicklung lohnt sich, wenn ein Prozess dich vom Wettbewerb abhebt und kein Standardprodukt ihn sauber abbildet — etwa Konfigurator, Pricing-Logik oder ein Kundenportal. Für austauschbare Prozesse wie Buchhaltung oder Lohn bleibt Standard-SaaS günstiger. Entscheide entlang der Differenzierung, nicht über den Monatspreis.

Was kostet Individualsoftware im Vergleich zu SaaS?

SaaS hat niedrige Einstiegskosten, deren Kurve mit Nutzern, Funktionen und Integrationen steigt. Individualsoftware verlangt ein Projektbudget vorab; der größere Kostenblock ist die laufende Wartung über die Jahre. Rechne beide Optionen über fünf Jahre durch — erst diese Gesamtkosten zeigen, was wirklich günstiger ist.

Komme ich aus einem SaaS wieder raus?

Vertraglich wird es einfacher: Ab dem 12. Januar 2027 dürfen Cloud- und SaaS-Anbieter nach dem EU Data Act keine Wechselentgelte mehr verlangen. Technisch bleibt der Aufwand aber bestehen — je tiefer deine Prozesse in den proprietären Datenmodellen eines Anbieters stecken, desto länger dauert die Migration. Frage schon bei der Auswahl nach dem Exit-Pfad, dem Exportformat und dem, was davon im Vertrag steht.