Companies often grow in portfolios: one group, several subsidiaries, different target groups, separate websites. The classic answer is to build a separate website for each brand - with all the associated costs of development, operation and editing. The modern answer: one technical core, several brand overlays.
The principle in two sentences
All brands use the same renderer, the same infrastructure, the same content types. What differs are: Design tokens (colors, typography, assets), content (pages, blog posts, meta data) and domain mapping.
Everything else - architecture, deployment, security - is shared. A criticism patch of the auth logic is simultaneously applied to all brands. A new content type is available for everyone. A performance fix works everywhere.
Brand tokens as the foundation
The separation starts with the design tokens. Each brand has its own brand.json with colors, font families, logo references, spacing preferences. During the build, a brand.css with CSS custom properties is generated from this.
In the frontend, all components use these CSS variables exclusively. var(--brand-primary) instead of #2563eb. The correct brand.css is loaded during domain routing - the styling adapts automatically.
Content inheritance with override
A lot of content (imprint, data protection, "About us" basic structure) is almost identical across brands. We solve this using a _template brand that serves as the basis. Each specific brand inherits from _template and only overwrites the differences.
Technically: With every page load, the template page is loaded first and then merged with the brand-specific overrides. If overrides are missing, the template content remains. This dramatically reduces the maintenance load - new brands start with a complete website and adapt incrementally.
The limits of the approach
Not every brand fits into the split stack. We reject multi-brand when:
- The brands need fundamentally different content types (e.g. e-commerce vs. pure-corporate).
- The designs differ so much that common components no longer work.
- The release cycles have to be separate for political reasons.
These criteria are rare. In 80% of multi-brand constellations, the split stack is the right way to go.
Domain routing
The last building block is routing. We use Keycloak with domain-based realm selectors - a request to efexcon.com ends up in the efexcon-group realm, efexcon.swiss at efexcon-ag. The same logic determines which brand overlay is loaded.
This sounds simple, but in practice this is where most multi-brand setups break - because the brand ↔ domain assignment is duplicated in too many places (DNS, keycloak, app config, build system). Our rule: A single source of truth (a domains.json), all other systems are derived from it.
Result after two years
We currently operate four brands in one stack. An average deploy costs us 8 minutes - regardless of whether one, two or all four brands are affected. A new brand rollout (colors, logo, content import, domain setup) typically takes 3 working days.
The cost per brand decreases the more brands you add. This is the business model argument that works in boardrooms.