Build vs. Buy 2025: Das 100.000€-Projekt wird zum 25.000€-Projekt

Jedes mittelständische Unternehmen hat sie: diese eine Lösung, die eigentlich keine ist. Die Access-Datenbank aus 2008, die nur Herr Müller versteht. Das Spreadsheet mit 47 Tabs, das die halbe Logistik steuert. Der Prozess, der drei Systeme braucht, die nicht miteinander reden – und einen Menschen, der die Lücken füllt.

Und dann die Rechnung, die sich jedes Jahr wiederholt: Könnte man das nicht besser lösen?

Die Antwort war bisher meistens: Theoretisch ja. Praktisch nein. Standardsoftware passt nie wirklich. Sie zwingt uns, unsere gewachsenen Abläufe an ihre Logik anzupassen. Individualsoftware wäre die Alternative, aber die Zahlen sind ernüchternd: 100.000 Euro aufwärts, plus Wartung, plus das leise Unbehagen, ob der Dienstleister in drei Jahren noch existiert.

Also bleibt es beim Pragmatismus. Man arrangiert sich, optimiert hier und da, und nennt es eine bewusste Entscheidung. Dabei ist es oft eher ein Nicht-Entscheiden.

Die Zahlen kommen inzwischen von den CEOs selbst: Sundar Pichai erzählte Lex Fridman, dass 25% von Googles Code mittlerweile AI-assisted entsteht. Satya Nadella sprach bei Metas LlamaCon von 20-30% bei aktiven Microsoft-Projekten. Eine kontrollierte Studie von GitHub und MIT zeigte: Entwickler mit AI-Unterstützung waren 55,8% schneller bei der Implementierung eines HTTP-Servers.

Aber die Prozentzahlen sind nicht das Interessante.

Das Interessante ist: Das Projekt, das gestern 100.000 Euro gekostet hätte, kostet heute vielleicht 25.000.

Nicht weil Entwickler schneller tippen. Sondern weil sich verschoben hat, wofür man eigentlich bezahlt. Der repetitive Teil – Boilerplate-Code, Standard-Integrationen, Dokumentation – wird zunehmend automatisiert. Was bleibt, ist das, was immer schon der eigentliche Wert war: das genaue Verstehen eines Problems, das Übersetzen von Geschäftslogik in Systemlogik, das Wissen, welche Fragen überhaupt gestellt werden müssen.

Die alte Frage "Build or Buy?" war binär. Die neue Landschaft ist differenzierter.

Kaufen macht weiterhin Sinn für alles, was Commodity ist: Buchhaltung, E-Mail, die Grundfunktionen eines CRM. Auch für hochregulierte Bereiche, wo Zertifizierungen teuer erkauft werden müssen. Und für alles, was nicht wirklich differenziert.

Bauen lohnt sich plötzlich für Nischen, die vorher ökonomisch tot waren: für Prozesse, die den eigenen Wettbewerbsvorteil ausmachen; für Integrationen zwischen Systemen, die partout nicht miteinander reden wollen; für Automatisierungen, die bisher einen Menschen brauchten.

Und dann gibt es eine dritte Option, die oft übersehen wird: die Sidecar-Lösung. Eine schlanke Anwendung, die neben dem bestehenden System läuft, auf die vorhandenen Daten zugreift und sofort Mehrwert liefert – ohne das Kernsystem anzufassen. Kein großes Migrationsprojekt, kein Alles-oder-Nichts. Ein Anfang, der sich beweisen kann.

Es gibt gute Gründe für Vorsicht. Und es gibt Gründe, die sich gut anfühlen, aber bei genauerem Hinsehen weniger tragen.

Da ist die Verlustaversion: Die 25.000 Euro für ein Experiment fühlen sich wie ein Risiko an. Die 100.000 Euro pro Jahr, die durch ineffiziente Prozesse versickern, fühlen sich wie Normalität an – weil sie nie auf einer Rechnung stehen.

Da ist die Vertrautheit mit dem Chaos: Excel mag unübersichtlich sein, aber es ist unser Chaos. Wir können jede Zelle anfassen, auch wenn längst niemand mehr versteht, was die Formeln eigentlich tun.

Und da ist die Frage nach der Kompetenz: "Wir kennen unsere Prozesse am besten" – das stimmt. Aber daraus folgt nicht automatisch, dass wir sie auch am besten in Software übersetzen können. Das sind zwei verschiedene Fähigkeiten.

Vielleicht ist die spannendere Frage nicht mehr "Können wir uns das leisten?", sondern "Was kostet es uns eigentlich, es nicht zu tun?"

Wie viele Stunden fließen jede Woche in Workarounds? Wie oft bleiben Entscheidungen in der Schwebe, weil die Daten fehlen? Wie viel Wissen ist an einzelne Köpfe gebunden, die irgendwann nicht mehr da sein werden?

Die Build-vs-Buy-Gleichung hat sich verschoben. Nicht weil Technologie billiger geworden ist – das auch – sondern weil die Kosten für "genau das, was wir brauchen" dramatisch gesunken sind.

Wer das nur als Effizienz-Gewinn verbucht, übersieht das eigentliche Potenzial: die Möglichkeit, Dinge zu tun, die vorher schlicht nicht wirtschaftlich waren.

Welche Lösung, die eigentlich keine ist, gibt es bei euch? Welcher Prozess wartet seit Jahren auf eine bessere Alternative?

Manchmal lohnt es sich, die Rechnung neu aufzumachen.