One Design System Across Many Brands, Without Cloning Them

You can absolutely run one design system under products that look nothing alike. The mistake people make is assuming a shared design system means every product ends up looking the same. It does not, if you build the system so brand lives in a theme layer and structure lives in the components. Swap the theme, keep the components, and two products can share every line of interface code while reading as completely different brands. That is the whole design payoff of a portfolio: build the machinery once, dress it many ways.

I run products across very different feels, from developer infrastructure to legal software to a music brand, off one interface foundation. They do not look like siblings. They share bones, not skin.

Why sharing a design system does not mean sharing a look

A design system has two layers that people conflate. The structural layer is how a button behaves, how a form validates, how a modal traps focus, how spacing rhythm works. The brand layer is color, type personality, corner radius, shadow depth, motion character. Structure is where the engineering value lives and where consistency helps everyone. Brand is where products should be free to differ.

Share the structure. Theme the brand. When those layers are cleanly separated, a bold high-contrast fintech product and a warm rounded consumer app can run on the same component code. The difference is entirely in the theme they load. I laid out the mechanics of this in design tokens are where a design system compounds: the semantic token layer is exactly where you swap brands.

How to theme brands without a per-brand rebuild

The rule is that components read semantic tokens and never hardcode brand values. button.primary.bg resolves to a token. The token resolves differently per brand. The component does not know or care which brand it is rendering. That indirection is what makes a brand swap a config change instead of a fork.

Practically, each brand is a file. It reassigns the semantic layer: what "primary" means, which type family carries headings, how sharp the corners are, how heavy the shadows fall. A brand file is small, because it only overrides the decisions that carry brand personality, and inherits everything structural. Adding brand number three is cheap for the same reason adding a dark theme is cheap when tokens are done right: you are swapping a layer, not rewriting the app.

What must stay shared, and what must stay free

Not everything should be themeable, and not everything should be locked. Draw the line deliberately.

• Keep shared and locked: accessibility behavior, focus management, keyboard handling, form validation logic, spacing rhythm. These are correctness. A brand does not get to have worse focus states.
• Keep themeable per brand: color, type personality, radius, shadow, motion feel, density. These are identity. Let them diverge.
• Keep app-owned entirely: the hero section, the marketing narrative, the illustration style. Some surfaces should not touch the shared system at all, which is the point of where to let portfolio apps diverge.

Get this line wrong in the locked direction and every brand fights the system. Get it wrong in the free direction and you lose the consistency you built the system for. The art is knowing which decisions are correctness and which are taste.

The trap: over-theming into visual mush

There is a failure mode where you make everything themeable to be safe, and now the system has a thousand knobs and no opinion. Products built on it look arbitrary, because with infinite freedom nobody makes coherent choices. A design system should have a spine. It should make some decisions for you and only let brand vary along the axes that carry identity. Constraint is a feature. The system that themes everything is not a system, it is a blank canvas with extra steps, and it stops compounding because every product re-decides everything.

Why this is a portfolio strategy, not just an engineering trick

The reason this matters beyond the code is that it lets one operator maintain distinct brands without distinct teams. Each product gets a real, considered visual identity, and I still only maintain one set of components. That is the same leverage logic as one governed foundation under every company, applied to design. The brands stay separate in the market and unified in the machine.

I keep the structural layer and the per-brand themes in the same build system at Bootspring, so a new product inherits the mechanics and only needs a brand file to look like itself. When clients ask me how a small operation can run many polished brands at once, this is the answer, and it is the same system thinking I bring to brand work at Girard Media: the brand is a theme over a machine, not a bespoke build every time. Share the bones. Vary the skin. Ship many brands off one system.