One token set, many brands: theming a platform for multiple clients
When a platform serves many clients, every client wants it to look like their own. The tempting answer is to redesign the interface for each of them, and it is also the most expensive one. The better answer takes more effort at the start and repays it many times over: one token set, built carefully enough that a new brand becomes a matter of configuration rather than a new project.
The cost of starting over
I have seen platforms where every new client meant a fresh round of design, a fresh round of development and a fresh set of inconsistencies. Each version drifted a little further from the others, until maintaining them became a project in its own right. The work was never wasted, exactly, but it was paid for again and again.
A shared token set changes the arithmetic. The structure, the components and the behaviour stay the same for everyone. Only the layer that expresses the brand changes, and if that layer is designed properly, it is surprisingly thin.
Invest once, properly
The investment goes into the library, and it is real. Every colour, every radius, every spacing value and every piece of typography has to be a token named by purpose, so that a component never refers to a raw value directly. Buttons ask for the primary action colour, not for orange. Cards ask for the surface radius, not for eight pixels. That discipline is tedious to set up and easy to break, which is why it pays to write it down clearly from the very beginning.
The second part of the investment is reach. A library becomes far more valuable when the same tokens drive more than one implementation: React components, a shadcn/ui setup, an Ant Design theme or whatever stack the next client happens to use. When the tokens are the single source and each stack simply reads from it, the brand travels with them, wherever the code goes.
Two colours and a corner radius
This is where the effort pays back. With a library built that way, onboarding a new client is often a matter of changing two colour variables and the border radius. The primary colour carries the brand, the secondary supports it, and the radius sets the tone, from sharp and institutional to soft and friendly. Everything else, from contrast in dark mode to hover states and focus rings, follows from the system, because it was designed to.
Of course, some clients need more: their own typeface, a denser layout, a particular illustration style. The system makes room for that too, but even then the starting point is a working, consistent product rather than a blank page.
Not only for clients
The same library is just as useful before there is a client at all. When a promising job is on the horizon and nothing is signed yet, I can dress the platform in the prospect’s colours and see in an afternoon whether the idea holds up. When a pitch is coming, I can walk in with something that already looks and behaves like their product, rather than a set of mood boards. Quick iterations, early checks and ideas tested before anyone commits a budget: that freedom comes from the same tokens, and it is often what wins the work in the first place.
Why it matters to the client
For the client, the benefit is simple and measurable. They get a product that looks like theirs in days rather than months, built on components that have already been tested by everyone else on the platform. They pay for their brand, not for reinventing buttons. And because every improvement to the shared library reaches all clients at once, their product keeps getting better without a separate budget.
That is the kind of saving clients remember. It is also, in the end, the most persuasive argument for doing the unglamorous work of building a library properly: it makes every future project faster, cheaper and more consistent, for everyone involved.
Is your design system starting to fade?
I’d like to hear about it →