Individualsoftware: Wann sie sich rechnet – und wann Standardsoftware die bessere Entscheidung ist

Vorab, weil daran die meisten Make-or-Buy-Entscheidungen scheitern: nicht an der Technik, sondern an der Fragestellung. Wer fragt «Was ist billiger?», vergleicht einen einmaligen Entwicklungspreis mit einer monatlichen Lizenzgebühr. Die Antwort ist zwangsläufig schief. Die Frage, die trägt, lautet anders: Welcher deiner Prozesse erklärt deine Marge, und welcher ist reine Verwaltung? Den einen baust du selbst. Den anderen kaufst du und fasst ihn nie wieder an.

Dazu kommt eine Verschiebung, die in fast keinem Vergleichsartikel auftaucht: Die Kostenseite von Standardsoftware ist nicht mehr stabil. Gartner-Analyst Mike Tucciarone berichtet, dass die Abonnementpreise mehrerer großer SaaS-Anbieter im laufenden Jahr um 10 bis 20 Prozent gestiegen sind. Gleichzeitig prognostiziert Gartner das Wachstum der IT-Budgets auf 2,8 Prozent (Gartner-Aussagen, zitiert in CIO.com, 2025). Der Vergleich «einmalige Entwicklung gegen laufende Lizenz» fällt heute anders aus als vor fünf Jahren, und zwar in beide Richtungen: je nachdem, wie viele Menschen die Software benutzen.

Individualsoftware ist Software, die für einen bestimmten Auftraggeber und dessen konkrete Prozesse entwickelt wird, statt für einen anonymen Markt. Sie wird nicht lizenziert, sondern beauftragt. Ihr Funktionsumfang ergibt sich aus den Anforderungen genau einer Organisation, und die Nutzungsrechte werden vertraglich geregelt statt über AGB zugeteilt.

Ebenso wichtig ist, was Individualsoftware nicht ist. Sie ist nicht dasselbe wie das Customizing einer Standardlösung: Dort bleibt der Hersteller Eigentümer des Produkts, und du trägst das Upgrade-Risiko deiner Anpassungen. Sie ist auch nicht identisch mit Eigenentwicklung im eigenen Team. Laut techconsult vergeben 44 Prozent der befragten Unternehmen die Entwicklung an Dienstleister, 22 Prozent entwickeln ausschließlich intern, der Rest fährt eine Mischform (techconsult, 2021, n = 201 IT- und Softwareentscheider, im Auftrag des Individualsoftware-Anbieters Dr. Eckhardt + Partner – eine auftraggeberfinanzierte Erhebung, die man entsprechend lesen sollte). Und ein Großprojekt ist sie erst recht nicht, jedenfalls nicht am Anfang: Der kleinste sinnvolle Schnitt ist ein einzelner Prozess, kein Systemersatz.

Zur Orientierung, bevor es an die Kriterien geht: Die gängigen Vergleichsartikel stellen einen Zweikampf dar. In der Praxis stehen vier Optionen zur Wahl. Die meisten Fehlentscheidungen entstehen, weil die mittleren beiden übersprungen werden.

Du kaufst ein fertiges Produkt und passt deinen Prozess an die Software an. Das ist die schnellste und fast immer günstigste Option, solange du die Anpassung deines Prozesses wirklich akzeptierst. Sie kippt in dem Moment, in dem die Belegschaft anfängt, die Lücken mit Excel-Listen, E-Mail-Ketten und Zuruf zu schließen. Diese Schattenprozesse sind die eigentlichen Kosten. Sie stehen in keiner Rechnung.

Parametrisierung, eigene Felder, Workflows im Regelwerk des Herstellers, im nächsten Schritt Erweiterungen im Code des Produkts. Konfiguration innerhalb des vorgesehenen Rahmens ist unproblematisch. Customizing im engeren Sinn, also Eingriffe in den Standard, verschiebt das Upgrade-Risiko zu dir: Jede Produktversion des Herstellers wird zu deinem Testprojekt. Die Option kippt, wenn die Anpassungen ein eigenes Release-Management brauchen. Dann zahlst du Lizenz und Entwicklung gleichzeitig.

Du baust Anwendungslogik in einer Plattform zusammen, ohne klassische Softwareentwicklung. Für interne Formular- und Freigabeprozesse mit zwei- statt dreistelliger Nutzerzahl ist das häufig die wirtschaftlichste Wahl, und wir empfehlen sie in solchen Fällen aktiv. Sie kippt an drei Stellen: bei komplexer Datenlogik, bei hoher Nutzerzahl, weil die Lizenzierung fast immer nutzerbasiert ist, und beim Ausstieg, weil der gebaute Prozess ohne die Plattform nicht lauffähig ist. Du tauschst Entwicklungsaufwand gegen eine sehr enge Plattformbindung. Ein legitimer Handel, solange du weißt, dass du ihn eingehst.

Du beauftragst die Entwicklung genau der Anwendung, die dein Prozess braucht, auf einem verbreiteten Technologie-Stack. Die Investition ist am Anfang am höchsten und wächst danach nicht mit der Nutzerzahl. Sie kippt, wenn der Prozess unklar ist, wenn niemand intern die fachliche Verantwortung übernimmt oder wenn der Prozess ohnehin bald abgelöst wird. Merke: Jede der vier Optionen hat einen Kipppunkt. Wer ihn nicht benennen kann, hat die Option nicht verstanden.

Vorteile-Nachteile-Listen helfen niemandem, weil sie keine Gewichtung haben. Hilfreicher ist ein anderes Vorgehen: Geh jedes Kriterium einzeln durch und notiere, welche der vier Optionen es nach vorne bringt. Zeigen fünf von sieben Kriterien in dieselbe Richtung, ist die Entscheidung gefallen.

Differenzierungsrelevanz des Prozesses. Verdienst du Geld damit, dass du diesen Prozess anders machst als der Wettbewerb? Ja: Individualentwicklung. Nein: Standard, ohne Diskussion. Dieses Kriterium schlägt alle anderen.

Prozessindividualität. Wie viele deiner Prozessschritte laufen außerhalb dessen, was der Standard vorsieht? Bis etwa ein Zehntel: Standard kaufen und Prozess anpassen. Bis ein Viertel: Konfiguration, notfalls Low-Code für den Rest. Darüber: Individualentwicklung, weil Customizing ab hier teurer wird als der Neubau.

Integrationstiefe. Wie viele Systeme müssen konsistent gehalten werden: ERP, PIM, Shop, CRM, Warenwirtschaft, Versanddienstleister? Bei einem oder zwei gewinnt der Standard. Ab drei Systemen mit gegenseitigen Abhängigkeiten wird die Integrationsschicht selbst zum Produkt, und die baut dir kein Lizenzanbieter.

Änderungsfrequenz. Wie oft ändert sich der Prozess fachlich? Einmal im Jahr: Standard. Mehrmals pro Quartal: Individualentwicklung oder Low-Code, weil du sonst bei jeder Änderung in der Warteschlange des Herstellers hängst.

Nutzerzahl. Lizenzkosten skalieren linear mit den Köpfen, Entwicklungskosten nicht. Wenige Nutzer sprechen für Standard, viele für Eigenbau. Wo genau der Umschlagpunkt liegt, rechnen wir weiter unten durch.

Rechte am Ergebnis. Willst du den Prozess in fünf Jahren mit einem anderen Dienstleister weiterentwickeln können? Nur die Individualentwicklung gibt dir diese Option – und auch die nur, wenn der Vertrag stimmt.

Zeit bis produktiv. Standard: Tage bis Wochen. Konfiguration: Wochen bis Monate. Low-Code: Wochen. Individualentwicklung: bei sauberem Schnitt sechs bis zwölf Wochen bis zur ersten produktiven Version, bei einem Rundumschlag ein Jahr und mehr. Der Zeitfaktor ist kein Argument gegen Individualsoftware. Er ist ein Argument gegen zu große Erstschnitte.

Zur Einordnung: Die folgenden Werte sind unsere Praktikereinschätzung aus Mittelstandsprojekten, keine Studienergebnisse. Sie ersetzen keine Analyse. Sie sind aber ein besserer Prüfrahmen als «es kommt darauf an».

Schwelle 1: Lizenzkosten gegen Entwicklungsinvestition. Betragen deine jährlichen Lizenz- und Wartungsgebühren für ein System mehr als ein Drittel dessen, was eine eigene Lösung einmalig kosten würde, lohnt sich die Rechnung. Woran du es merkst: Der Verlängerungstermin löst intern jedes Jahr dieselbe Grundsatzdiskussion aus.

Schwelle 2: Anzahl synchron zu haltender Systeme. Ab drei Systemen, zwischen denen Daten in beide Richtungen fließen müssen, brauchst du ohnehin eine eigene Integrationsschicht. Woran du es merkst: Es gibt eine Person, deren halbe Stelle daraus besteht, Daten zwischen zwei Systemen abzugleichen.

Schwelle 3: Anteil der Prozessschritte außerhalb des Standards. Über einem Viertel wird Customizing teurer als Neubau, weil jede Anpassung dauerhaft gegen den Release-Zyklus des Herstellers verteidigt werden muss. Woran du es merkst: Es existiert eine Excel-Datei, ohne die der Prozess nicht funktioniert, und alle kennen sie.

Schwelle 4: Nutzerzahl. In unserem Modell weiter unten liegt der Umschlagpunkt bei nutzerbasierter SaaS-Lizenzierung bei rund 80 Nutzern; mit dem Lizenzpreis pro Kopf verschiebt er sich deutlich in beide Richtungen. Woran du es merkst: Du kaufst Lizenzen für Menschen, die das System zweimal im Monat öffnen. Wie groß dieser Posten wird, zeigt Zylo: Organisationen geben im Schnitt 21 Millionen US-Dollar jährlich für ungenutzte SaaS-Lizenzen aus, 14,2 Prozent mehr als im Vorjahr (Zylo, 2025 SaaS Management Index, Datenbasis: über 40 Millionen verwaltete Lizenzen und 40 Milliarden US-Dollar SaaS-Ausgaben, überwiegend große US-Unternehmen). Der absolute Betrag ist auf den Mittelstand nicht übertragbar, der Mechanismus schon.

Was jetzt folgt, ist eine offengelegte Modellrechnung, keine Studie. Alle Annahmen stehen im Text, damit du sie durch deine eigenen ersetzen kannst. Ausgangsfall: eine Fachanwendung für einen operativen Kernprozess, 80 Nutzer.

Lizenzpfad. 45 Euro pro Nutzer und Monat ergibt 43.200 Euro im ersten Jahr. Mit 10 Prozent jährlicher Preissteigerung summiert sich das über fünf Jahre auf rund 264.000 Euro. Dieser Aufschlag ist der untere Rand der 2025 von Gartner berichteten Spanne, hier über fünf Jahre fortgeschrieben: die angreifbarste Annahme dieses Modells. Dazu einmalig 40.000 Euro für Einführung, Datenmigration und Konfiguration. Gesamt: rund 304.000 Euro.

Entwicklungspfad. 150.000 Euro Erstinvestition für eine ausgebaute Fachanwendung. Für die Wartung nutzen wir den stabilsten Erfahrungswert der Software-Engineering-Literatur: Wartung verbraucht 40 bis 80 Prozent der Gesamtkosten einer Software, im Mittel 60 Prozent (Robert L. Glass, Facts and Fallacies of Software Engineering, 2002). Auf einen zehnjährigen Lebenszyklus verteilt entspricht das etwa 15 Prozent der Erstinvestition pro Jahr, also rund 22.500 Euro. Plus 6.000 Euro Betrieb und Hosting jährlich. Über fünf Jahre: rund 293.000 Euro.

Das Ergebnis ist bewusst unspektakulär: Bei 80 Nutzern ist es ein Patt. Die Kostenfrage entscheidet hier gar nichts. Entscheiden müssen Prozessindividualität, Integrationstiefe und Rechte. Interessant wird die Rechnung erst an den Rändern: Bei 25 Nutzern kostet der Lizenzpfad im gleichen Modell rund 122.000 Euro und gewinnt deutlich. Bei 250 Nutzern liegt er bei rund 864.000 Euro, während der Entwicklungspfad bei 293.000 Euro bleibt. Software wird nicht pro Kopf teurer.

Zwei Posten fehlen auf der Lizenzseite in fast jeder internen Kalkulation. Erstens die ungenutzten Lizenzen, deren Größenordnung oben steht: Bezahlt wird pro Kopf, genutzt wird pro Bedarf. Zweitens die Preismodelle: 66,5 Prozent der von Zylo befragten IT-Verantwortlichen berichten über unerwartete SaaS-Kosten durch verbrauchsbasierte oder KI-gestützte Preismodelle (Zylo, 2025 SaaS Management Index). Der Umschlagpunkt ist kein Naturgesetz. Er hängt an drei Variablen: Nutzerzahl, Lizenzpreisentwicklung und Änderungsfrequenz.

Zur Ehrlichkeit gehört die Gegenrichtung: Es gibt Kategorien, in denen wir grundsätzlich von Individualentwicklung abraten, obwohl wir davon leben. Buchhaltung und Rechnungswesen. Lohn- und Gehaltsabrechnung. Zeiterfassung. E-Mail und Kollaboration. Standard-CRM ohne echte Prozessbesonderheit. Alles, was zertifizierungs- oder auditpflichtig ist und wofür es zertifizierte Produkte gibt. In diesen Feldern kaufst du mit dem Produkt auch die regulatorische Pflege ein, und die ist mehr wert als jede Passgenauigkeit.

Unabhängig von der Kategorie raten wir außerdem ab, wenn eine dieser vier Bedingungen zutrifft. Der Prozess ist fachlich nicht beschrieben und niemand kann ihn in einer Stunde am Whiteboard erklären. Es gibt keinen internen Verantwortlichen, der Entscheidungen treffen darf. Das Budget reicht nur für die Hälfte des ersten sinnvollen Schnitts: Dann baust du ein Fragment, das niemand benutzt. Oder der Prozess soll im Rahmen eines anderen Vorhabens in den nächsten anderthalb Jahren ohnehin abgelöst werden.

Wenn du noch nicht sicher bist, welche Gattung von Anwendung du überhaupt brauchst, klärt das der Weichen-Ratgeber Website, Web-App oder Portal schneller als jede Make-or-Buy-Analyse.

Branchenlisten helfen bei der Einordnung wenig, weil sich Individualsoftware nicht nach Branche sortiert, sondern nach Prozesstyp. Diese sechs Fälle sehen wir am häufigsten.

Konfigurator und Angebotsstrecke. Variantenreiche Produkte, Preislogik mit Ausnahmen, Angebot in Minuten statt Tagen. Der klassische Fall, in dem kein Standardprodukt die Regellogik abbildet, weil die Regeln dein Geschäft sind.

Kundenportal. Auftragsstatus, Dokumente, Reklamationen, Nachbestellung: alles, was deine Kunden sonst per Telefon beim Innendienst erfragen. Kosten- und Abgrenzungsfragen dazu klären wir gesondert unter Kundenportal entwickeln lassen und im Vergleich wann Zendesk reicht und wann es teuer wird.

Auftragsdurchlauf über Systemgrenzen. Ein Vorgang, der durch vier Systeme und drei Abteilungen läuft und heute per E-Mail zusammengehalten wird.

Datendrehscheibe zwischen ERP, PIM und Shop. Produktdaten, die an drei Stellen gepflegt werden und an keiner stimmen. Wann sich hier ein eigenes System rechnet und wann ein Standard-PIM reicht, steht in Build vs. Buy: wann sich ein eigenes PIM rechnet; die Umsetzungsperspektive findest du unter PIM-Agentur.

Prüf- und Freigabeworkflow. Mehrstufige Freigaben mit Fristen, Vertretungsregeln und Nachweispflicht. Häufig der Fall, in dem Low-Code die richtige Antwort ist, solange die Nutzerzahl zweistellig bleibt.

Reporting auf uneinheitlichen Datenquellen. Kennzahlen, die aus mehreren Systemen zusammengesetzt werden müssen, weil kein System die Wahrheit allein besitzt.

Ein Sonderfall überlagert alle sechs: Wenn die abzulösende Anwendung ein gewachsenes Altsystem ist, ist die Make-or-Buy-Frage der zweite Schritt. Der erste ist der Schnitt der Ablösung, dazu mehr unter Software-Modernisierung. Dass dieser Fall verbreitet ist, zeigt eine internationale Befragung von GLG Insights im Auftrag von Slalom: 61 Prozent der Unternehmen betreiben die Mehrheit ihrer Geschäftsanwendungen weiterhin auf veralteten Plattformen (GLG Insights für Slalom, August 2025, n = 2.000 in fünf Ländern, deutsche Teilstichprobe 161; befragt wurden ausschließlich Unternehmen, die eine KI-Initiative bereits gestartet haben oder gerade starten).

Das ist der Abschnitt, den kein rankender Vergleichsartikel liefert, obwohl er für CIO und CFO gemeinsam relevant ist. Zwei Punkte solltest du kennen, bevor du unterschreibst. Beides ersetzt keine Rechts- oder Steuerberatung. Es sagt dir, wonach du fragen musst.

Rechte. Das Urheberrecht an Software ist in Deutschland nicht übertragbar (§ 29 Abs. 1 UrhG); eingeräumt werden können nur Nutzungsrechte. Fehlt eine ausdrückliche Regelung, greift die Zweckübertragungsregel des § 31 Abs. 5 UrhG: Der Auftraggeber erhält im Zweifel nur die Rechte, die der Vertragszweck zwingend erfordert. Das ist typischerweise ein einfaches, nicht ausschließliches Nutzungsrecht, keine Exklusivität und kein Anspruch auf Herausgabe des Quellcodes. Ein Bearbeitungsrecht über das hinaus, was § 69d UrhG für die bestimmungsgemäße Benutzung und die Fehlerbeseitigung ohnehin erlaubt, ist ebenfalls nicht selbstverständlich. Wer den Satz «der Quellcode gehört uns» für gegeben hält, hat ihn meist nicht im Vertrag stehen (Darstellung nach IT-Recht-Kanzlei).

Risiko und Bilanz. Ob du einen Werkvertrag oder einen Dienstvertrag schließt, entscheidet zivilrechtlich über das Wesentliche: Beim Werkvertrag schuldet der Dienstleister ein Ergebnis, trägt das Herstellungsrisiko und haftet nach Abnahme für Mängel. Beim Dienstvertrag kaufst du Arbeitszeit, und das Ergebnisrisiko bleibt bei dir. Bilanziell wirkt die Vertragsgestaltung nur mittelbar. Aktivierungsfähig ist Software, wenn sie entgeltlich erworben wurde, wenn also die Verfügungsmacht von einem Dritten übergeht und eine objektiv feststellbare Gegenleistung vorliegt. Eine Werkvertragskonstellation erfüllt das eher als eine reine Zeitabrechnung, die auf Selbsterstellung hinausläuft. Für selbst geschaffene immaterielle Vermögensgegenstände des Anlagevermögens besteht handelsrechtlich ein Aktivierungswahlrecht (§ 248 Abs. 2 HGB), steuerrechtlich dagegen ein Aktivierungsverbot (§ 5 Abs. 2 EStG). Sprich das mit deiner Steuerberatung durch, bevor der Vertragstyp aus Bequemlichkeit gewählt wird (Darstellung nach Haufe).

Drei Klauseln gehören in jeden Individualsoftware-Vertrag: ausschließliches, zeitlich und räumlich unbeschränktes Nutzungsrecht einschließlich Bearbeitungsrecht; laufende Herausgabe des Quellcodes in dein eigenes Repository, nicht erst bei Projektende; und eine Ausstiegsregelung mit Übergabedokumentation. Wer bei einem dieser drei Punkte ausweicht, hat einen Grund dafür. Welchen technischen Rahmen wir setzen, steht unter TypeScript-Agentur.

Zum Abschluss die Muster, die wir am häufigsten sehen: erst die Fehler bei der Vergabe, dann die im Betrieb.

Das 80-seitige Lastenheft vor dem ersten Prototyp. Anforderungen, die nie an einem laufenden System validiert wurden, sind Vermutungen in Vertragsform. Schreib zwanzig Seiten, bau sechs Wochen, schreib die nächsten zwanzig.

Festpreis auf unscharfem Umfang. Ein Festpreis ist gut, wenn der Umfang scharf ist. Ist er es nicht, zahlst du den Risikoaufschlag des Anbieters und bekommst zusätzlich einen Anbieter, der jede Änderung abwehren muss.

Der zu große Erstschnitt. McKinsey und die University of Oxford haben über 5.400 IT-Projekte mit einem Anfangsvolumen ab 15 Millionen US-Dollar ausgewertet: Sie lagen im Schnitt 45 Prozent über Budget, 7 Prozent über Zeit und lieferten 56 Prozent weniger Wert als geplant (McKinsey/University of Oxford, 2012). Diese Zahlen gelten für Großprojekte, nicht für Mittelstandsvorhaben. Genau das ist der Punkt: Sie sind das stärkste Argument dafür, den ersten Schnitt klein zu halten.

Niemand, der fachlich entscheiden darf. Wer keine Person benennt, die fachliche Entscheidungen ohne Gremium treffen darf, kauft Verzögerung. Das ist in unserer Erfahrung der zuverlässigste Prädiktor für ein Projekt, das nicht fertig wird.

Kein Betriebskonzept. Wer zahlt Hosting, Überwachung, Sicherheitsupdates und Unterstützung ab Tag eins nach dem Go-Live? Wird das erst nach dem Start geklärt, verhandelst du aus der schwächeren Position.

Die Annahme, man mache es intern. Bitkom beziffert die Lücke auf 109.000 fehlende IT-Fachkräfte in Deutschland; die durchschnittliche Besetzungsdauer einer freien IT-Stelle liegt bei 7,7 Monaten (Bitkom, 07.08.2025, n = 855 Unternehmen). Wer intern aufbaut, verliert gut zwei Quartale allein für die Stellenbesetzung, bevor die erste Zeile Code entsteht. Das spricht nicht gegen internen Aufbau. Es spricht gegen ihn als Terminplan.

Der Betrieb steht in kaum einem Angebot. Rechne mit einem laufenden Aufwand von 10 bis 20 Prozent der Erstinvestition pro Jahr. Das ist unsere Erfahrungsspanne, und sie deckt sich mit dem Bild, das der 60-Prozent-Wartungsanteil bei Glass über einen realistischen Lebenszyklus ergibt. Darin enthalten sind Sicherheitsupdates, Abhängigkeits-Upgrades, Anpassungen an geänderte Schnittstellen Dritter und kleine fachliche Änderungen. Nicht enthalten sind neue Funktionsbereiche.

Der zweite ehrliche Punkt betrifft die Abhängigkeit vom Dienstleister. Der Vorwurf, Individualsoftware erzeuge eine dauerhafte Bindung, ist berechtigt, und er lässt sich vertraglich wie technisch begrenzen. Der Quellcode liegt in deinem Repository, nicht in unserem. Der Technologie-Stack ist verbreitet genug, dass ein anderer Anbieter ihn übernehmen kann, statt in einem Hausframework zu stecken. Architektur und Deployment sind dokumentiert, das Deployment selbst läuft ohne proprietäre Werkzeuge. Und die Abhängigkeit ist ohnehin nicht binär: Auch bei Standardsoftware hängst du an einem Hersteller, nur hast du dort keinen Einfluss auf Produktplanung, Preis und Abkündigung.

Bevor du mit einem Anbieter sprichst, lohnt sich eine Stunde interne Vorarbeit, die den ganzen Rest der Entscheidung trägt. Liste deine operativen Prozesse und sortiere sie nach Differenzierungsrelevanz: Was macht der Wettbewerb genauso, was machst nur du so? Stell für die drei individuellsten Prozesse die jährlichen Lizenz- und Wartungskosten der heute genutzten Systeme neben eine grobe Entwicklungsschätzung. Skizziere, welche Systeme dabei Daten austauschen müssen. Notiere zuletzt, wo heute Excel-Dateien und E-Mail-Ketten den Prozess zusammenhalten. Das ist deine eigentliche Anforderungsliste.

Steht danach der Fall für eine eigene Lösung, ist der nächste sinnvolle Schritt kein Lastenheft, sondern ein geschnittenes erstes Release. Die 150.000 Euro aus der Modellrechnung sind die über Jahre ausgebaute Fachanwendung, nicht der Einstieg. Wie wir den Einstieg aufsetzen, steht auf unserer Seite zu Individualsoftware: MVP in sechs bis zwölf Wochen ab 8.000 Euro, Betrieb auf EU-Servern, Quellcode gehört dir.

Wenn du deinen Fall lieber in einer halben Stunde durchsprichst, statt ihn allein zu sortieren: Beratungsgespräch vereinbaren. Wir sagen dir auch, wenn Standardsoftware die bessere Entscheidung ist. Das ist häufiger der Fall, als es einem Anbieter lieb sein kann.