Who Builds the Frontend? Roles in a Composable Commerce Team

In a composable commerce stack, the backend is a set of services and the frontend is where all of them become one storefront a customer actually uses. That makes the frontend the busiest shared surface in the whole team, and the one place where role boundaries get blurry fast. This post is the overview of who does what: the developer and architect, the product and marketing owner, the merchandiser, the designer, and operations. It also names the layer that keeps those roles from colliding, so five people can work on the same storefront without stepping on each other.

The frontend is a team sport, not a job title

Most stack diagrams stop at the API. commercetools, Shopware, or a headless CMS deliver data; the storefront turns that data into pages, campaigns, and a checkout. The mistake many teams make is assuming one role owns that layer. In practice, at least five roles write to it every week, and the friction is rarely about talent. It is about unclear ownership: who can publish a hero banner, who signs off on a component change, who is accountable when a page regresses on Core Web Vitals. Naming the roles is the first step to drawing those lines.

The five roles that touch the storefront

Developer and architect

The developer and architect own the building blocks: components, data bindings, and the integration to the commerce and content backends. In a composable headless frontend, that means defining reusable sections and blocks, wiring them to the right service, and keeping the type contracts stable so nothing downstream breaks. What they should not be doing is fielding a ticket every time marketing wants to move a banner. Their job is the system, not the daily edit.

Product and marketing owner

The product owner decides what the storefront should do and in what order, translating business goals into a roadmap for pages, flows, and campaigns. The marketing manager runs the campaign layer on top: landing pages, seasonal pushes, and the copy that goes live this week. Both need to compose and publish from approved components without a developer ticket. When they cannot, the roadmap stalls behind engineering capacity, which is the most common reason composable projects feel slow after go-live.

Merchandiser

The merchandiser owns what shoppers see and in what order: product placement, category curation, search and discovery, and the conversion levers on the page. This role sits closest to revenue and often overlaps with the CRO specialist, who runs the experiments and personalization that turn placement decisions into measured lift. Merchandising is a frontend job, because it lives in the presentation layer, not in the catalog service that stores the data.

Designer

The UX and UI designer owns brand consistency and the interaction patterns across every page. In a composable setup, the risk is design drift: ten teams building ten slightly different button states. The designer's real leverage is the component library and design tokens, so a decision made once shows up everywhere. That only works if the storefront actually consumes the same tokens the designer defines, instead of a separate handoff that decays over time.

Operations

Operations rarely appears on a role diagram, but someone runs performance budgets, accessibility compliance, locale sync, and the release process. In many teams this is split across the content manager for editorial governance and a platform or DevOps function for uptime and Core Web Vitals. Ops is the role that notices when a well-meaning edit ships a 2.4 second LCP, and the role that needs the guardrails to catch it before a customer does.

Where ownership usually breaks

The pattern is predictable. Marketing waits on developers for edits that should be self-serve. Developers get pulled off the roadmap to fix content typos. Ops finds regressions after they ship because nothing checked the performance budget at publish time. Each of these is an ownership gap, not a skills gap. We wrote about the accountability side in the RACI most teams skip after go-live, and the strategic version of the question in who owns the storefront.

Frontend Management as the shared layer

The fix is not adding a sixth role. It is giving the five a shared operating layer so each works at the right altitude. Frontend as a Service is Laioutr's name for that layer: developers define components and data bindings once, then product, marketing, and merchandising compose and publish from those components through content management without a deploy. The designer's tokens are the same tokens the storefront renders. Performance budgets and accessibility rules apply to every edit, whoever makes it, so ops gets guardrails instead of after-the-fact cleanup.

Who does what

• Developer and architect. Owns: Components, data bindings, integrations. Works in: Code, schema, the component library.
• Product and marketing owner. Owns: Roadmap, campaigns, published pages. Works in: Composition, no deploy needed.
• Merchandiser. Owns: Placement, discovery, conversion levers. Works in: Presentation layer, experiments.
• Designer. Owns: Brand consistency, interaction patterns. Works in: Design tokens, component library.
• Operations. Owns: Performance, accessibility, releases. Works in: Guardrails, monitoring, governance.

How to map this to your team

1. Name the owner for each surface. Components, pages, campaigns, merchandising, and release each need one accountable role, not a shared inbox.
2. Separate the system from the edit. Developers own how a component works; the people who use it daily should not need a ticket to change its content.
3. Make the guardrails automatic. Performance and accessibility budgets should apply at publish time, so ownership does not depend on someone remembering to check.

FAQ

Who owns the frontend in a composable commerce team? No single role. Developers own components and integrations; product, marketing, and merchandising own what gets composed and published; the designer owns consistency; ops owns performance and releases. A shared layer keeps those lines clean.

Is merchandising a frontend role or a backend role? Frontend. Placement, discovery, and conversion levers live in the presentation layer. The catalog service stores the data, but the decisions about what shoppers see happen on the storefront.

How is this different from a design system alone? A design system defines the components. Frontend Management is where every role uses them: composing, publishing, merchandising, and shipping against the same tokens, budgets, and rules.

Next step

Want to map these five roles onto your own team and storefront? Talk to the Laioutr team and we will walk through where each role works and where the shared layer removes the friction.