Make-or-Buy im B2B-Commerce: Wie KI die Plattformauswahl kippt

Die Make-or-Buy-Entscheidung im B2B-Commerce folgte zwei Jahrzehnte lang einem simplen Gesetz: Wer eine neue Plattform brauchte, kaufte das Standardprodukt, das am nächsten an die eigenen Anforderungen herankam – und passte sich dem Rest der Lücke selbst an. Custom-Entwicklung galt als Luxus, den sich nur Konzerne mit dreistelligen Budgets leisten konnten. Diese Faustregel ist gerade dabei zu kippen. Und das verändert nicht nur die Wahl der Software, sondern die ökonomische Logik dahinter.

Wer die Tragweite dieser Verschiebung verstehen will, kommt am Ende dieses Artikels nicht umhin, sich drei unbequeme Fragen zu stellen – Fragen, die über Plattform-Auswahl hinausgehen und an die Reife der eigenen Organisation rühren. Wir kommen am Schluss darauf zurück. Zunächst aber zur Logik, die dahinter steht.

Stellen wir uns die typische Plattform-Auswahl im gehobenen B2B-Mittelstand vor. Ein Distributor mit 8.000 SKUs, drei Ländermärkten, komplexer Preisstruktur, Anbindung an ERP und PIM, sucht eine neue Commerce-Plattform. Die Beratung erstellt eine Anforderungsliste mit 200 Kriterien, schickt RFPs an commercetools, Spryker, SAP, Adobe, vielleicht Emporix. Am Ende gewinnt das Produkt, das am meisten Kriterien out-of-the-box abdeckt – sagen wir 70 Prozent. Die restlichen 30 Prozent werden in einem Implementierungsprojekt von 12 bis 18 Monaten kundenspezifisch ergänzt.

Hinter dieser Standard-Logik steht eine harte ökonomische Realität: Custom-Entwicklung war teuer. Ein neues B2B-Feature, sauber gebaut, getestet, dokumentiert und produktiv ausgerollt, hat traditionell zwischen sechs und achtzehn Monaten gedauert und sechsstellige Budgets verschlungen. Bei dieser Kostenstruktur war es immer rationaler, fünf Standardlizenzen zu kaufen, als ein Feature selbst zu entwickeln. Auch wenn das Standardprodukt nur 70 Prozent passte und 30 Prozent unbequeme Kompromisse erzwang.

Die Konsequenz dieser Logik kennt jeder, der lange genug in der Branche ist: Unternehmen formen sich nach ihrer Software, nicht umgekehrt. Prozesse werden an die Plattform angepasst, weil das günstiger ist als die Plattform an die Prozesse anzupassen. Differenzierung geht verloren, weil alle die gleichen Standardprodukte mit den gleichen Standardprozessen nutzen. Lizenzkosten steigen jährlich um 8 bis 15 Prozent, während die individuelle Wertschöpfung sinkt.

Der Faktor, der diese ökonomische Gleichung kippt, ist nicht „die KI im Allgemeinen" – sondern eine sehr konkrete Entwicklung der letzten 18 Monate: KI-Agenten wie Claude Code oder Cursor können in spezifischen Software-Architekturen mittlerweile vollständige Features eigenständig bauen, inklusive Datenmodell, Geschäftslogik, API-Anbindung und Tests. Nicht im Sinne von „Coding-Assistenz", die Entwicklern Tipparbeit abnimmt – sondern im Sinne von autonomen Builds, bei denen ein Mensch die Anforderung formuliert, das Ergebnis reviewed und freigibt.

Was das in Zahlen bedeutet, ist drastisch. Wo eine spezialisierte Funktion früher drei bis sechs Monate gedauert hat, sehen wir bei Projekten auf KI-tauglichen Architekturen aktuell Zeiträume von Tagen bis wenigen Wochen für vergleichbare Ergebnisse. Das ist kein Marketing-Versprechen, sondern beobachtete Realität in Pilotprojekten – und auch in unseren eigenen Engagements.

Wenn die Kosten für individuelle Entwicklung um den Faktor 5 bis 10 fallen, verändert sich die gesamte Make-or-Buy-Logik. Plötzlich ist die Frage nicht mehr „Welches Standardprodukt passt am wenigsten schlecht?", sondern: „Welche Architektur erlaubt es uns, schnell und günstig genau das zu bauen, was wir wirklich brauchen?". Die 30 Prozent Lücke, für die früher Workarounds gebaut wurden, schließen sich plötzlich mit Custom-Code, der weniger kostet als die Workarounds. Differenzierung wird wieder bezahlbar.

Was das in der Praxis bedeutet, lässt sich am besten an konkreten Projekten illustrieren. In einem aktuellen Implementierungsprojekt konnten wir für unseren Kunden ein vollständig individuell entwickeltes Storefront umsetzen – zum gleichen Budget, mit dem üblicherweise nur ein angepasstes Standard-Template aus dem Plattform-Marketplace finanzierbar gewesen wäre. Der Unterschied im Ergebnis ist signifikant: Statt einer optisch und funktional an die Plattform-DNA gebundenen Standardlösung erhielt der Kunde eine Storefront, die auf seine Markenführung, sein Sortiment und seine Kundenstruktur exakt zugeschnitten ist. Vor 18 Monaten wäre dieselbe Lösung beim doppelten oder dreifachen Budget gelandet – und damit für den Kunden außerhalb der Reichweite gewesen.

Ein zweites Beispiel zeigt eine andere Dimension der Verschiebung. In einem CMS-Projekt haben wir eine native DeepL-Integration entwickelt, die beim Kopieren einer Seite in eine Ländervariante die Inhalte sofort in der Zielsprache verfügbar macht. Was klingt wie ein Detail, ist betrieblich enorm: Die Content-Pflege für mehrsprachige B2B-Auftritte sinkt um einen Anteil, den keine Standardsoftware leisten kann – weil keine Standardsoftware diese spezifische Workflow-Optimierung im Repertoire hat. Solche Features wurden früher als „nice to have" abgewählt, weil das Bauen sie unwirtschaftlich machte. Heute sind sie ROI-positiv ab dem ersten Monat.

Beide Beispiele haben einen gemeinsamen Nenner: Es geht nicht primär darum, dass KI Standardfeatures schneller baut. Es geht darum, dass plötzlich Features wirtschaftlich werden, die mit Standardsoftware gar nicht abbildbar sind und früher als Investition nicht zu rechtfertigen waren.

Hier kommt die unbequeme Wahrheit, die in der aktuellen Diskussion oft unterschlagen wird: Die beschriebene Geschwindigkeitssteigerung gilt nicht für jede Software gleich. Sie gilt insbesondere für Architekturen, die KI-Agenten gut verarbeiten können – typischerweise moderne, modulare, in einer einheitlichen Sprache geschriebene Frameworks mit klaren Schnittstellen und maschinenlesbarer Dokumentation.

Die etablierten Enterprise-Plattformen sind technisch nicht „schlechter", aber für KI-gestützte Entwicklung schlechter geeignet. Komplexe Schichtarchitekturen, gemischte Sprachstacks und herstellereigene Konzepte, die in Trainingsdaten unterrepräsentiert sind, bremsen KI-Agenten aus. Dieser Vorsprung wird sich in den nächsten 24 bis 36 Monaten verkleinern, weil die etablierten Hersteller nachziehen werden. Aber genau dieses Zeitfenster ist die Chance für Unternehmen, die jetzt strategisch handeln.

Was bedeutet das konkret für die Plattform-Auswahl im B2B-Mittelstand? Drei Fragen, die sich ändern müssen.

Von „Welches Produkt deckt am meisten ab?" zu „Welche Architektur lässt uns am schnellsten bauen?". Der Anforderungskatalog mit 200 Kriterien ist nicht mehr die richtige Methode. Wenn Custom-Entwicklung günstig wird, ist die Fähigkeit der Plattform zur schnellen, KI-gestützten Erweiterung wichtiger als der Standard-Funktionsumfang am Tag der Auswahl. Eine Plattform mit 50 Prozent Standard-Coverage und exzellenter Erweiterbarkeit schlägt eine mit 80 Prozent Coverage und schwerfälliger Customization.

Lizenzkosten werden in den meisten Total-Cost-Berechnungen überbewertet. Wenn Custom-Entwicklung bezahlbar wird, sinkt der Wert teurer All-Inclusive-Lizenzen. Gleichzeitig steigt der Wert der Frage: Wie schnell können wir morgen ein neues Geschäftsmodell, einen neuen Markt, einen neuen Kanal launchen? Geschwindigkeit über die Zeit schlägt Funktionsumfang am Stichtag.

Von „Wir kaufen, was zu uns passt" zu „Wir bauen, was uns differenziert". Standardsoftware standardisiert Prozesse – das ist ihr Wesen. Wenn alle Wettbewerber dieselbe Plattform mit denselben Out-of-the-Box-Prozessen nutzen, kann keine Differenzierung über die Software entstehen. Die Verschiebung der Build-vs-Buy-Schwelle macht Software wieder zum strategischen Differenzierungshebel – aber nur, wenn das Unternehmen diese Möglichkeit auch nutzt.

Nicht jedes Unternehmen ist heute schon auf der „neuen" Seite der Schwelle. Die Verschiebung trifft am stärksten Organisationen, die drei Voraussetzungen mitbringen: Sie haben oder bauen interne oder partnerseitige Engineering-Kapazität, sie haben Geschäftsanforderungen, die mit Standard nur schlecht abbildbar sind, und sie haben eine Entscheidungsstruktur, die mittelgroße strategische Investitionen tragen kann ohne in jahrelange Konzern-Approvals zu fallen.

Wer 20.000 SKUs hat, in 30 Ländern verkauft, drei ERP-Systeme synchronisieren muss und Compliance-Anforderungen aus Pharma oder Finance erfüllen muss, fährt mit den etablierten Enterprise-Plattformen weiterhin besser. Die Verschiebung der Schwelle bedeutet nicht das Ende der Standardsoftware – sie bedeutet das Ende der Standardsoftware als Default-Antwort.

Die wirklich strategische Frage für CFOs, Geschäftsführer und Heads of Digital im B2B-Mittelstand lautet damit nicht mehr: „Welche Plattform sollen wir kaufen?". Sie lautet: „Sind wir organisatorisch in der Lage, von der neuen Make-or-Buy-Realität zu profitieren – oder kaufen wir aus Gewohnheit weiter Standard?".

Diese Frage erfordert ehrliche Selbstauskunft. Hat unser Team die Reife, KI-gestützte Entwicklung in geordneten Prozessen einzusetzen? Haben wir Anforderungen, die echte Differenzierung versprechen, oder sind unsere Prozesse so generisch, dass Standard genügt? Haben wir die Entscheidungsgeschwindigkeit, mittelgroße Investments in Eigenentwicklung autonom zu treffen, oder zwingt uns unsere Governance in Standard-Käufe?

Wer diese Fragen ehrlich beantwortet, kommt zu einer anderen Plattform-Auswahl als wer den klassischen RFP-Prozess durchläuft. Und wer falsch antwortet – in beide Richtungen – zahlt in den nächsten fünf Jahren strategisch dafür.

Die meisten Unternehmen, mit denen wir sprechen, haben bisher kein klares Bild davon, ob ihre aktuelle Ausgangslage für KI-gestützte Custom-Entwicklung geeignet ist. Sprechen Sie die strategischen Implikationen direkt mit unserem Business Consulting durch: 30 Minuten Sparring zu Ihrer Plattform-Situation, ohne Vertriebsdruck. Wir geben Ihnen eine ehrliche Einschätzung, ob Sie heute auf der Make- oder Buy-Seite besser aufgestellt sind – und wo der nächste konkrete Schritt liegt.