Make or Buy im KI-Zeitalter

Als Anbieter von Software hörst du den Satz selten direkt. Er steht hinter der Verlängerung: „Das könnten wir mit KI doch selbst bauen.“ Make or Buy bei Software, also selbst entwickeln oder kaufen, war lange eine Frage für Einkauf und IT-Leitung. Jetzt stellt sie jeder, der an einem Wochenende mit einem Coding Agent gearbeitet hat. In der Befragung „The state of AI in 2026“ von McKinsey (1.719 Teilnehmer aus 97 Ländern, Mai und Juni 2026) geben 32 Prozent an, ihre Organisation habe mindestens ein Softwareprodukt oder eine Funktion nicht gekauft, weil sie sich mit Coding Agents intern bauen ließ.¹ Am häufigsten berichten das Befragte aus Technologieunternehmen, mit 41 Prozent. Gefragt wurde nach der Entscheidung gegen den Kauf, nicht danach, ob der Eigenbau am Ende lief.

Du kannst den Satz als Drohung lesen und den Preis verteidigen. Ich lese ihn als Hinweis darauf, was dein Kunde von deinem Produkt sieht und was ihm darin fehlt.

Make or Buy: was dein Kunde sieht und was nicht

Ein Geschäftsführer arbeitet an fünf Wochenenden mit einem Coding Agent an einem Werkzeug. Das sind zehn Arbeitstage. Kostet die Standardlösung 50 bis 100 Euro im Monat, zahlt sich das für ihn kaum aus. Kostet dein Produkt ein Vielfaches, sieht dieselbe Rechnung anders aus. Das Beispiel ist erfunden und zeigt nur die Größenordnung. In der Rechnung steht in der Regel nur der Bau. Der Betrieb kommt nicht vor.

Dein Kunde vergleicht, was er sieht: Entwicklerstunden, eine Oberfläche, Anpassungen an seine Abläufe. Genau das liefert ein Agent inzwischen in kurzer Zeit. Eine Studie von Demirer, Musolff und Yang für das National Bureau of Economic Research mit mehr als 500.000 Entwicklern auf GitHub zeigt, wo die Grenze liegt: Mit autonomen Agenten steigt die Zahl der Commits kumuliert um 240 Prozent, die der Releases um 30 Prozent.² Die Studie ist ein Arbeitspapier ohne Begutachtung. Geschrieben ist der Code schnell, geprüft und ausgeliefert wird er nicht im selben Tempo.

Was ein Produkt ausmacht, sieht dein Kunde nicht: Erfahrungswissen aus vielen Einsätzen, Randfälle, Fehlerverhalten, Rechte, ein tragfähiges Datenmodell, Betrieb und Absicherung, und jemand, der dafür geradesteht. Dieses Wissen steht nicht im Netz, es steckt im Produkt. Wer kauft, bekommt es mit. Wer selbst baut, erarbeitet es sich, und manches bemerkt er erst im Betrieb.

Daraus folgt eine unbequeme Trennung. Betreibst du echtes Product Engineering, ist der Eigenbau für deinen Kunden in aller Regel kein Ersatz. Setzt du vor allem um, was der Kunde bestellt, und baust dafür etwas Oberfläche, kann er es auch einem Agenten auftragen. Das hängt nicht an der Größe deines Produkts, sondern daran, ob das Unsichtbare tatsächlich darin steckt.

Warum dein Kunde wirklich baut

Kaum jemand baut eine Anwendung, weil er eine Anwendung besitzen möchte. Wer selbst baut, hat meist ein Problem, das das gekaufte Produkt ignoriert oder nicht angemessen löst. Neu ist nur, dass er es jetzt selbst lösen kann.

Ein Fall aus den USA passt dazu. Das Unternehmen Curative hat nach Angaben seines Gründers ein CRM-Abo über rund 600.000 US-Dollar im Jahr gekündigt und in etwa zwei Monaten ein eigenes System gebaut. Als Grund nennt er nicht den Preis: Im Haus habe niemand mehr damit gearbeitet.³ Das ist ein Einzelfall aus zweiter Hand, kein Beweis.

Das zweite Motiv ist der Preis. Das britische National Cyber Security Centre beschreibt ein Startup, das ein Verlängerungsangebot zum doppelten Preis bekam und die benötigten Kernfunktionen binnen Stunden selbst nachbaute.⁴ Auch das sagt etwas über das Produkt: Der Kunde hat den Gegenwert nicht mehr gesehen.

In beiden Fällen erfährst du durch den Eigenbau etwas, das dir sonst niemand sagt.

Kern und Rand

Wo dein Kunde bauen soll und wo nicht, lässt sich nach der Lebensdauer trennen.

• Der Kern ist das System, dessen Zustand fachlich als verbindlich gilt: Stammdaten, Verträge, Buchungen, Aufträge. Dafür steht der Begriff System of Record. Dort zählen Verlässlichkeit, Rechte, Nachvollziehbarkeit und Betrieb. Eine Eigenentwicklung ist hier teuer und riskant.
• Der Rand ist das Schnelllebige: ein Dashboard, eine Auswertung, eine Landingpage zur Kampagne. Es ändert sich ständig, ein Fehler hat wenig Folgen, und ein Agent baut es an einem Nachmittag.

Diese Unterscheidung ist nicht neu. Bain,⁵ das National Cyber Security Centre⁴ und der Bitkom-Bericht „Softwarewelt 2036“⁶ ziehen dieselbe Linie mit anderen Worten. Strittig ist, was du als Anbieter daraus machst.

Den Rand öffnen, statt Schranken zu bauen

Mein Rat: Biete Schnittstellen an, die so standardisiert und einfach sind, dass dein Kunde den Rand selbst baut. Er bekommt die Passgenauigkeit, die dein Standard nicht liefert, ohne den Kern aufzugeben. Was er baut, hängt an deinem System.

Die Branche bewegt sich gerade in die andere Richtung. Deloitte beschreibt unter dem Stichwort „Tollgating“ Gebühren für den Zugriff auf Daten, die Kunden bisher als ihre eigenen ansahen, und die Reaktion darauf: eigene Orchestrierung, schärfere Prüfung der Datenrechte vor jeder Verlängerung.⁷ Im Bitkom-Bericht heißt es, Abschottung und „absichtliche Inkompatibilität verlieren an Tragfähigkeit“.⁶ Der Bericht stützt sich auf zwölf Einschätzungen und ist nicht repräsentativ.

Es gibt einen ernsten Einwand. Bei Bain sind offene Schnittstellen gerade das Merkmal der gefährdeten Felder: Wo fremde Agenten darüber an die Arbeit kommen, schrumpft der Umsatz. Bain rät deshalb, Schemata gezielt offenzulegen.⁵ Ich nehme das als Bedingung für meinen Rat. Offenheit hilft dir nur, wenn der verbindliche Zustand bei dir bleibt. Bist du lediglich die Oberfläche über Daten, die anderswo gelten, beschleunigt sie deinen Ersatz.

Der offene Rand hat einen zweiten Nutzen. Was deine Kunden darauf bauen, zeigt dir, was in deinem Produkt fehlt.

Der Kern schützt nur, solange darin gearbeitet wird

Ein System ist verbindlich, solange die Arbeit deines Kunden darin stattfindet. Deshalb gehört für mich zum Product Engineering, die tatsächliche Nutzung dauerhaft zu beobachten. Geht sie zurück, gehst du dem nach wie einem Fehler: Du klärst, warum, und bearbeitest das eigentliche Problem, bevor dein Kunde es selbst löst.

Das hat Grenzen. Die Menschen, die mit deinem Produkt arbeiten, sind Beschäftigte deines Kunden. Was du auswerten darfst, hängt von Vertrag, Datenschutz und der Mitbestimmung in seinem Haus ab. Läuft dein Produkt beim Kunden vor Ort, siehst du die Nutzung oft gar nicht. Dann bleiben zusammengefasste Zahlen, die der Kunde freigibt, und das Gespräch.

Sinkende Nutzung kann außerdem zweierlei bedeuten: Dein Produkt löst ein Problem nicht, oder Agenten erledigen die Arbeit, die bisher Menschen darin getan haben. Jason Lemkin von SaaStr sieht den Druck ohnehin nicht beim Nachbau, sondern beim Budget, das zu KI wandert, und bei der Lizenz je Nutzer: Der Kunde behält dein System und braucht weniger Plätze.⁸ Auch die Befragten des Bitkom-Berichts erwarten, dass die Abrechnung je Platz verliert.⁶ Dazu folgt ein eigener Text.

Fünf Fragen an dein eigenes Produkt

1. Was sieht dein Kunde von deiner Arbeit, und was nicht? Sieht er nur Stunden und Oberfläche, vergleicht er sie mit einem Agenten.
2. Welcher Teil deines Produkts ist nur die Umsetzung von Kundenwünschen? Den kann ein Agent übernehmen.
3. Wo gilt dein Zustand als verbindlich, und wie einfach sind die Schnittstellen dorthin? Das ist dein Kern, und die Schnittstellen sind sein Eingang.
4. Was bauen deine Kunden bereits selbst, und was sagt dir das? Jeder Eigenbau am Rand benennt eine Lücke.
5. Weißt du, wie viel deine Kunden dein Produkt tatsächlich nutzen? Wenn nicht, erfährst du vom Rückgang erst bei der Kündigung.

Dieselbe Frage stellt sich bei den Bausteinen in deinem eigenen Produkt, etwa bei der PDF-Erzeugung: einbinden oder selbst bauen. Dazu gibt es einen eigenen Text.

Meine Einschätzung

Was KI für das bedeutet, was du verkaufst, klären wir im AI Impact Check: ein Vorgespräch, ein halber Tag Workshop mit Geschäftsführung und Technik und ein persönlicher Radar, der festhält, was in den nächsten 90 bis 180 Tagen ansteht.

Quellen

Redaktionelle Grundsätze