Multi-Brand Platform
A configuration-driven platform that serves many branded products from a single codebase — theme tokens, feature flags, and per-brand config instead of a fork per client.
Problem
Each new brand looked like a reason to fork the product. The trouble is that a fork per client doesn't stay one extra codebase — it becomes many, each drifting from the others, each needing the same fix applied separately. The real cost of "one more brand" was the cost of maintaining one more parallel product, forever.
Approach
Rather than fork, I led a single configuration-driven codebase where the things that differ between brands are data, not code. Appearance is driven by theme tokens, so a brand supplies its own colours, typography, and spacing without touching components. Capabilities are gated by feature flags, so a brand turns parts of the product on or off without a separate build. And per-brand specifics come from a dedicated configuration layer rather than branching logic scattered through the app. A new brand is set up and configured — not forked.
- One configuration-driven codebase (no fork per client)
- Theme tokens for brand appearance
- Feature flags for per-brand capabilities
- A dedicated per-brand configuration layer
- A clear line between configuration and custom code
What made it hard
The hardest part wasn't theming itself. It was deciding where the boundary should sit between configuration and custom development.
And the difficult part was that every request could be justified. Each brand had a legitimate reason for wanting something slightly different. The challenge was never rejecting requests — it was deciding which differences represented a new platform capability and which would create long-term complexity for everyone else.
What helped was looking for the shape behind the requests rather than taking each one literally. Some brands needed a feature hidden entirely, others needed it visible but optional, and a few just needed different defaults. Those requests looked unrelated at first, but many of them collapsed into the same configuration capability once you saw the pattern — which is exactly the difference between a platform setting and a one-off exception.
Trade-offs
The main trade-off was giving up some local freedom for a shared codebase: not every brand could get a custom implementation immediately. Adding a capability to the platform usually took longer than solving the same problem inside one product — but it removed future duplication and made standing up each new brand far easier.
What I learned
The interesting part of a multi-brand platform isn't the theming — it's the boundary. Most of the engineering judgment went into one repeated question: is this a new platform capability, or a feature specific to a single brand? Get that line right and new brands stay cheap; get it wrong and the platform slowly turns back into the forks you were trying to avoid in the first place.