Design tokens that survive a rebrand

Every expensive rebrand we have ever been asked to rescue had the same post-mortem: the old brand was not applied to the product, it was written into it. The blue was typed out four hundred times. Changing the blue meant finding all four hundred.

Two layers, one rule

Our token architecture has exactly two layers. The bottom layer is primitives: the raw palette, the type scale, the spacing steps, named for what they are and nothing else. The top layer is decisions: surface, ink, accent, heading, body, gap. Components are only ever allowed to reference decisions, never primitives.

That one rule is the entire trick. A rebrand rewires the decision layer to point at new primitives, and every component follows because none of them ever knew what the blue was called.

Type and spacing obey the same law

Colour gets the attention, but type and spacing are where rebrands actually bleed time. So the same two layers apply: a raw scale at the bottom, semantic roles above it. When the new brand arrives with a new typeface and a tighter rhythm, the roles are re-pointed and the layout holds, because every margin in the product was already a named decision rather than a number someone liked that day.

A rebrand should be a decision you make, not a project you survive.

The test we apply

Before we call any design system finished, we run the drill: swap the entire brand in a branch, on a timer. If the swap touches anything beyond the token config, the system is not done, and whatever it touched is the next thing we fix. The last one we shipped passed the drill in an afternoon.

It is not glamorous work. It is the difference between a refresh that ships in a sprint and a rewrite that eats a quarter, and it is standard in everything the Build practice delivers.