Multi-Brand Magento on One Frontend: A Showcase

If you run a brand portfolio on Magento or Adobe Commerce, you already know the pattern: every brand gets its own theme, its own front-end team backlog, and its own release cycle. A new campaign hero shipped to Brand A never reaches Brand B without a second build. This showcase walks through what the setup looks like when a single shared frontend serves all of them, without per-brand rebuilds and without migrating off Magento. We covered the consolidation case earlier in one frontend for multiple Magento stores; here we show the architecture in practice.

The showcase setup: three brands, one frontend layer

To keep this concrete, picture an illustrative portfolio: a mid-market group running three consumer brands. All three sit on the same Magento backend, modelled as Magento's native hierarchy of websites, stores, and store views. Historically each brand carried a separate frontend theme, so a shared feature like a size-guide component or a new checkout upsell was built three times. The goal of the showcase is simple: keep the Magento backend exactly as it is, and put one shared frontend layer in front of all three brand storefronts.

The numbers and brands here are illustrative, chosen to show the mechanics rather than to report a specific customer result.

The architecture: shared frontend, many store views

The shared frontend connects to Magento's GraphQL API and reads the existing website, store, and store-view structure directly. Each brand storefront maps to a store view, so catalog scope, pricing, currency, and language stay wherever they already live in Magento. Nothing about the product data model changes.

What changes is the presentation layer. Instead of three themes maintained in parallel, there is one component library and one content model, with a brand context resolved per request. A visitor landing on Brand A's domain gets Brand A's theme tokens, catalog scope, and content, all served from the same frontend deployment. This is the Frontend as a Service operating model applied to a brand portfolio: the storefront is composed and operated centrally, on top of the commerce backend you already run. The headless frontend for Magento 2 and Adobe Commerce paths are the same architecture, differing only in which backend edition supplies the data.

Brand theming: one component library, per-brand tokens

The theming layer is where the multi-brand payoff shows up. Each brand is a token set: colours, typography, spacing, logo, and imagery rules, plus any brand-specific component variants. A product card is one component in the library; Brand A renders it with its own tokens, Brand B with its own, and neither brand needs a forked component to do it.

This keeps design consistency enforceable rather than aspirational. When the group updates the size-guide component, the change lands once and every brand inherits it, each in its own visual identity. Brand consistency becomes a property of the shared library instead of a manual checklist repeated per theme. We went deeper on the design-token mechanics in brand consistency across multi-brand storefronts.

Shared components, brand-specific data

A shared component is not a locked component. Each brand storefront binds the same component to its own data and content. The hero on the homepage is the same building block across brands, but the campaign, imagery, and copy are set per brand in the content model. The product listing reads each brand's store-view scope, so catalog and pricing stay correct without any per-brand code.

The practical result: a marketer working on Brand B composes a landing page from the shared library, in Brand B's theme, using Brand B's catalog, without opening a developer ticket and without touching the other two brands. That editor-level control across a portfolio is the core of multi-brand and multi-market from one system, and we walked through the single-system model in multi-brand and multi-market from a single system.

Governance: who owns what

Running many brands from one frontend only stays sane with clear ownership. In the showcase, the split looks like this:

• Component library. Owner: Central frontend team. Scope: Shared building blocks, accessibility, performance budgets.
• Brand tokens. Owner: Brand design leads. Scope: Colours, type, logo, imagery per brand.
• Content and campaigns. Owner: Brand marketers. Scope: Per-brand pages, heroes, copy, within the shared library.
• Catalog and pricing. Owner: Existing Magento setup. Scope: Unchanged, per store view.

The central team owns the shared foundation once, so performance and accessibility rules apply to every brand by default. Brand teams own what makes their storefront theirs, and cannot accidentally break another brand, because they work inside tokens and content, not forked code.

What launching a fourth brand looks like

Because the foundation is shared, adding a brand is mostly configuration rather than a new build. The steps in the showcase: add the new brand's store view in Magento if it does not exist yet, define a token set for the brand, map the domain, and compose the launch pages from the existing library. The new brand inherits the component library, the performance budget, and the accessibility baseline from day one, instead of starting from an empty theme.

Where this sits next to the consolidation story

The earlier consolidation post answered why a portfolio would move to a single frontend without migrating the backend. This showcase answers the follow-up question a buyer asks next: what does the running system actually look like, and who touches which part. Same architecture, different lens, operations rather than rationale.

FAQ

Does this require migrating off Magento or Adobe Commerce? No. The shared frontend reads Magento's existing GraphQL API and store-view structure. The backend, catalog, and pricing stay where they are.

How is each brand kept visually distinct? Each brand is a token set applied to a shared component library. Same components, different colours, type, logos, and imagery, resolved per brand at request time.

Can brand marketers work independently? Yes. Each brand's editors compose pages from the shared library in their own theme and catalog scope, without developer tickets and without affecting other brands.

Does a shared component mean shared content? No. Components are shared; the data and content bound to them are per brand, set in the content model and read from each store view.

Next step

Want to see this mapped to your own brand portfolio on Magento or Adobe Commerce? Talk to the Laioutr team and we will sketch the shared frontend layer for your stores.