Multi Brand Design Systems

Introduction

Multi-brand design systems serve one codebase with multiple visual identities — holding company portfolios, franchise networks, or B2B2C platforms. Architecture: shared primitives and components, brand-specific semantic token overlays, and runtime or build-time brand resolution per tenant, domain, or route.

Staff pattern: one Button component, N brand token JSON files — not N forked button SCSS files.

Business problem

Business pressure: Media conglomerate launches 8th streaming brand — engineering cannot clone the app 8 times. Multi-brand DS ships feature once, themes per brand from token overlay.

• M&A: Acquire brand, add token file, not rewrite app.
• Partner: Co-branded experiences with partner palette.
• QA: Visual regression per brand on shared components.

Why this feature exists

Platform history: White-label SaaS and franchise portals drove token overlay architectures before CSS variables made runtime swap practical.

• Problem solved: Forked codebases per brand.
• Reference: Carbon themes as multi-theme example; Material brand customization.

Browser rendering perspective

Rendering impact: Runtime brand = load one semantic overlay JSON + apply custom properties — faster than swapping CSS files. Build-time per-brand bundles maximize cache isolation per domain.

Internal browser workflow

Resolution: Detect brand from hostname / tenant id → load brand tokens → set data-brand on html → components unchanged.

Feature deep dive

Token overlay stack:

/* base semantic */
:root { --color-interactive: #4f46e5; }

/* brand-a overlay */
[data-brand="a"] { --color-interactive: #e11d48; }

/* brand-b overlay */
[data-brand="b"] { --color-interactive: #059669; }

/* shared component */
.cta { background: var(--color-interactive); }

Syntax

Build-time: separate CSS entry per brand importing same components. Runtime: fetch tenant theme API → inject variables.

Examples

Chromatic per brand: Storybook globalTypes brand switcher runs snapshots for each data-brand.

Real-world use

Warner Bros Discovery multi-brand streaming UIs. Franchise quick-service restaurant ordering with per-franchise colors. Enterprise SaaS with customer-branded portals.

Real production example

Pattern: brands/ folder with token JSON; CI matrix builds all brands; E2E per brand smoke.

Enterprise use case

Enterprise: Carbon multi-theme (@carbon/themes). Atlassian limited multi-brand — product skins within ADS constraints.

Accessibility considerations

A11y: Each brand overlay must pass contrast CI — partner brand cannot ship illegible colors.

Performance considerations

Performance: Runtime overlay small JSON; build-time N bundles — CDN cache per domain.

SEO considerations

SEO: Each brand domain needs correct favicon, theme-color meta from brand tokens.

Scalability considerations

Scale: 50 brands — automate token generation from brand portal; manual JSON does not scale.

Common production issues

Failures: Brand logo SVG hardcoded blue — ignores token. One brand needs unique layout — exception becomes fork.

Debugging guide

Debug: Verify data-brand on html matches tenant; missing overlay falls back to default visibly wrong.

Best practices

• Shared components never brand-specific branches.
• Contrast CI per brand overlay.
• Storybook brand switcher for all stories.

Anti-patterns

• if (brand === 'x') className in every component.
• Separate npm package per brand duplicating components.

Trade-offs

• Runtime overlay: one bundle, flexible.
• Build per brand: cache isolation, larger CI matrix.

Architecture review questions

• Brand-specific layout exceptions documented?
• Chromatic covers all brands?

Interview questions

Hands-on exercise

Exercise: Two brand overlays on one card component; Storybook switcher; contrast check both.

Staff engineer notes

• Multi-brand fails when marketing exceptions bypass token overlay — govern exceptions with ADR.

Common pitfalls

• Brand-specific React branches — scales linearly with brands.

Try it yourself

Edit the CSS panel — the preview updates live. Use DevTools Performance and Accessibility panels to validate.

Summary

Multi-brand design systems share components while swapping semantic token overlays — avoiding forked codebases across portfolio brands.

Key takeaways

• Shared components + per-brand token overlays.
• CI visual and contrast per brand.