Wer besitzt den Storefront-Code? Die Rolle der Frontend-Entwickler:innen im Composable-Team

Frag zehn Frontend-Entwickler:innen, wer den Storefront-Code besitzt, und noch vor ein paar Jahren hättest du von allen dieselbe Antwort bekommen: sie selbst, von Anfang bis Ende. In einem Generation-4- / Frontend-as-a-Service-Betriebsmodell zerfällt diese eine Antwort in klar abgegrenzte Ownership-Bereiche. Eine Frontend Management Platform (FMP) nimmt Entwickler:innen nicht aus dem Storefront heraus, sie zieht die Linie neu zwischen dem, was Engineering einmal baut, und dem, was andere Rollen täglich damit arbeiten.

Warum sich die Ownership-Frage jetzt stellt

Ein composable Backend und ein composable Headless Frontend entkoppeln Präsentation von Commerce-Logik. Genau diese Entkopplung ist der Grund, warum die Frage überhaupt beantwortet werden muss: Sobald der Storefront eine eigene Schicht ist, muss trotzdem jemand sie besitzen, und „wer zuletzt im Repo war" funktioniert nicht mehr, sobald Marketing, Merchandising und Editor:innen alle in denselben Storefront publizieren. Im Composable-Team besitzt die Frontend-Entwicklerin oder der Frontend-Entwickler das System, das den Storefront rendert: Component-Contracts, Rendering-Strategie, Performance-Budget. Nicht jeden Headline-Wechsel oder Hero-Bild-Austausch, der diese Woche live geht.

Was Frontend-Entwickler:innen besitzen

• Das Design-System und die Komponentenbibliothek. Vue- oder Nuxt-Komponenten (je nach Stack auch Next.js), mit Prop-Schemas, die in TypeScript typisiert sind, sodass jede Section einen strikten, versionierten Contract hat.
• Die Integrationsschicht. defineSection- und defineBlock-Funktionen machen Sections als konfigurierbares Schema für Nicht-Entwickler:innen nutzbar; die Orchestr-Schicht verdrahtet Daten, GraphQL-Queries und Hooks in diese Sections, ohne dass die Seite neu gebaut werden muss.
• Rendering-Entscheidungen. SSR versus SSG pro Route, Hydration-Strategie und die Gesundheit der CI/CD-Pipeline liegen bei Engineering, nicht bei wem auch immer heute gerade eine Seite publiziert.
• Core Web Vitals als SLA. LCP-, CLS- und INP-Budgets werden pro Release getrackt, nicht erst geprüft, nachdem eine Marketing-Kampagne schon live gegangen ist.
• Storybook als Contract-Fläche. Jede Section kommt dokumentiert, mit ihren erlaubten Props und Zuständen sichtbar, bevor sie bei Editor:innen ankommt.

Was Frontend-Entwickler:innen nicht besitzen

Sobald eine Section mit gesperrtem Schema und Storybook-Eintrag live ist, gehören tägliche Änderungen an Headlines, Bildern und Section-Reihenfolge Editor:innen, nicht einem Pull Request. Unser Beitrag zur Editor-Persona betrachtet dieselbe Grenze von der anderen Seite: was Editor:innen besitzen, sobald Engineering das Schema definiert hat, und wo ein KI-Copilot bei Merchandising und Content-Änderungen ansetzt, ohne den Komponenten-Code anzufassen.

Developer-Ownership versus Editor-Ownership

• Bereich | Frontend-Entwickler:in besitzt | Editor:in besitzt
• Component-Contracts und Prop-Schemas | Definiert und versioniert in TypeScript | Nutzt sie über das Editor-UI
• Section-Verdrahtung (defineSection/defineBlock, Orchestr) | Baut und pflegt | Für diese Rolle nicht sichtbar
• Headlines, Bilder, Text, Section-Reihenfolge | Prüft nur, wenn sich das Schema ändert | Editiert direkt, publiziert
• Core Web Vitals (LCP, CLS, INP) | Besitzt als Engineering-SLA | Erbt automatisch
• Komponentenbibliothek und Storybook | Dokumentiert und liefert aus | Liest, um zu sehen, was verfügbar ist
• Neue Section-Typen | Baut einmalig | Fragt an, baut nicht selbst

Wo sich die beiden Rollen treffen

Eine agentic frontend management platform ist genau auf diese Nahtstelle gebaut. Engineering liefert eine Section einmal aus, Props gesperrt und Daten-Contract typisiert, und sie wird über jede Locale und jede Kampagne hinweg wiederverwendbar, ohne einen zweiten Pull Request. Das ist auch die Prämisse hinter Frontend as a Service als Betriebsmodell: Die Storefront-Schicht wird zentral gepflegt, sodass sich Ownership nach Rolle aufteilen lässt statt nach Ticket. Einen genaueren Blick darauf, was der Stack im Alltag von Engineering verlangt, gibt unser Developer-Persona-Guide: Komponentenmodell, defineSection/defineBlock-APIs, Orchestr für Daten, durchgängig TypeScript, Storybook und Core Web Vitals von Haus aus.

FAQ

Braucht ein Composable-Team überhaupt noch Frontend-Entwickler:innen? Ja. Sie besitzen das System, das den Storefront rendert: Komponenten, Integrationsschicht, Rendering-Strategie und Performance. Was sich ändert: Sie sind nicht mehr die einzigen, die eine Content-Änderung live bringen können.

Was bedeutet „die Integrationsschicht besitzen" konkret? Es bedeutet, die defineSection/defineBlock-Funktionen und die Orchestr-Verdrahtung zu bauen und zu pflegen, die aus einer Komponente eine schemagesteuerte, editor-sichere Section machen, inklusive ihrer GraphQL-Queries und Hooks.

Wer ist für Core Web Vitals verantwortlich? Die Frontend-Entwickler:innen, als Engineering-SLA pro Release getrackt (LCP, CLS, INP), nicht als etwas, das erst geprüft wird, nachdem eine Kampagnenseite schon live ist.

Ist das dasselbe wie die Editor-Rolle? Nein. Frontend-Entwickler:innen besitzen das System und seine Contracts, Editor:innen arbeiten innerhalb dieser Contracts, um Content zu publizieren. Die andere Seite dieser Aufteilung zeigt unser Beitrag zur Editor-Persona.

Ersetzt das eine klassische Frontend-Engineering-Rolle? Nein, es grenzt sie präziser ab. Entwickler:innen besitzen weiterhin die Codebase, den Stack (Nuxt, Vue oder Next.js, TypeScript, GraphQL), CI/CD und Storybook. Was aus ihrer Warteschlange verschwindet, ist die laufende Content-Publikation.

Nächster Schritt

Wenn du gerade prüfst, wie die Developer-Rolle in einem Composable-Team aussieht, schau dir unseren Developer-Persona-Guide mit der vollständigen Stack-Aufschlüsselung an.