Integrationen per Klick: App Store statt Engineering-TicketTime-to-Market entscheidet sich selten im…
Modular Commerce: Der Engpass sitzt jetzt im Frontend
Modular Commerce löst das Replatforming-Problem dort, wo es entstanden ist: im Backend. Genau dadurch legt es frei, wo der eigentliche Time-to-Market-Engpass sitzt, nämlich im Frontend. Wer Core Commerce in acht Wochen einführt, danach aber pro Modul eine eigene Oberfläche bauen lässt, hat den Flaschenhals verschoben, nicht entfernt.
Mein Take: Das ist die wichtigste Architektur-Verschiebung des Jahres, und die meisten Roadmaps rechnen sie noch nicht mit.
Was sich im Markt verschoben hat
Seit Juli 2026 verkauft commercetools sein Angebot als Module. Core Commerce mit Cart, Order, Checkout, Customer und B2B auf der einen Seite, Product Catalog mit Product Modeling, Pricing, Inventory und Search auf der anderen. Beides ist einzeln buchbar, statt nur als vollständige Plattform. Nachzulesen in der Ankündigung zu Modular Commerce.
Doug McNary, CEO von commercetools, ordnet den Schritt so ein:
„As the pace of commerce innovation accelerates, companies can no longer afford to wait years to modernize. Enterprises want to solve immediate business problems, prove value quickly and evolve over time."
Dem ist inhaltlich nichts hinzuzufügen. Es stimmt. Und es ist bemerkenswert, wer es sagt: ein Anbieter mit über 600 Marken auf der Plattform und rund 120 Milliarden Euro annualisiertem GMV. Wenn der Composable-Platzhirsch das Replatforming-Projekt in kaufbare Teile zerlegt, ist das kein Produkt-Detail, sondern ein Markt-Signal. Die Botschaft an den Markt lautet: Modernisierung läuft inkrementell, nicht als Big Bang.
Der Markt-Move ist eindeutig. Die Frage ist nur, ob die Rechnung damit vollständig ist.
Warum der Engpass wandert, statt zu verschwinden
Ein Modul liefert eine API. Eine API liefert keinen Geschäftswert. Wert entsteht erst dort, wo ein Kunde etwas sieht, versteht und kauft: auf der Ausspielseite.
Genau deshalb verschiebt sich die Rechnung, statt kleiner zu werden. Vorher stand ein großes Replatforming-Projekt im Budget, mit klarem Anfang und klarem Ende. Jetzt stehen dort mehrere kleine Backend-Einführungen, und daneben, meist unbeziffert, ein Frontend-Projekt pro Modul.
- Backend-Einführung Klassisches Replatforming: ein großes Projekt. Modular Commerce ohne Frontend-Layer: mehrere kleine, planbare Schritte.
- Frontend-Aufwand Klassisches Replatforming: einmalig, aber groß. Modular Commerce ohne Frontend-Layer: pro Modul erneut, in Summe größer.
- Sichtbarer Kundennutzen Klassisches Replatforming: am Ende des Projekts. Modular Commerce ohne Frontend-Layer: erst nach der jeweiligen Oberfläche.
- Risiko Klassisches Replatforming: konzentriert im Go-Live. Modular Commerce ohne Frontend-Layer: verteilt, dafür dauerhaft.
Das Muster ist nicht neu. Wir haben es schon gesehen, als Geschwindigkeit zum Haupt-Treiber für Composable-Entscheidungen wurde, nachzulesen in unserer Analyse zu Speed to Market als Composable-Treiber. Modular Commerce macht das Muster jetzt nur deutlich sichtbarer, weil die Backend-Seite sauber getaktet ist und die Frontend-Seite es nicht ist.
Die Rechnung, die in der Modul-Logik fehlt
Rechne es einmal für Dich durch. Du buchst Product Catalog, weil Dein Pricing dringend flexibler werden muss. Vier Wochen später ist das Modul angebunden. Dann stellt jemand die Frage, die alles entscheidet: Wo genau sieht ein Kunde den neuen Preis, in welchen Ländern, in welcher Marke, in welchem Kanal, und wer baut das?
Ab hier läuft die Uhr wieder von vorn, nur eben im Frontend-Team. Beim nächsten Modul dasselbe. In unseren Projektgesprächen sehen wir regelmäßig Composable-Vorhaben, die über neun Monate laufen, obwohl das Backend längst stand. Der Grund ist fast immer derselbe: Frontend, Integration und Deployment wurden parallel neu aufgebaut, jeweils als Einzelfall.
Der Punkt ist nicht, dass die Backend-Modularisierung falsch wäre. Sie ist richtig, und sie ist überfällig. Der Punkt ist, dass Modularität nur dann Time to Market erzeugt, wenn sie auf beiden Seiten der API existiert. Sonst kaufst Du Geschwindigkeit im Backend und bezahlst sie im Frontend zurück. Wie diese Experience-Schicht konkret aussehen muss, haben wir am commercetools-Stack durchgespielt: Enterprise Commerce in Tagen statt Monaten.
Was das für Dich als Entscheider bedeutet
Drei Konsequenzen, die ich jedem Geschäftsführer und jedem Commerce-Lead mitgeben würde:
Erstens: Miss die richtige Kennzahl. Nicht Zeit bis zum Go-Live des Moduls, sondern Zeit bis zum ersten Umsatz, der über dieses Modul läuft. Die Differenz zwischen beiden Zahlen ist Dein Frontend-Gap.
Zweitens: Entkopple den Frontend-Layer, bevor Du das zweite Modul buchst. Solange die Ausspielseite an ein einzelnes Backend gekoppelt ist, erbt sie jede Backend-Entscheidung. Ein eigenständiger Frontend-Layer über der Composable Digital Experience Platform dreht das um: das Backend wird austauschbar, die Oberfläche bleibt stehen.
Drittens: Denk die Ausspielseite selbst modular. Wenn Cart, Search oder Pricing als Module kommen, müssen Komponenten, Seiten und Kampagnen genauso zusammensteckbar sein. Genau das ist die Aufgabe von Composability und Orchestrierung im Frontend, und der Grund, warum wir Laioutr als Frontend Management Platform gebaut haben und nicht als weiteres Template-Set.
Konkret heißt das bei uns: eine Standard-Anbindung an über 50 Backends, darunter commercetools als Backend hinter einem entkoppelten Frontend, ein Studio, in dem Marketing Seiten selbst baut, statt auf einen Sprint zu warten, und eine Komponenten-Bibliothek, die für alle Marken und Märkte gleichzeitig gilt. Die Zahlen dahinter stammen aus unseren eigenen Projekten: 65 Prozent kürzere Time-to-Launch für neue Landingpages gegenüber einem klassischen Headless-Setup und ein Median von unter 14 Tagen für die Migration mit Founder-Begleitung.
Das ist keine Gegenposition zu Modular Commerce. Es ist die fehlende Hälfte der Rechnung. Wer beide Seiten modular hält, bekommt genau das, was McNary beschreibt: schnelle Wertbeweise statt Jahresprojekte. Wer nur die Backend-Hälfte modularisiert, bekommt schnellere Backend-Projekte und wartet danach genauso lange wie vorher.
FAQ
Ist Modular Commerce ein Ersatz für Composable Commerce? Nein. Es ist eine Einkaufs- und Einführungslogik innerhalb einer composable Architektur. Du kaufst nicht mehr die ganze Plattform auf einmal, sondern die Funktionen, die Du zuerst brauchst.
Warum reicht ein modernes Backend allein nicht für Time to Market? Weil ein Modul eine Schnittstelle liefert, keine Oberfläche. Der Kunde sieht die API nicht. Erst die Ausspielseite macht aus einer Funktion einen Umsatz, und genau dort entsteht der Aufwand, den die Modul-Rechnung meist nicht enthält.
Müssen wir dafür unser Backend wechseln? Nein, im Gegenteil. Der Frontend-First-Weg funktioniert gerade dann, wenn das Backend bleibt. Du entkoppelst die Oberfläche, führst danach Module in Deinem Tempo ein und musst die Ausspielseite kein zweites Mal bauen.
Wie schnell ist so ein Frontend-Layer produktiv? Bei einem Single-Brand-Setup liegt der Median unserer begleiteten Migrationen bei unter 14 Tagen. Multi-Brand- und Multi-Market-Szenarien brauchen erwartungsgemäß länger, weil Marken-Tokens, Locales und Berechtigungen mitgeplant werden.
Was ist der erste sinnvolle Schritt? Nimm das Modul, das als nächstes ansteht, und beziffere ehrlich, was die dazugehörige Oberfläche kostet. Wenn diese Zahl größer ist als die Modul-Einführung selbst, hast Du Deinen Business Case für einen eigenständigen Frontend-Layer.
Nächste Schritte
Wenn bei Dir gerade ein Modul-Fahrplan entsteht, lohnt sich der Blick auf die andere Seite der API, bevor das erste Modul live geht. Buch Dir eine 30-minütige Demo, wir gehen Deinen Fahrplan gemeinsam durch und beziffern den Frontend-Anteil.
Weitere Themen aus der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist CEO und Co-Founder von Laioutr. Er arbeitet mit Handels- und Markenunternehmen im DACH-Raum daran, den Frontend-Layer aus dem Replatforming-Projekt herauszulösen.