Sechs Monate nach dem Composable-Umstieg ist die erste Reparatur in den allermeisten Teams nicht das Backend, nicht die PIM-Anbindung und nicht der Such-Provider. Es ist die Frontend-Ebene: die Storefront-Experience, die Ladezeit, die Iterationsgeschwindigkeit bei Kampagnen. Wer nach dem Go-Live sechs Monate Betrieb gesammelt hat, sieht ein sehr konsistentes Muster in dem, was zuerst auf die Backlog-Liste rutscht.

Was ist der Sechs-Monats-Composable-Regret?

Composable Regret beschreibt die Lücke zwischen dem, was Teams sich vom Umstieg auf eine composable Architektur versprochen haben, und dem, was nach der ersten Betriebsphase tatsächlich zurückkommt. Der Begriff ist bewusst nicht auf die Entscheidungsphase gemünzt (dazu gibt es bereits 7 Readiness-Fragen vor dem Schritt in ein modulares Setup), sondern auf die Retrospektive: Was fällt auf, wenn die ersten zwei bis drei Release-Zyklen durch sind und das Team nicht mehr im Launch-Modus, sondern im Betriebsmodus arbeitet?

Composable-Architekturen entkoppeln Backend-Services (Commerce-Engine, PIM, Search, Payments) über APIs. Das Versprechen ist Flexibilität und Zukunftssicherheit. Das Problem ist: Die Entkopplung löst Backend-Probleme, aber sie erzeugt gleichzeitig eine neue Verantwortungsebene, die vorher implizit im Monolithen mitgelaufen ist - die Frontend-Ebene, die alle diese Services zu einer kohärenten Experience zusammenführt.

Das Problem, das viele Teams aktuell haben

In den ersten Wochen nach dem Go-Live steht die reine Funktionsfähigkeit im Vordergrund: Läuft der Checkout, funktioniert die Produktsuche, sind die Preise korrekt synchronisiert. Nach sechs Monaten verschiebt sich der Blick. Jetzt fragen Marketing- und Produktteams: Warum dauert eine neue Kampagnen-Landingpage drei Sprints? Warum ist die Core-Web-Vitals-Zahl seit dem Composable-Umstieg schlechter statt besser? Warum bricht die mobile Conversion-Rate im Vergleich zum alten Monolithen ein?

Der Kern des Problems: composable Backends sind für API-Verträge optimiert, nicht für Rendering-Performance oder Editor-Erfahrung. Wenn die Frontend-Schicht als Custom-Build direkt gegen fünf bis acht einzelne APIs entwickelt wurde, trägt jedes Team-Mitglied diese Integrationslast bei jeder Änderung mit. Das ist keine Ausnahme, sondern der Normalfall bei Composable-Setups ohne dedizierte Frontend-Management-Ebene - wir haben genau dieses Muster bereits in der Woche der 30-Minuten-Storefronts beschrieben: der schnelle Launch verdeckt die technische Schuld, die erst im Betrieb sichtbar wird.

Konkrete Symptome, die uns in Gesprächen mit Teams sechs Monate nach dem Umstieg immer wieder begegnen:

• Landingpage-Änderungen brauchen einen Pull-Request und Code-Review, obwohl es sich um reinen Marketing-Content handelt
• LCP-Werte liegen bei 3,5 bis 5 Sekunden, weil jede Komponente eigene API-Calls gegen unterschiedliche Backends fährt
• Zwei parallele Storefronts (DE und EN, oder zwei Marken) laufen auf leicht unterschiedlichem Component-Code, weil es keine zentrale UI-Bibliothek gibt
• A/B-Tests sind technisch möglich, aber jeder Test braucht ein eigenes Feature-Branch und einen eigenen Deploy

Warum die Frontend-Ebene fast immer die erste Priorität wird

Composable Commerce zu entscheiden heißt nicht, dass das Projekt am Tag des Go-Live fertig ist. Der Backend-Teil - API-Verträge, Datenmodelle, Migrations - ist zu diesem Zeitpunkt tatsächlich weitgehend abgeschlossen. Was in den ersten sechs Betriebsmonaten reift, ist die Frontend-Ebene: Genau hier entsteht die tägliche Erfahrung für Kundinnen und Kunden, und genau hier entsteht die tägliche Arbeitslast für Marketing- und Produktteams.

Das ist exakt die These, auf der die Frontend Management Platform (FMP) als Kategorie aufbaut: composable Backend-Architektur braucht eine ebenso composable, aber eigenständig steuerbare Frontend-Schicht - nicht als nachträgliches Theme, sondern als Composable Digital Experience Platform, die zwischen Backend-Services und Endkunden-Erlebnis sitzt. Ohne diese Ebene bleibt jede Frontend-Änderung ein Custom-Engineering-Projekt, weil die Integrationslogik in jeder einzelnen Komponente neu gedacht werden muss.

Konkret heißt das für Laioutr: Wir verbinden uns mit dem bestehenden composable Backend-Stack über unseren Unified Data Layer (Orchestr), sodass Frontend-Komponenten ein einheitliches Datenmodell konsumieren, egal wie viele Backend-Services dahinter liegen. Das Team behält seine Backend-Entscheidung vollständig - Laioutr ersetzt keinen Commerce-Service - und bekommt für die Frontend-Ebene eine echte Steuerungsebene: Studio als visueller Editor für Marketing, eine zentrale UI-Library für Konsistenz über Marken und Märkte, und Performance-Optimierung als Plattform-Eigenschaft statt als Ad-hoc-Sprint. Wer nach sechs Monaten merkt, dass genau diese Frontend-Reife fehlt, ist auch der ideale Zeitpunkt, um sich die Agentic Frontend Management Platform als eigenständige Ebene oberhalb des bestehenden Composable-Stacks anzuschauen, statt weiter Custom-Code an einzelne Services zu kleben.

Was Du gewinnst

• Dimension: Zeit / Sechs Monate nach Composable-Go-Live (Custom-Frontend): 2-3 Sprints pro neuer Landingpage / Mit dedizierter Frontend-Ebene: Stunden bis 1-2 Tage, Marketing-Team baut selbst
• Dimension: Geld / Sechs Monate nach Composable-Go-Live (Custom-Frontend): Engineering-Kapazität für jede Frontend-Änderung gebunden / Mit dedizierter Frontend-Ebene: Engineering fokussiert auf Backend-/Integrationslogik
• Dimension: Qualität / Sechs Monate nach Composable-Go-Live (Custom-Frontend): LCP häufig über 3 Sekunden, uneinheitliche Komponenten pro Markt / Mit dedizierter Frontend-Ebene: LCP im Median unter 2 Sekunden, eine UI-Library für alle Storefronts

Konkrete Kennzahl zur Einordnung: Live-Frontends auf Laioutr liegen im Median bei einer LCP von 1,2 Sekunden (Feld-Daten Q2 2026) - das ist der Unterschied zwischen einer Frontend-Ebene, die als Plattform-Eigenschaft für Performance gebaut ist, und einer, die pro Komponente gegen mehrere APIs improvisiert. Das lässt sich mit der Performance-Produktseite konkret nachvollziehen.

FAQ

Ist das ein Zeichen, dass die Composable-Entscheidung falsch war? Nein. Composable Commerce löst reale Backend-Probleme - Vendor-Lock-in, unflexible Datenmodelle, fehlende API-Verträge. Der Regret sechs Monate später ist kein Rückzieher-Signal, sondern ein Reifesignal: Das Team merkt jetzt, welche Ebene beim Backend-fokussierten Umstieg mitgedacht werden muss.

Was kostet die Nachrüstung einer Frontend-Ebene? Das hängt vom Umfang ab. Sieh Dir die Preisübersicht an - typischerweise ist die Investition deutlich kleiner als ein zweites Replatforming-Projekt, weil das bestehende Backend unverändert bleibt.

Können wir das parallel zum laufenden Betrieb einführen? Ja. Die Frontend-Ebene wird über den Unified Data Layer an den bestehenden Stack angebunden, ohne den produktiven Checkout oder die Backend-Services zu unterbrechen. Migration läuft typischerweise Storefront-Sektion für Storefront-Sektion, nicht als Big-Bang.

Nächste Schritte

Wenn Dein Team gerade an dem Punkt steht, an dem die ersten Retro-Meetings nach dem Composable-Go-Live zeigen, dass die Frontend-Ebene der Flaschenhals ist: Buch eine 30-Minuten-Bestandsaufnahme und wir gehen gemeinsam durch, wo genau die Lücke zwischen Backend-Reife und Frontend-Reife in Deinem Setup liegt.

Weitere Themen aus der Laioutr-Plattform

• Composable Digital Experience Platform
• Agentic Frontend Management Platform
• Performance · Core Web Vitals

Über den Autor: Marcel Thiesies ist Co-Founder & CEO von Laioutr. Er baut die Frontend Management Platform, weil er in eigenen Projekten wiederholt gesehen hat, dass Backend-Composability allein die Frontend-Iterationsgeschwindigkeit nicht löst.