Eine Frage, die nicht mehr passt
In jedem IT-Lehrbuch steht die Make-or-Buy-Frage als eine der zentralen strategischen Entscheidungen. Soll das Unternehmen eine Lösung selbst entwickeln oder von einem Anbieter kaufen? Die Antwort hing klassisch an drei Faktoren: Kernkompetenz, Kosten, Time-to-Market. Wer keine eigene Software-Mannschaft hatte, kaufte. Wer Differenzierung wollte, baute. Wer beides nicht klar entscheiden konnte, kaufte sicherheitshalber.
Diese Logik bricht zusammen. Nicht weil eine Seite gewinnt, sondern weil die Frage selbst veraltet ist. Die ehrliche Antwort auf „Make or Buy?" ist heute immer öfter: „Beides – aber an verschiedenen Stellen."
Wie der Stack wirklich aussieht
Schau dir die Architektur eines modernen Unternehmens an. Es kauft Salesforce als CRM-Plattform – aber baut darauf eigene Lightning-Apps, Flows und KI-gestützte Datenanreicherung. Es kauft Snowflake als Data-Warehouse – aber baut eigene Pipelines, Modelle und Semantiklayer. Es kauft Microsoft 365 – aber baut eigene Copilot-Erweiterungen mit Zugriff auf eigene Wissensbasen. Es kauft Stripe – aber baut eigene Checkout-Flows, Subscription-Logik und Reporting.
In jedem dieser Fälle ist die Plattform gekauft, der Wert liegt im Eigenbau. Die Plattform liefert das, was alle haben können: Infrastruktur, regulatorische Konformität, Skalierbarkeit, Betrieb. Die Eigenentwicklung liefert das, was differenziert: Prozesse, Daten, Workflows, Erlebnis.
Das ist „Build the Buy" – nicht statt kaufen, sondern auf gekauftes aufsetzen. Es ist die Architektur, in die sich Unternehmen seit Jahren bewegen, ohne dass es einen Namen dafür gegeben hätte. Mit KI wird sie zur dominierenden Form.
Warum die alte Frage falsch war
Die klassische Make-or-Buy-Logik unterstellte, dass eine Lösung entweder als Ganzes gekauft oder als Ganzes gebaut wird. Diese Annahme war nie ganz richtig – schon SAP-Implementierungen bestanden zu erheblichen Teilen aus eigenem Customizing – aber sie war eine brauchbare Vereinfachung.
Heute ist sie eine Fehlannahme. Moderne Plattformen sind APIs und Erweiterungspunkte, keine geschlossenen Lösungen. Salesforce ohne eigene Anpassung ist ein generisches CRM. Mit eigener Schicht obendrauf wird es zum spezifischen Geschäftsprozess. Snowflake ohne eigene Modelle ist eine teure Datenbank. Mit eigenen Modellen wird es zum analytischen Vorteil.
Wer heute nach „Make or Buy" fragt, fragt nach einem Modell, das die Realität nicht mehr abbildet. Die bessere Frage lautet: „Was kaufen wir – und was bauen wir darauf?"
Was das wirtschaftlich verändert
Drei Konsequenzen, die in Budgetdiskussionen langsam ankommen:
Die Lizenzkosten der Plattform sind nur die halbe Rechnung. Wer Salesforce für 500.000 Euro im Jahr lizenziert, gibt typischerweise nochmal 500.000 bis eine Million für Customizing, Integration und Eigenentwicklung aus. Das war früher ein Argument gegen Plattformen. Heute ist es einfach ein realistischer TCO – und der Eigenbau-Anteil produziert den Großteil des Werts.
Lock-in verschiebt sich, verschwindet aber nicht. Wer auf Salesforce baut, ist an Salesforce gebunden – nicht nur durch Lizenzkosten, sondern durch die eigene Schicht, die ohne die Plattform nutzlos wäre. Das macht die Plattformwahl strategischer als früher. Es ist kein bloßer Tooling-Entscheid mehr, sondern eine Wette auf einen Ökosystempartner für die nächsten zehn Jahre.
Eigenkompetenz wird teurer und wichtiger. Wer auf eine Plattform baut, braucht Leute, die diese Plattform tief verstehen – plus Leute, die generelle Entwicklung beherrschen. Diese Mischkompetenz ist am Markt knapp und teuer. Sie macht den Unterschied zwischen einer Plattform, die ihren Wert ausschöpft, und einer, die nur als Lizenz herumliegt.
Wo „Build the Buy" gewinnt
Die Stärke des Modells liegt in der Arbeitsteilung. Was die Plattform liefert, muss niemand mehr bauen. Was der Eigenbau liefert, kann niemand mehr kaufen.
Konkret: Authentifizierung, Berechtigungen, Skalierung, Audit-Logs, regulatorische Updates, Betrieb, Backups – alles Themen, die mühsam, wichtig und nicht differenzierend sind. Hier zahlt jeder Eurocent Plattformkosten sich aus, weil die Alternative wäre, ein halbes Entwicklerteam mit Dingen zu beschäftigen, die keinen Kunden je interessieren.
Auf der anderen Seite: Bewertungslogik für Angebote, Tour-Optimierung, Lead-Scoring, Pricing-Modelle, automatisierte Vertragsverhandlung, individuelle Risikobewertung – Themen, die unternehmensspezifisch sind und in denen jede kleine Verbesserung im Kerngeschäft messbar ist. Hier ist Eigenbau der Hebel, weil generische Plattformfunktionen den Wettbewerb gleichmachen.
Wo das Modell scheitert
„Build the Buy" funktioniert nicht überall. Drei Konstellationen, in denen es nicht aufgeht:
Plattformen ohne ernsthafte Erweiterbarkeit. Manche SaaS-Anbieter behaupten, eine Plattform zu sein, liefern aber nur eine geschlossene Anwendung mit ein paar Webhook-Schnittstellen. Wer darauf bauen will, baut auf Sand. Vor jeder „Build the Buy"-Entscheidung gehört eine ehrliche Bewertung der API-Reife des Anbieters.
Plattformen mit feindlicher Pricing-Politik. Einige Anbieter berechnen Pro-API-Call oder Pro-Custom-Object so aggressiv, dass jeder Eigenbau zur Kostenfalle wird. Hier verschiebt sich der Wert vom Kunden zum Anbieter, sobald die Eigenentwicklung Erfolg hat. Das ist ökonomisch tödlich und sollte ein klares Ausschlusskriterium sein.
Eigenbauten, die nur Plattform-Versäumnisse kompensieren. Wenn das eigene Team monatelang baut, was eigentlich die Plattform liefern sollte – Reporting, Standard-Workflows, einfache Integrationen – ist die Plattformwahl falsch. Eigenbau soll Differenzierung produzieren, nicht Plattformlücken füllen.
Die richtige Frage in vier Schritten
Statt Make-or-Buy als ja/nein-Entscheidung zu behandeln, lohnt sich eine geschichtete Analyse:
Welche Schicht ist nicht differenzierend? Hier kaufen. Plattform-Standard reicht.
Welche Schicht ist differenzierend, aber generisch lösbar? Hier Plattform plus Konfiguration. Kein eigener Code nötig, aber bewusste Gestaltung.
Welche Schicht ist differenzierend und unternehmensspezifisch? Hier Eigenbau auf der Plattform. Das ist die Schicht, die den Wettbewerbsvorteil produziert.
Welche Schicht ist so kritisch, dass Plattform-Risiko inakzeptabel ist? Hier Eigenbau ohne Plattform. Selten, aber existiert – zum Beispiel im Kern eines algorithmisch differenzierten Produkts.
Diese vier Fragen ersetzen das alte Make-or-Buy. Sie sind anspruchsvoller, weil sie eine differenzierte Sicht auf den eigenen Stack verlangen. Sie sind aber näher an der Realität dessen, wie moderne Software wirklich entsteht.
Wir bei nh labs erleben in Projekten häufig, dass Kunden mit klassischer Make-or-Buy-Logik ankommen und am Ende eine „Build the Buy"-Architektur umsetzen – einfach weil sich diese im Detail als die wirtschaftlich und strategisch tragfähigere Lösung erweist.
Fazit
Die Make-or-Buy-Frage hat ihre Schärfe verloren, weil ihr Gegensatz nicht mehr gilt. Moderne Software entsteht hybrid: gekaufte Plattformen für das, was alle brauchen, eigene Schichten für das, was differenziert. Wer noch in den alten Kategorien denkt, optimiert das falsche Problem. Wer „Build the Buy" als Architektur akzeptiert, kann seinen Stack so gestalten, dass Plattform und Eigenbau zusammen mehr Wert produzieren als jeder Teil allein. Das ist nicht der Kompromiss zwischen Make und Buy – das ist die nächste Stufe.