Unternehmen wachsen oft in Portfolios: Eine Gruppe, mehrere Tochterfirmen, unterschiedliche Zielgruppen, separate Webauftritte. Die klassische Antwort ist, für jede Marke eine eigene Website zu bauen — mit allen Folgekosten in Entwicklung, Betrieb und Redaktion. Die moderne Antwort: Ein technischer Kern, mehrere Marken-Overlays.
Das Prinzip in zwei Sätzen
Alle Marken nutzen denselben Renderer, dieselbe Infrastruktur, dieselben Content-Typen. Was sich unterscheidet, sind: Design-Tokens (Farben, Typografie, Assets), Inhalte (Seiten, Blog-Posts, Meta-Daten) und Domain-Zuordnung.
Alles andere — Architektur, Deployment, Sicherheit — ist geteilt. Ein Kritik-Patch an der Auth-Logik geht gleichzeitig auf alle Marken. Ein neuer Content-Typ steht für alle bereit. Ein Performance-Fix wirkt überall.
Brand-Tokens als Fundament
Die Trennung beginnt bei den Design-Tokens. Jede Marke hat ihre eigene brand.json mit Farben, Font-Familien, Logo-Referenzen, Spacing-Präferenzen. Beim Build wird daraus eine brand.css mit CSS-Custom-Properties erzeugt.
Im Frontend nutzen alle Komponenten ausschließlich diese CSS-Variablen. var(--brand-primary) statt #2563eb. Beim Domain-Routing wird die richtige brand.css geladen — das Styling passt sich automatisch an.
Content-Inheritance mit Override
Viele Inhalte (Impressum, Datenschutz, "Über uns"-Grundstruktur) sind über Marken hinweg fast identisch. Wir lösen das über ein _template-Brand, das als Basis dient. Jede konkrete Marke erbt aus _template und überschreibt nur die Unterschiede.
Technisch: Bei jedem Page-Load wird erst die Template-Seite geladen, dann mit den brand-spezifischen Overrides gemergt. Fehlen Overrides, bleibt der Template-Inhalt. Das senkt die Pflege-Last dramatisch — neue Marken starten mit einer kompletten Website und passen inkrementell an.
Die Grenzen des Ansatzes
Nicht jede Marke passt in den geteilten Stack. Wir lehnen Multi-Brand ab, wenn:
- Die Marken fundamental unterschiedliche Content-Typen brauchen (z.B. E-Commerce vs. Pure-Corporate).
- Die Designs so stark voneinander abweichen, dass gemeinsame Komponenten nicht mehr funktionieren.
- Die Release-Zyklen aus politischen Gründen getrennt sein müssen.
Diese Kriterien sind selten. In 80% der Multi-Brand-Konstellationen ist der geteilte Stack der richtige Weg.
Domain-Routing
Der letzte Baustein ist das Routing. Wir nutzen Keycloak mit domain-basierten Realm-Selektoren — ein Request auf efexcon.com landet im efexcon-group-Realm, efexcon.swiss bei efexcon-ag. Die gleiche Logik bestimmt, welcher Brand-Overlay geladen wird.
Das klingt simpel, ist in der Praxis aber die Stelle, an der die meisten Multi-Brand-Setups zerbrechen — weil die Zuordnung Brand ↔ Domain an zu vielen Stellen dupliziert wird (DNS, Keycloak, App-Konfig, Build-System). Unsere Regel: Eine einzige Source of Truth (eine domains.json), alle anderen Systeme leiten sich daraus ab.
Ergebnis nach zwei Jahren
Wir betreiben aktuell vier Marken in einem Stack. Ein durchschnittliches Deploy kostet uns 8 Minuten — unabhängig davon, ob eine, zwei oder alle vier Marken betroffen sind. Ein neues Brand-Rollout (Farben, Logo, Content-Import, Domain-Setup) dauert typischerweise 3 Arbeitstage.
Die Kosten pro Marke sinken, je mehr Marken man hinzufügt. Das ist das Geschäftsmodell-Argument, das in Boardrooms funktioniert.