Es ist Ende Juli. Black Friday ist der 27. November 2026, Cyber Monday der 30. Das klingt nach reich…
Wer baut das Frontend? Rollen in einem Composable-Commerce-Team
Frage zehn Leute in einem Commerce-Team, wer das Frontend ownt, und du bekommst zehn verschiedene Antworten. Marketing sagt, es sei das Dev-Team. Dev sagt, es sei das Design-System. Der Product Owner sagt, es hänge von der Roadmap ab. In einem Composable-Commerce-Stack ist das keine Zuständigkeits-Frage am Rande, sondern der eigentliche Engpass. Das Frontend hat keinen einzelnen Besitzer. Es hat vier, und der Wert entsteht erst, wenn klar ist, wer welchen Teil in der Hand hält.
Dieser Beitrag ist der Einstieg in die Rollen-Sicht: welche vier Rollen das Frontend anfassen, wo Ownership in einem klassischen Setup auseinanderbricht, und wie eine Frontend Management Platform (FMP) die Verantwortung sauber schneidet, statt sie in eine Ticket-Queue zu verschieben.
Warum das Frontend keinen einzelnen Besitzer hat
In einem monolithischen Shop war die Antwort einfach: Das Frontend gehörte dem Backend. Template-Sprache, Theme-Layer und Business-Logik lagen im selben System, und wer das System betreute, betreute auch die Storefront. Composable dreht das um. Das Frontend wird zu einer eigenen Ebene, entkoppelt vom Backend, angebunden an mehrere Systeme über eine Datenschicht. Diese Entkopplung ist genau der Gewinn, denn sie erlaubt es, das Backend zu tauschen, ohne die Storefront neu zu bauen. Sie erzeugt aber auch eine offene Frage, die der Monolith nie stellen musste: Wenn das Frontend niemandem im Backend mehr gehört, wem gehört es dann?
Die ehrliche Antwort ist, dass es sich vier Rollen teilen. Und solange diese Teilung nicht ausgesprochen ist, füllt sie sich mit der Standard-Antwort jedes Tech-Teams: Alles, was das Frontend berührt, wird zu einem Entwickler-Ticket. Genau das ist der Punkt, an dem Composable-Teams langsamer werden, statt schneller.
Die vier Rollen, die das Frontend anfassen
Eine Storefront wird nicht von einer Person gebaut, sondern in einer Kette von Entscheidungen, die vier unterschiedliche Rollen treffen.
Marketing und E-Commerce besitzen den Ausgang: Kampagnenseiten, Landingpages, Kategorie-Inszenierung, saisonale Umbauten, die konkrete Reihenfolge der Blöcke auf einer Seite. Diese Rolle wird am Umsatz gemessen und arbeitet in Tagen, nicht in Sprints. Was sie braucht, ist die Fähigkeit, eine Seite selbst zu komponieren und live zu schalten, ohne auf ein Release-Fenster zu warten. Die Rollen-Perspektive dazu steht auf Laioutr für Marketing Manager.
Der Product Owner besitzt die Priorisierung: welche Templates existieren, welche Features als Nächstes kommen, wo die Grenze zwischen Standard-Baustein und Sonderfall liegt. Diese Rolle übersetzt zwischen Business-Wunsch und technischer Realität und entscheidet, was ins Komponenten-System gehört und was ein Einzelfall bleibt.
Development besitzt das Fundament: die Komponenten selbst, die Datenanbindung, die Guardrails, innerhalb derer alle anderen arbeiten. Diese Rolle baut nicht jede Seite, sondern das System, aus dem Seiten gebaut werden. Wenn dieses Fundament sauber ist, hört das Team auf, Entwickler für Banner-Änderungen zu blockieren. Die Sicht dieser Rolle steht auf Laioutr für Developer.
Architektur besitzt den Vertrag: wie die Datenschicht die Backends normalisiert, wie Themes und Design-Tokens über Marken und Märkte hinweg konsistent bleiben, wie das Frontend performant und barrierefrei ab Werk ist. Diese Rolle ist selten in der täglichen Seiten-Arbeit sichtbar, entscheidet aber, ob das ganze Modell über mehrere Storefronts trägt.
Dazu kommen zwei angrenzende Rollen, die je nach Team-Größe eigenständig oder Teil der oberen vier sind: Die Redaktion pflegt Inhalte im Live-Kontext, siehe Laioutr für Content Manager, und der Conversion-fokussierte Part testet und optimiert, siehe Laioutr für CRO-Spezialisten. Das Design-System-Handoff selbst liegt bei UX/UI Designer, wo Tokens und Komponenten ohne Verlust zwischen Design und Code wandern sollen.
Wo Ownership in einem klassischen Setup auseinanderbricht
Der übliche Bruch ist kein böser Wille, sondern eine fehlende Trennung. In einem klassischen Custom-Build-Frontend gibt es keine saubere Grenze zwischen "das ist ein Baustein, den Marketing selbst zusammensetzt" und "das ist Code, der ein Development-Ticket braucht". Weil die Grenze fehlt, wandert alles auf die sichere Seite: ins Ticket. Eine Headline-Änderung, eine neue Kampagnenseite, ein Umbau der Kategorie-Reihenfolge, alles landet in derselben Queue wie echte Feature-Arbeit.
Das Ergebnis ist ein doppelter Verlust. Marketing wartet auf Kapazität, die es nicht steuern kann, und Development verbringt Zeit mit Arbeit, die eigentlich niemand als Entwicklungsarbeit bezeichnen würde. Wie sich dieser Stau auflöst, wenn die Trennung stimmt, haben wir an anderer Stelle beschrieben: vom Dev-Bottleneck zum Frontend-Flow im ganzen Team. Der Kern für diesen Beitrag ist einfacher: Unklare Ownership ist teurer als jede einzelne technische Entscheidung im Stack.
Wie eine FMP die Verantwortung sauber schneidet
Eine Frontend Management Platform löst das Ownership-Problem nicht dadurch, dass sie eine Rolle zur Chefin über alle macht, sondern dadurch, dass sie jeder Rolle eine eigene, nicht überlappende Ebene gibt. Das Prinzip ist ein Vertrag zwischen Development und den Business-Rollen.
Development definiert die Komponenten und die Guardrails einmal: Was ist ein erlaubter Baustein, welche Slots hat er, welche Daten zieht er. Marketing und Redaktion komponieren daraus Seiten in einem Live-Editor mit Vorschau, ohne Code anzufassen und ohne ein Release zu blockieren. Architektur ownt die Datenschicht darunter, die die Backends normalisiert, und den Theme-Layer, der Marken und Märkte konsistent hält. Jede Rolle arbeitet in ihrer Ebene, und keine wartet auf die andere für Routine-Arbeit.
Genau das ist die Idee hinter Frontend as a Service: Studio, Storefront, Connect-Schicht und Cloud arbeiten als ein gemanagtes System, in dem die Trennung der Verantwortung eingebaut ist statt bei jedem Projekt neu verhandelt zu werden. Wenn du den Begriff selbst neu einordnen willst, haben wir was Frontend as a Service eigentlich ist separat aufgeschrieben. Auf Plattform-Ebene ist derselbe Gedanke die Composable Digital Experience Platform: ein Frontend-Layer, der über allen Backends sitzt und die vier Rollen an einem Ort zusammenführt, ohne sie in dieselbe Queue zu zwingen.
Der Ownership-Schnitt in einem Satz pro Rolle
Wenn du das Modell in einem Team verankern willst, reicht ein Satz pro Rolle. Development ownt Komponenten und Guardrails. Der Product Owner ownt, was ins System gehört und in welcher Reihenfolge. Marketing und E-Commerce ownen die Komposition und den Go-Live von Seiten. Architektur ownt die Datenschicht und den Theme-Vertrag über Marken und Märkte. Niemand wartet auf jemand anderen, um seine Kern-Arbeit zu tun. Das ist der Test dafür, ob die Ownership sauber ist.
FAQ
Wer sollte in einem Composable-Team das Frontend besitzen? Keine einzelne Rolle. Development besitzt die Komponenten und Guardrails, Marketing und E-Commerce besitzen die Komposition und den Go-Live von Seiten, der Product Owner besitzt die Priorisierung, Architektur besitzt die Datenschicht und den Theme-Vertrag. Der Fehler ist, alles einer Rolle zu geben, meist unbeabsichtigt dem Dev-Team über die Ticket-Queue.
Was ändert eine Frontend Management Platform an der Rollen-Verteilung? Sie macht die Trennung explizit. Development definiert Komponenten und Regeln einmal, die Business-Rollen komponieren daraus Seiten in einem Live-Editor. Routine-Änderungen brauchen kein Development-Ticket mehr, und Development gewinnt Zeit für echte System-Arbeit zurück.
Braucht ein kleines Team wirklich vier getrennte Rollen? Die vier Rollen sind Verantwortungen, keine vier Personen. In einem kleinen Team kann eine Person mehrere Rollen tragen. Wichtig ist, dass die Verantwortungen benannt sind, damit nicht standardmäßig alles zum Entwickler-Ticket wird.
Nächste Schritte
Wenn in deinem Team die Frage "wer baut das eigentlich" bei jeder neuen Seite neu aufkommt, ist das kein Personal-Problem, sondern ein fehlender Ownership-Schnitt. Der schnellste Weg, ihn zu testen, ist ein Blick auf die Plattform-Ebene, auf der die Rollen bereits getrennt sind. Sieh dir die Plattform-Preise an oder sprich mit uns darüber, wie der Schnitt in deinem konkreten Setup aussehen würde.