Das Composable-Frontend-Loch: Wer besitzt die Frontend-Ebene?

In den meisten Composable-Commerce-Stacks besitzt niemand explizit das Frontend. Teams wählen PIM, OMS, Suche und Payment-Provider als klar abgegrenzte, Best-of-Breed-Bausteine aus, und die Storefront wird zu dem, was übrig bleibt: ein liegen gebliebener Next.js-Build, ein CMS-Template, das über seine eigentliche Aufgabe hinaus gedehnt wurde, oder das alte Monolith-Theme, das nie ersetzt wurde. Frontend as a Service schließt genau dieses Loch, indem die Frontend-Ebene zum gemanagten, besitzbaren Baustein des Stacks wird, nicht zum Nachgedanken.

Was ist das Composable-Frontend-Loch?

Composable Commerce verkauft sich über Best-of-Breed-Flexibilität: OMS austauschen, PIM behalten, neuen Such-Provider ergänzen, ohne komplettes Replatforming. Die meisten Vendor-Auswahlprozesse sind genau auf dieses Versprechen ausgelegt, und die meisten Lastenhefte spiegeln das. Sie fragen detailliert nach PIM-Datenmodellen, OMS-Orchestrierungslogik und Payment-Service-Provider-Abdeckung. Selten fragen sie, wer die Storefront baut, hostet und pflegt, für wie lange und mit welchem SLA.

Genau diese fehlende Frage ist das Composable-Frontend-Loch. Backend-Systeme im Composable-Stack werden als Produkte mit benannten Ownern beschafft, budgetiert und besetzt. Das Frontend dagegen wird häufig als Integrationsdetail behandelt, etwas, das ein Dev-Team einmal während der Migration zusammenbaut und danach still erbt, ohne erneuerte Budgetzeile, ohne Support-Modell, ohne klares Mandat, wer entscheidet, was als Nächstes live geht.

Woher das Loch kommt: Composable Regret in der Praxis

Das Loch zeigt sich am deutlichsten ein paar Monate nach dem Go-Live. Dieses Muster haben wir bereits im Reifegrad-Kater beschrieben, den Teams nach ihrem ersten Composable-Go-Live erleben: ein schneller erster Launch, gefolgt von der langsameren Erkenntnis, dass niemand den Frontend-Betrieb wirklich geplant hat. Component-Library-Pflege, Core-Web-Vitals-Regressionen und Multi-Locale-Sync brauchen alle einen Owner, und in vielen Composable-Projekten wurde dieser Owner nie benannt.

Das ist kein Backend-Problem. commercetools, Shopware und ähnliche Composable-ready-Plattformen tun genau das, was sie tun sollen: Sie stellen saubere APIs bereit und mischen sich nicht in Rendering-Entscheidungen ein. Das Frontend-Loch öffnet sich gerade deshalb, weil die Backend-Ebene bewusst keine Meinung dazu hat, wie die Storefront gebaut wird, ein Vorteil bei der Vendor-Auswahl und ein Risiko in dem Moment, in dem niemand die Frontend-Budgetzeile beansprucht.

Drei Wege, wie das Frontend ohne echten Owner endet

• Der liegen gebliebene Build. Wer während der Replatforming-Migration den MVP-Frontend geliefert hat, erbt ihn per Default, meist ohne die Kapazität oder das Mandat, ihn als Produkt zu betreiben.
• Das ausgeliehene CMS. Ein Page Builder oder CMS-Template wird über seine eigentliche Aufgabe hinaus gedehnt, um Commerce-Seiten zu rendern, für die es nie gebaut wurde, jede neue Landingpage oder PDP-Variante wird zum Workaround statt zum unterstützten Feature.
• Das eingefrorene Monolith-Theme. Das Backend wird composable, das Frontend bleibt exakt dort, wo es war, weil die Entkopplung der Storefront aus dem ursprünglichen Migrations-Zeitplan gestrichen wurde.

Alle drei Muster teilen dieselbe Ursache: Frontend-Ownership wurde nie so explizit vergeben wie Backend-Ownership.

Frontend as a Service: Das Loch schließen

Frontend as a Service behandelt das Frontend genauso, wie ein Composable-Stack seine übrigen Systeme behandelt: als betriebene, Backend-agnostische Ebene mit benanntem Owner, Support-Modell und Release-Rhythmus, statt als einmaliges Build-Projekt. Das Frontend verbindet sich mit deinem Composable-Backend der Wahl, zum Beispiel einem Headless Frontend für commercetools, und bleibt unabhängig deploybar, versioniert und überwacht, sodass es nicht zum unbesitzten Artefakt degradiert, sobald das Migrationsprojekt abgeschlossen ist.

Genau hier verdient sich die Frontend-Ebene auch ihren Platz in einer Composable Digital Experience Platform-Strategie: Das DXP-Gespräch deckt meist Content, Personalisierung und Channel-Orchestrierung ab, aber die Rendering-Ebene darunter braucht trotzdem einen expliziten Owner und ein Betriebsmodell. Und weil KI-Agenten inzwischen Storefronts direkt zusammensetzen und auslesen, wird ein betriebenes Frontend auch zu der Ebene, auf der eine Agentic Frontend Management Platform strukturierte Daten, Monitoring und Agent-taugliches Markup konsistent anwenden kann, statt es nachträglich auf ein Frontend aufzusetzen, das den ursprünglichen Build zufällig überlebt hat.

Was sich für dein Team ändert

• Dimension | Ohne benannten Frontend-Owner | Mit Frontend as a Service
• Neue Landingpage | Dev-Ticket, wartet hinter Backend-Arbeit | Editor, Stunden, keine Backlog-Kollision
• Core Web Vitals | Niemand überwacht sie, bis sie einbrechen | Owned, als Plattform-Metrik getrackt
• Backend-Wechsel | Frontend-Rewrite im Projektumfang enthalten | Frontend bleibt, nur der Connector ändert sich
• Budgetzeile | Im ursprünglichen Migrationsprojekt verankert, dann vergessen | Wiederkehrend, klar abgegrenzt, SLA-gestützt

FAQ

Ist das Frontend nicht einfach die letzte Meile einer Composable-Migration? Genau diese Annahme erzeugt das Loch. Backend-Systeme bekommen laufendes Budget und klare Owner, das Frontend, als Letzte-Meile-Detail behandelt, nicht, und die Betriebskosten zeigen sich später als ungeplante Dev-Zeit.

Heißt das, dass wir unser bestehendes Frontend-Framework ersetzen müssen? Nein. Frontend as a Service läuft in der Regel auf derselben Next.js- oder Nuxt-Basis, die dein Team bereits nutzt, was sich ändert, ist das Betriebsmodell darum herum, nicht zwangsläufig der Stack selbst.

Wer sollte diese Entscheidung treffen, Engineering oder Marketing? Beide, was Teil des Problems ist, das das Loch erzeugt. Eine gemanagte Frontend-Ebene gibt Engineering einen klaren technischen Owner und Marketing einen Self-Service-Editor, statt ein einzelnes Team zu zwingen, beide Rollen zu übernehmen.

Was kostet das im Vergleich zum Eigenbetrieb? Die Tarife hängen von Umfang und Backend-Komplexität ab. Der relevante Vergleich läuft nicht gegen "nichts tun", sondern gegen die laufenden, oft nicht budgetierten Kosten der Dev-Zeit, die in ein unbesitztes Frontend fließt.

Nächste Schritte

Wenn dein Composable-Stack für jedes System einen benannten Owner hat, außer für das, was deine Kunden tatsächlich sehen: Buch dir einen Frontend-Ownership-Review, und wir gehen gemeinsam durch, wo das Loch in deiner aktuellen Architektur sitzt und was es tatsächlich braucht, es zu schließen.

Über den Autor: Das Laioutr Team arbeitet täglich mit Composable-Commerce-Teams daran, eine unbesitzte Frontend-Ebene in ein betriebenes, Backend-agnostisches Frontend as a Service zu verwandeln.