Build vs. Buy: Wann sich eigene Software wirklich lohnt

Die Entscheidung „selbst entwickeln oder fertige Software kaufen" wird in den meisten Mittelständlern als Kostenrechnung geführt. Ein paar Tabellen, Lizenzpreise gegen Stundensätze, Excel-Vergleich, fertig. Das Problem: Die Tabelle gibt fast immer die falsche Antwort, weil sie die falsche Frage stellt.

Die richtige Frage lautet nicht „was kostet weniger?", sondern „wo entsteht in unserem Unternehmen tatsächlich Mehrwert, und wo nicht?". Wer das ehrlich beantwortet, kommt zu klareren Entscheidungen als jede TCO-Rechnung sie liefern kann. Sie ist im Übrigen eine von mehreren Fragen, die vor jedem Softwareprojekt geklärt werden sollten.

Warum die Ausgangslage heute eine andere ist

Vor fünf Jahren war die Antwort fast immer dieselbe: Standardsoftware kaufen, SaaS-Abo abschließen, weiter im Tagesgeschäft. Aus gutem Grund. SaaS war günstiger im Einstieg, schneller einsatzbereit, und Eigenentwicklungen verlangten Entwicklungsteams und Projektbudgets, die im Mittelstand selten vorhanden waren.

Drei Verschiebungen haben dieses Bild aufgebrochen.

Erstens: SaaS wird systematisch teurer. Standardsoftware-Preise steigen aktuell etwa 4,5-mal schneller als die Inflation, einzelne Anbieter erhöhen ihre Preise um 20 bis 37 Prozent, oft begründet mit „KI-Funktionen", die kaum jemand abgefragt hat. Was heute 50.000 Euro Jahreslizenz kostet, kostet bei zwölf Prozent Steigerung pro Jahr nach fünf Jahren über 88.000 Euro. Das macht SaaS-Budgets zu einem schwer kalkulierbaren Posten in der mittelfristigen Planung.

Zweitens: Tool-Wildwuchs ist messbar geworden. Unternehmen nutzen im Schnitt etwa 106 SaaS-Anwendungen, kleinere Mittelständler immerhin 40 bis 100. Pro Mitarbeiter sind es im Schnitt 13 verschiedene Tools, fast doppelt so viele wie 2022. Rund die Hälfte der bezahlten Lizenzen wird nicht genutzt. Was in keiner dieser Statistiken auftaucht, aber jeden Tag Arbeitszeit kostet: die Brüche zwischen diesen Tools, die manuellen Übergaben, die Workarounds in Excel.

Drittens: Die Baukosten sind im unteren Bereich kollabiert. Das ist die Verschiebung, die am wenigsten verstanden wird. Wer Build vs. Buy noch mit den Zahlen von vor drei Jahren rechnet, geht von Entwicklungsprojekten über viele Monate und sechsstelligen Budgets aus. Für eine wachsende Klasse von internen Werkzeugen stimmt das nicht mehr. Ein durchdachtes internes Tool, das früher ein Projekt über ein halbes Jahr gewesen wäre, entsteht heute in wenigen Wochen. Damit konkurriert nicht mehr ein großes Projekt gegen ein günstiges Abo, sondern überschaubarer Entwicklungsaufwand gegen ein Abo, das jedes Jahr wiederkommt und teurer wird.

Diese drei Verschiebungen bedeuten nicht „Build ist jetzt immer richtig". Sie bedeuten: Die alte Faustregel „im Zweifel kaufen" trägt nicht mehr automatisch.

Vier Gründe, selbst zu bauen

Es gibt vier Situationen, in denen Eigenentwicklung heute die bessere Wahl ist. Zwei davon waren es schon immer. Zwei sind erst dadurch attraktiv geworden, dass die Baukosten gefallen sind.

Was schon immer für Build sprach

Erstens: Was Sie differenziert. Steckt in dem Prozess, den die Software unterstützt, Ihr eigener Mehrwert, Ihre eigene Arbeitsweise, Ihr eigenes Wissen? Dann ist eine Standardlösung fast immer ein Kompromiss, und individuell entwickelte Software der naheliegende Weg. Sie zwingt Ihre Arbeitsweise in die Logik eines Anbieters, der diese Logik für tausend andere Kunden gleichzeitig optimiert. Genau dort, wo Sie sich abheben sollten, machen Sie sich gleich. Das war noch nie eine Kostenfrage. Wer seinen Kernprozess von der Stange kauft, gibt seinen Vorsprung an der Kasse mit ab.

Zweitens: Was Souveränität und Datenhoheit erfordert. Wo liegen Ihre Daten, wer hat Zugriff, was passiert, wenn der Anbieter seine AGB ändert, sein Pricing umbaut oder verkauft wird? Bei US-Anbietern kommt der CLOUD Act hinzu: US-Behörden können auch auf Daten zugreifen, die in europäischen Rechenzentren liegen, solange der Anbieter US-amerikanisch ist. Für viele Bereiche ist das hinnehmbar. Für sensible Kundendaten oder Geschäftsgeheimnisse ist es ein Risiko, das mit einer eigenen Lösung auf EU-Hosting kalkulierbar wird. Ein eigenes System, in dem Ihre Kundendaten liegen statt verteilt über fremde Plattformen, ist kein Luxus, sondern eine bewusste Entscheidung darüber, wem Sie Ihre wichtigsten Informationen anvertrauen.

Was erst durch gesunkene Baukosten dazukam

Drittens: Was Sie nicht zufriedenstellt. Fast jedes Unternehmen kennt das eine Tool, mit dem niemand wirklich arbeiten will. Es passt nicht zum Prozess, also baut das Team Workarounds. Es kann das eine nicht, also gibt es eine zweite Anwendung daneben. Früher war das kein Grund zum Bauen, weil die Eigenentwicklung teurer gewesen wäre als das Ärgernis. Diese Rechnung verschiebt sich. Wenn der Aufwand, eine passende Lösung zu bauen, in Wochen statt Monaten gemessen wird, wird aus „damit leben wir halt" eine echte Alternative.

Viertens: Was Ihnen objektiv zu teuer wird. Seat-basiertes Pricing ist der Klassiker. Eine Lösung, die bei zehn Mitarbeitern günstig war, wird bei fünfzig zum spürbaren Kostenblock, ohne dass sie dafür mehr leistet. Hier lohnt eine echte Break-Even-Rechnung. Aber, und das ist wichtig, ehrlich gerechnet: Sie vergleichen nicht Lizenzkosten gegen Entwicklungskosten. Sie vergleichen Lizenzkosten gegen Entwicklung plus Betrieb plus Wartung plus die Verantwortung, die Sie damit übernehmen. Wenn die Lizenz pro Jahr mehr kostet als der laufende Aufwand für eine eigene Lösung, ist der Wechsel wirtschaftlich. Wenn nicht, bleiben Sie beim Abo. Das Kriterium ist nicht „SaaS ist teuer", sondern „SaaS ist teurer als die Summe dessen, was die Eigenlösung mich über ihre Lebensdauer kostet".

Wo Buy die richtige Antwort bleibt

Es gibt einen Bereich, in dem Eigenentwicklung fast nie sinnvoll ist, und er lässt sich präziser fassen als mit dem üblichen „Standardprozesse kauft man".

Die entscheidende Trennlinie ist nicht Commodity gegen Spezialfall. Sie ist: Wer macht die Regeln? Bei einem CRM bilden Sie Ihre eigenen Prozesse ab. Die Regeln kommen von Ihnen, Sie dürfen sie ändern, und wenn etwas nicht passt, tragen Sie die Konsequenzen selbst. Bei Lohnbuchhaltung, Finanzbuchhaltung oder allem, was tief in Steuer- und Sozialrecht hängt, ist das anders. Dort kommen die Regeln vom Gesetzgeber, sie ändern sich laufend, und ein Fehler ist keine Unannehmlichkeit, sondern ein rechtliches Problem.

Solche Software selbst zu bauen hieße, massives regulatorisches Domänenwissen nachzubauen und dauerhaft aktuell zu halten. Wer das ohne die entsprechenden Experten tut, baut sich ein Haftungsrisiko ins Haus. Hier zahlen Sie bei einem Standardanbieter nicht nur für Software, sondern dafür, dass jemand anderes die Verantwortung trägt, die Regeln korrekt umzusetzen und bei jeder Gesetzesänderung nachzuziehen. Das ist gut investiertes Geld.

Die Frage ist also nicht „können wir das selbst bauen?". Sie lautet: „Bestimmen wir die Regeln dieses Prozesses selbst, oder tut es jemand anderes?". Wo andere die Regeln machen und Fehler teuer werden, kaufen Sie. Sie sparen sich damit nicht nur Entwicklungsaufwand, sondern ein Risiko, das Sie ohnehin nicht tragen wollen.

Die ehrlichen Kosten einer Eigenentwicklung

An dieser Stelle muss ich ehrlich sein, auch wenn ich Software entwickle und das hier in eigener Sache schreibe: Dass die Entwicklung günstiger geworden ist, heißt nicht, dass Eigenentwicklung kostenlos ist. Das Problem war selten die erste Version. Das Problem sind die Kosten danach.

Eine erste Version deckt die typischen Abläufe ab. Realistisch sind das vielleicht 50 bis 60 Prozent des Gesamtaufwands. Der Rest verschwindet in Sonderfällen, in der Realität, dass Geschäftsprozesse nie so sauber sind wie die Spezifikation, und in allem, was produktionsreife Software ausmacht: Sicherheit, Berechtigungen, Protokollierung, Administration. Günstigere Entwicklung verschiebt diese Anteile, sie schafft sie nicht ab.

Dazu kommen Betrieb und Wartung. Updates, Sicherheitspatches, Anpassungen an neue Anforderungen, die nächste Datenbank- oder Framework-Version. Eine Eigenentwicklung ist kein einmaliges Projekt, sondern eine fortlaufende Verpflichtung. Wer das ausblendet, steht nach zwei Jahren vor einer unangenehmen Lage: Die Software läuft, aber niemand fühlt sich zuständig, niemand passt sie an. Aus dem strategischen Asset wird ein Klotz.

Das ist kein Argument gegen Eigenentwicklung. Es ist ein Argument dafür, von Anfang an zu klären, wer betreibt und wer langfristig pflegt. Genau hier entscheidet sich, ob aus einer guten Build-Entscheidung ein dauerhafter Vorteil wird oder eine Altlast.

Was KI wirklich verändert hat, und was nicht

Es kursiert die Erzählung, KI mache Eigenentwicklung „für jeden" möglich. Das stimmt so nicht, und der Unterschied ist entscheidend.

Auf der einen Seite steht das, was sich auf LinkedIn als „Vibe Coding" eingebürgert hat: Jemand ohne Entwicklungshintergrund beschreibt einer KI, was er will, und nimmt das Ergebnis, ohne es beurteilen zu können. Das funktioniert erstaunlich gut für Prototypen und Spielereien. Es bricht zuverlässig bei allem, worauf ein Unternehmen läuft, weil niemand die Entscheidungen geprüft hat, die unter der Oberfläche getroffen wurden: zur Architektur, zur Sicherheit, zur Frage, ob das System in zwei Jahren noch wartbar ist.

Auf der anderen Seite steht das, was man „Agentic Engineering" nennt: Ein erfahrener Entwickler dirigiert KI-Werkzeuge, prüft jede relevante Entscheidung und verantwortet das Ergebnis. Die KI beschleunigt, der Entwickler bleibt zuständig. Routineaufgaben, die früher Tage gekostet haben, sind in Stunden erledigt, aber jede Zeile durchläuft das Urteil von jemandem, der erkennt, wo ein generierter Vorschlag elegant aussieht und trotzdem falsch ist.

Der Unterschied ist nicht das Werkzeug. Beide nutzen dieselbe KI. Der Unterschied ist, wer die Verantwortung trägt und ob er sie tragen kann. Genau das ist der Grund, warum „günstig zu bauen" und „leichtfertig zu bauen" nicht dasselbe sind. Eine interne Lösung, die in wenigen Wochen entsteht und trotzdem trägt, ist kein zusammengeklicktes Tool. Sie ist das Ergebnis von Erfahrung, die durch moderne Werkzeuge schneller wirkt, nicht ersetzt wird.

Eine pragmatische Schlussfolgerung

Build vs. Buy ist keine ideologische Entscheidung und keine Bauchfrage. Es ist die nüchterne Auseinandersetzung mit einer simplen Unterscheidung: Wo schaffen unsere eigenen Prozesse Wert, wo sind sie austauschbar, und wo macht ein anderer die Regeln, an die wir uns ohnehin halten müssen?

Bauen Sie, was Sie differenziert. Bauen Sie, was Ihre Daten in Ihrer Hand hält. Bauen Sie, was Sie täglich ärgert oder mit jedem neuen Mitarbeiter teurer wird, wenn die Rechnung über die ganze Lebensdauer aufgeht. Kaufen Sie alles, wo Fehler rechtlich teuer werden und andere die Verantwortung übernehmen. Und blenden Sie nie aus, dass auch eine günstig gebaute Lösung gepflegt werden will.

Sie sind unsicher, in welche Kategorie Ihre Tools fallen?
Welche Anwendung verursacht jeden Tag Reibung, welcher Prozess zwängt sich in eine Standardlogik, die nicht zu Ihnen passt, und wo zahlen Sie pro Mitarbeiter für etwas, das Ihnen wenig zurückgibt?
Lassen Sie uns das gemeinsam durchgehen.
Ein ehrliches Gespräch, keine Verkaufsveranstaltung.

Buchen Sie ein unverbindliches Erstgespräch.