Companies often grow into portfolios: a parent group, several subsidiaries, different audiences, separate web presences. The classic answer is to build a dedicated website for each brand — with all the follow-up costs in development, operations, and editorial work. The modern answer: one technical core, multiple brand overlays.
The principle in two sentences
All brands use the same renderer, the same infrastructure, the same content types. What differs is: design tokens (colors, typography, assets), content (pages, blog posts, metadata), and domain assignment.
Everything else — architecture, deployment, security — is shared. A critical patch to the auth logic ships to all brands at once. A new content type becomes available everywhere. A performance fix takes effect across the board.
Brand tokens as the foundation
The separation starts with design tokens. Each brand has its own brand.json with colors, font families, logo references, spacing preferences. At build time, this becomes a brand.css with CSS custom properties.
In the frontend, all components use these CSS variables exclusively. var(--brand-primary) instead of #2563eb. During domain routing, the correct brand.css is loaded — styling adapts automatically.
Content inheritance with override
Many pieces of content (imprint, privacy policy, "About" page basics) are nearly identical across brands. We solve this with a _template brand that serves as the baseline. Each concrete brand inherits from _template and overrides only the differences.
Technically: on every page load, the template page is loaded first, then merged with the brand-specific overrides. If overrides are missing, the template content remains. This dramatically reduces maintenance load — new brands launch with a complete website and adapt incrementally.
The limits of the approach
Not every brand fits into a shared stack. We push back on multi-brand when:
- The brands fundamentally need different content types (e.g., e-commerce vs. pure corporate).
- The designs diverge so much that shared components no longer work.
- Release cycles must be separated for political reasons.
These criteria are rare. In 80% of multi-brand setups, the shared stack is the right choice.
Domain routing
The final building block is routing. We use Keycloak with domain-based realm selectors — a request to efexcon.com lands in the efexcon-group realm, efexcon.swiss in efexcon-ag. The same logic determines which brand overlay is loaded.
This sounds simple, but in practice it is the place where most multi-brand setups break — because the brand ↔ domain mapping is duplicated in too many places (DNS, Keycloak, app config, build system). Our rule: a single source of truth (one domains.json); all other systems derive from it.
Result after two years
We currently run four brands on one stack. An average deploy takes 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 goes down as you add more brands. That is the business-model argument that works in boardrooms.