Make or Buy 2.0. Was KI an dieser Frage verändert.

Teil 3: Make or Buy 2.0. Was KI an dieser Frage verändert.

In Teil 2 haben wir die Greenfield-Architektur skizziert – und sind dabei einer Frage bewusst ausgewichen: Wenn KI die Eigenentwicklung verbilligt, warum dann überhaupt noch Plattformen kaufen? Diesen Teil haben wir uns aufgehoben, weil er der unbequemste der Serie ist. Hier müssen wir gegen einen Hype anschreiben, von dem auch wir als Berater bequem profitieren könnten.

In jedem zweiten Geschäftsführer-Gespräch fällt derzeit derselbe Satz: „Mit KI bauen wir uns das doch einfach selbst.“ Gesagt wird er mit einer Mischung aus Begeisterung und Erleichterung – endlich raus aus der Lizenz-Abhängigkeit, endlich Software, die exakt zum eigenen Prozess passt. Wir verstehen den Reiz vollkommen. Und trotzdem ist unsere ehrliche Antwort fast immer: Vielleicht. Aber sollten Sie wirklich? Und vor allem – was genau?

Eine Offenlegung vorweg, in eigener Sache: Wir könnten an dieser Stelle bequem mit dem Strom schwimmen. Eigenentwicklung bedeutet Projektgeschäft, und Projektgeschäft ernährt eine Beratung zuverlässiger als der nüchterne Rat, beim Standard zu bleiben. Genau deshalb behandeln wir dieses Thema mit besonderer Vorsicht. Was hier folgt, ist nicht die Hype-Variante. Es ist die Rechnung, die wir auch dann aufmachen, wenn sie gegen das eigene Auftragsbuch spricht.

Die alte Logik – und warum sie so lange getragen hat

Über fast zwei Jahrzehnte war die Make-or-Buy-Frage erstaunlich leicht zu beantworten. Eigenentwicklung war teuer, langsam und riskant: Man brauchte ein Entwicklerteam, einen Projektplan, ein Testkonzept – und am Ende eine Software, die nur das eigene Haus verstand und nur das eigene Haus pflegen konnte. Standard-Software war demgegenüber günstiger, schneller verfügbar und brachte einen Update-Pfad mit: Der Hersteller entwickelte weiter, kümmerte sich um Sicherheit, Schnittstellen und gesetzliche Änderungen.

Diese Logik war nicht falsch. Sie war über zwei Jahrzehnte richtig – und sie ist es ehrlicherweise länger geblieben, als die Schlagzeilen behaupten. Wer „kaufen statt bauen“ als Grundregel verinnerlicht hat, hat in den allermeisten Fällen die richtige Entscheidung getroffen. Das Problem ist nur: Grundregeln haben ein Verfallsdatum – und die Annahmen, auf denen diese eine ruhte, haben erst in jüngster Zeit zu rutschen begonnen.

Wichtig ist dabei eine Unterscheidung, die in der Debatte gern verschwimmt: die zwischen der Verfügbarkeit der Werkzeuge und ihrer praktischen Tauglichkeit. KI-Programmierhilfen gibt es seit 2022, mit ChatGPT wurde das Thema Ende 2022 auch in den Chefetagen präsent – und für klar umrissene, eng abgegrenzte Entwicklungsaufgaben war der Produktivitätsgewinn schon früh messbar. Tauglich für die einfache Aufgabe heißt aber nicht tauglich für den komplexen Fall. Für produktionsnahe, fachlich verschachtelte Mittelstandsprozesse kommt der Nutzen erst jetzt verlässlicher im Tagesgeschäft an – und auch das ungleichmäßig. Wer die Make-or-Buy-Grenze heute neu zieht, sollte sie deshalb an der praktischen Tauglichkeit für den konkreten Fall festmachen, nicht am Datum der ersten Pressemitteilung.

Was KI tatsächlich verändert – und was nicht

Die ehrliche Einordnung beginnt mit einer Trennung: KI verändert einen Teil der Make-or-Buy-Rechnung spürbar – und einen anderen Teil überhaupt nicht. Beide auseinanderzuhalten ist die ganze Kunst.

• Die Baukosten sinken – aber später, als der Hype behauptet

Der Effekt ist real, aber er ist jung und ungleichmäßig. Über Jahre wurde mehr versprochen als geliefert. Erst in jüngster Zeit sehen wir – in eigenen Projekten und bei Kunden – Effizienzgewinne, die im Alltag wirklich ankommen: bei klar umrissenen, gut abgegrenzten Aufgaben durchaus spürbar, bei komplexer Geschäftslogik deutlich weniger. Und die Bruttozahlen täuschen. Was an Tipparbeit gespart wird, fließt zu einem guten Teil in Prüfung, Korrektur und Nacharbeit zurück. Netto bleibt ein Gewinn – aber selten in der Größenordnung, die durch die Schlagzeilen geistert. Was sich wirklich verändert hat, ist die Schwelle für den ersten Wurf: Prototypen, die man früher aus Aufwandsgründen gar nicht gebaut hätte, entstehen heute in Tagen.

Das Bild dazu ist eine simple Kurve. Lange lag der Punkt, ab dem Eigenbau günstiger war als Standard, sehr weit rechts: Man brauchte viel Spezialität und viele Nutzer, bis sich die Eigenentwicklung rechnete. Dieser Punkt hat sich erst kürzlich spürbar nach links verschoben – langsamer, als die Ankündigungen vermuten ließen, und er bewegt sich noch. Fälle, die bis vor Kurzem klar auf der Kaufen-Seite lagen, sind heute ein ehrliches Unentschieden. Nur sagt diese Kurve eben ausschließlich etwas über die Baukosten – über alles, was nach dem Go-live kommt, schweigt sie.

• Der Fachbereich wird zum Entwickler

Die zweite Verschiebung ist subtiler, aber folgenreicher. KI-gestützte Low-Code-Werkzeuge bringen die Entwicklung dorthin, wo der Prozess gelebt wird – in den Fachbereich. Der Einkauf baut sich ein Lieferanten-Bewertungstool, die Produktion eine kleine Rüstzeit-App, der Vertrieb einen Angebots-Konfigurator. Ohne IT-Ticket, ohne Wartezeit, im Idealfall in Tagen statt Monaten. Für die Geschwindigkeit ist das ein Segen. Für die Architektur ist es genau die Stelle, an der es gefährlich wird – dazu gleich mehr.

• Was KI nicht verändert: Betrieb, Wartung, Verantwortung

Und hier ist der Kern, den der Hype regelmäßig überspringt: Die Kosten der Erstellung waren noch nie das eigentliche Problem der Eigenentwicklung. Das eigentliche Problem fängt nach dem Go-live an. Eine Software muss betrieben, gewartet, an neue Schnittstellen angepasst, gegen Sicherheitslücken gehärtet und an gesetzliche Änderungen angeglichen werden. Sie braucht jemanden, der sie in fünf Jahren noch versteht. Genau diese Posten senkt KI bisher kaum – in Teilen erhöht sie sie sogar, weil schneller mehr Software entsteht, die alle gewartet werden will.

Das ist keine reine Berater-Vorsicht – Branchenerhebungen zeichnen dasselbe Bild. Der DORA-Report 2024 etwa findet deutliche wahrgenommene Produktivitätsgewinne durch KI und zugleich, dass mit steigender KI-Nutzung die Liefergeschwindigkeit und vor allem die Stabilität der Auslieferung tendenziell leiden. Im Stack Overflow Developer Survey 2025 wiederum nutzen über vier Fünftel der Entwickler KI-Werkzeuge – während das Vertrauen in die Korrektheit der Ergebnisse sinkt. Schneller schreiben heißt eben nicht automatisch besser ausliefern. Review, Verifikation und Verantwortung verschwinden nicht; sie verschieben sich nur.

→ KI macht Eigenentwicklung billiger. Sie macht sie nicht klüger.

Klüger wird Eigenbau nämlich nicht durch das Werkzeug, sondern durch zwei Dinge: Architektur und Governance. Sie entscheiden, ob aus billigem Bauen ein Vorteil wird oder nur schnellerer Wildwuchs – und sie sind der rote Faden durch den Rest dieses Artikels.

Wann sich Eigenbau heute wirklich lohnt

Wenn die Baukosten sinken, verschiebt sich die Grenze, ab der Eigenbau die richtige Wahl ist – sie verschwindet aber nicht. Aus unserer Sicht gibt es vier Felder, in denen Eigenentwicklung heute schneller und überzeugender ins Geld einspielt als noch vor Kurzem.

Das erste sind differenzierende Prozesse, die kein Standard abbildet – das, womit ein Unternehmen sich am Markt tatsächlich unterscheidet. Ein Konfigurator, der eine einzigartige Produktlogik abbildet. Eine Preisfindung, die jahrelanges Branchenwissen kodiert. Hier wäre es geradezu fahrlässig, das eigene Alleinstellungsmerkmal in ein Standard-Korsett zu pressen.

Das zweite sind Spezial-Workflows mit kleiner Nutzerzahl, für die sich eine Standard-Lizenz nie gerechnet hat. Genau hier war Eigenbau früher zu teuer und Standard zu überdimensioniert – und genau hier macht die gesunkene Bauschwelle den Unterschied. Das dritte ist Datenintelligenz, die sonst niemand hat: Auswertungen und Modelle auf den eigenen Daten, die zum Wettbewerbsvorteil werden. Und das vierte sind schnelle Experimentierfelder – Ideen, die man ausprobieren will, bevor man weiß, ob sie tragen. Dafür musste man früher ein Projekt aufsetzen; heute baut man einen Prototyp und lernt.

Wann der Standard weiterhin gewinnt

So wichtig die verschobene Grenze ist – auf der anderen Seite steht ein ebenso klares Bild. Es gibt Bereiche, in denen Standard-Software weiter die richtige Antwort ist, und zwar deutlicher denn je. Standardprozesse wie Buchhaltung, Lohnverrechnung oder klassische CRM-Funktionen sollte niemand selbst bauen – sie sind überall gleich, millionenfach erprobt und vom Markt zu Preisen abgedeckt, die kein internes Team unterbieten kann.

Dasselbe gilt für Compliance-relevante Bereiche, in denen ein Hersteller die Gewähr für gesetzeskonforme Abwicklung übernimmt – vom Steuerrecht bis zur Datenschutz-Dokumentation. Für Funktionen mit echtem Skaleneffekt, bei denen ein breiter Markt die Weiterentwicklung finanziert, die ein einzelnes Haus nie stemmen könnte. Und für Bereiche mit einem wichtigen Lieferanten- und Partner-Ökosystem, in denen die Anschlussfähigkeit an Standards mehr wert ist als jede Maßanfertigung. Die Faustregel bleibt: Wo Sie sich nicht unterscheiden, sollten Sie auch nicht selbst bauen.

Sechs Fragen vor jeder Make-or-Buy-Entscheidung

Die eigentliche Make-or-Buy-Prüfung beginnt nicht mit der Frage, ob wir etwas bauen können – mit KI können wir inzwischen fast alles. Sie beginnt mit sechs Fragen:

1. Unterscheidet uns dieser Prozess am Markt?

2. Wie viele Nutzer betrifft er?

3. Wie lange wird die Lösung leben?

4. Welche regulatorischen Risiken entstehen?

5. Wie tief hängt sie an den Kernsystemen?

6. Und wer übernimmt Betrieb, Sicherheit, Dokumentation und Weiterentwicklung in fünf Jahren?

Erst wenn diese sechs Fragen beantwortet sind, ist KI-gestützter Eigenbau eine Managemententscheidung – und kein technischer Schnellschuss.

Eine dieser Fragen ist kein Faktor unter sechs, sondern ein Tor, durch das alles andere erst muss: die Betriebsfähigkeit. Ein noch so differenzierender Prozess rechtfertigt keinen Eigenbau, solange nicht geklärt ist, wer Wartung, Sicherheit, Monitoring und fachliche Verantwortung trägt. Ohne Owner, Budget und Dokumentation wird aus der eleganten Eigenlösung die nächste Schuld – womit wir beim unbequemen Teil wären.

Die vier Schulden der „Wir bauen alles selbst“-Welle

Jetzt zum unbequemen Teil. Wenn Bauen so billig wird, dass es jeder kann, baut auch jeder – und die Rechnung kommt später. Wir sehen vier Arten von Schulden entstehen, die in der Euphorie des günstigen Erstaufwands gerne übersehen werden. Sie alle haben eines gemeinsam: Sie tauchen nicht im Projektbudget auf, sondern erst im Betrieb.

1. Wartungs-Schuld

Was heute schnell gebaut ist, muss morgen gepflegt werden. Jede selbstgebaute App ist ein dauerhaftes Wartungsversprechen – an sich selbst. Schnittstellen ändern sich, Bibliotheken werden unsicher, Anforderungen wachsen. Zehn KI-gebaute Apps sind zehn Wartungsverpflichtungen, auch wenn jede einzelne in einem Nachmittag entstanden ist. Geschwindigkeit beim Bau ist kein Versprechen für günstigen Betrieb – eher im Gegenteil.

2. Wissens-Schuld

Wer pflegt die App in fünf Jahren? Bei selbstgebauter Software steckt das entscheidende Wissen oft in einem Kopf – dem des Mitarbeiters aus dem Fachbereich, der das Tool an einem motivierten Wochenende gebaut hat. Verlässt diese Person das Unternehmen, bleibt eine Black Box zurück, die niemand mehr anzufassen wagt. KI-generierter Code verschärft das Problem sogar: Er entsteht schnell, wird aber oft von niemandem wirklich durchdrungen.

3. Compliance-Schuld

KI-generierter Code, der ohne fachkundiges Review in Produktion geht, ist ein Risiko – und zwar eines, das sich erst zeigt, wenn es zu spät ist. Datenschutz, Sicherheit, Nachvollziehbarkeit: Ein Standard-Hersteller haftet hier in einem definierten Rahmen. Bei der Eigenentwicklung liegt diese Verantwortung vollständig im eigenen Haus – auch dann, wenn der Code von einer KI stammt, die niemand mehr im Detail geprüft hat. Nicht umsonst führen einschlägige Sicherheits-Frameworks – die OWASP-Risikoliste für LLM-Anwendungen ebenso wie das Secure Software Development Framework des NIST – ungeprüfte Ausgaben, Lieferketten-Risiken und blindes Vertrauen in die KI als zentrale Gefahren auf.

4. Prozess-Schuld

Die unterschätzteste Schuld von allen. Selbstgebaute Apps zementieren oft genau die Prozesse, die man eigentlich überdenken müsste. Statt zu fragen „Brauchen wir diesen Schritt überhaupt?“ baut man ihn schnell in Software – und macht den Umweg damit dauerhaft. Standard-Software zwingt wenigstens manchmal zur Auseinandersetzung mit einem etablierten Best-Practice-Prozess. Die maßgeschneiderte Eigenlösung erspart einem diese unbequeme Frage – und das ist kein Vorteil.

→ Wer mit KI ohne Architektur-Plan baut, baut den nächsten Zoo – nur schneller.

Zwei Bilder aus der Praxis

Damit das nicht abstrakt bleibt, zwei anonymisierte Beobachtungen aus unserer Arbeit – bewusst eine je Richtung.

Das positive Bild: Ein Mittelständler hat einen Spezial-Konfigurator KI-gestützt selbst entwickelt, der ein echtes Differenzierungs-Merkmal seines Geschäfts abbildet – etwas, das kein Standard-System je geliefert hätte. Der Aufwand war dank KI-Unterstützung überschaubar, die Lösung sitzt sauber in der Erweiterungs-Schicht der Architektur, und nach etwa eineinhalb Jahren hat sich die Investition über gewonnene Aufträge und gesparte Angebotszeit getragen. Hier war Eigenbau die richtige Antwort – weil er an einer differenzierenden Stelle saß und von Anfang an mitgedacht wurde, statt einfach zu entstehen.

Das warnende Bild: Ein anderes Unternehmen hat sich eine Reporting-App selbst gebaut – schnell, günstig, im Fachbereich. Nach rund eineinhalb Jahren wartete sie niemand mehr, weil die ursprüngliche Entwickler-Konstellation nicht mehr zusammen war. Die Auswertungen wurden unzuverlässig, das Vertrauen schwand, und am Ende stand die Erkenntnis: Eine Standard-BI-Lösung hätte rund 80 Prozent des Bedarfs von Tag eins an abgedeckt – mit Update-Pfad und ohne Wissens-Schuld. Gespart wurde am Anfang. Bezahlt wurde am Ende, mit Zinsen.

„Aber bald wartet die KI sich doch selbst“ – der ehrlichste Einwand

Den stärksten Gegeneinwand gegen alles bisher Gesagte wollen wir nicht verschweigen: Wenn KI heute den Bau übernimmt – wird sie nicht morgen auch Wartung, Review und Weiterentwicklung übernehmen? Dann lösten sich drei der vier Schulden quasi von selbst auf. Der Einwand ist berechtigt, und die Richtung stimmt vermutlich sogar. Werkzeuge, die bestehenden Code verstehen, dokumentieren und sicher fortschreiben, werden besser – und das schnell.

Nur darf man zwei Dinge nicht verwechseln: was technisch möglich wird, und was organisatorisch verantwortbar ist. Selbst wenn eine KI eine App in fünf Jahren technisch weiterpflegen kann, bleibt die Frage, wer entscheidet, ob eine Änderung fachlich richtig ist, wer im Schadensfall haftet und wer überhaupt noch weiß, dass es diese App gibt. Das löst kein Werkzeug, sondern nur Governance. Unsere Empfehlung ist deshalb keine Wette gegen den technischen Fortschritt – sie ist eine Wette darauf, dass Verantwortung auch in fünf Jahren bei Menschen liegt. Wer heute baut, sollte für den Fall planen, dass die KI ihm die Wartung nicht abnimmt – und sich freuen, wenn sie es am Ende doch tut.

Unsere ehrliche Empfehlung

Eigenbau – ja. Aber mit Architektur-Disziplin, nicht als Wildwuchs 2.0. Die gute Nachricht ist: Der Ort dafür ist in der Greenfield-Architektur aus Teil 2 längst vorgesehen. Es ist die Erweiterungs-Schicht – der bewusste, kontrollierte Raum für Low-Code und gezielte Eigenentwicklung. Eigenbau gehört dorthin, nicht in eine wuchernde Schatten-IT, die in fünf Jahren niemand mehr überblickt.

Die eigentliche Frage lautet deshalb auch nicht mehr nur „Make or Buy“. Sie lautet: „Make or Buy – und wer betreibt, pflegt und verantwortet es in fünf Jahren?“ Wer diese zweite Hälfte der Frage mitbeantwortet, trifft auch im KI-Zeitalter gute Entscheidungen. Wer sie überspringt, weil das Bauen gerade so verführerisch günstig ist, baut sich seinen nächsten Zoo – nur schneller als beim ersten Mal.

Was als Nächstes kommt

Bleibt eine letzte Frage offen, und es ist die praktischste von allen: Wie kombiniert man das nun konkret? Standard für den Kern, Low-Code für die Lücken, KI-Eigenbau für die Differenzierung – das klingt nach einem schönen Prinzip, aber wie sieht es in Euro und in der täglichen Governance aus? Genau das ist Teil 4 dieser Serie: die kostenoptimierte Symbiose. Wir schauen uns an, wo die typischen Lizenzkostenfallen liegen, wie eine ehrliche TCO-Betrachtung über mehrere Jahre aussieht und wer im Unternehmen eigentlich entscheidet, was Standard, was Low-Code und was Eigenbau wird.

Bis dahin eine Frage zum Mitnehmen für Ihr nächstes „Das bauen wir uns selbst“-Gespräch: Wissen Sie schon, wer das, was Sie heute bauen wollen, in fünf Jahren noch pflegt? Wenn die Antwort klar ist, ist Eigenbau vielleicht genau richtig. Wenn nicht, lohnt sich das Innehalten – bevor der erste Baustein liegt.