Design Tokens That Survive Five Products and a Rebrand

A rebrand should be a design decision. Too often it is a week of find-and-replace. The brand color shifts from one blue to another, and an engineer spends days hunting down every hardcoded hex value across five products, three of them with subtly different spellings of the same color, missing a few, shipping inconsistencies that a designer catches in QA. The work is tedious, error-prone, and entirely avoidable. The thing that avoids it is a design token system, set up so that a single value change propagates everywhere automatically.

The difference between a token system that scales and one that becomes its own maintenance burden is structure. A flat list of tokens is barely better than hardcoded values. A tiered system, where raw values, their meanings, and their component-specific uses are separated into layers, is what lets one change ripple cleanly through five products and survive three rebrands without a week of manual labor each time. Here is how those tiers work and why the separation matters.

The three tiers, and why a flat list fails

A token is a named design value, like color-blue-500: #0F62FE. The naive approach is to define a pile of these and reference them directly in components. This is better than hardcoding hex values inline, but only slightly, because the name is still tied to the value. If your button references color-blue-500 and the brand changes its primary color to a new blue, you are back to hunting down every reference to blue-500 across the codebase. You moved the problem; you did not solve it.

The tiered system solves it by inserting layers of meaning between the raw value and its use. There are three:

Primitive tokens are the raw building blocks. blue-500: #0F62FE, gray-100: #F4F4F4, spacing-4: 16px, radius-2: 8px, font-size-3: 20px. These are just the palette of available values, named by what they are, not what they are for. They are the bottom of the stack and nothing in your components references them directly.

Semantic tokens assign meaning to primitives. color-primary points at blue-500. color-surface points at gray-100. spacing-comfortable points at spacing-4. These describe a role, not a specific value, and this is the layer your components actually use. A button references color-primary, not blue-500. It does not know or care which blue that is; it knows it wants the primary color, whatever that currently is.

Component tokens are the most specific, defining values for individual components where a component needs its own controllable knob. button-background might point at color-primary. card-padding might point at spacing-comfortable. This layer exists for the cases where a component needs to vary independently of the general semantic, and it references the semantic layer, which references the primitives.

The chain is component token, which points to semantic token, which points to primitive token. Three hops, and each hop is a place you can intervene without touching the others.

Why this makes a rebrand a one-line change

Here is the payoff, and it is the whole reason the structure earns its complexity. When the brand changes its primary color, you change one thing: the primitive value, or the semantic mapping that points at it. With a semantic layer in place, a rebrand means updating your primitive values and possibly adjusting some semantic mappings, and every component that references those tokens updates automatically.

Walk it through. The brand moves from #0F62FE to a new blue. You update blue-500 to the new hex, or you repoint color-primary from blue-500 to a new blue-600 primitive. Every button, link, badge, and highlight that references color-primary now renders the new color, instantly, everywhere, because they all reference the semantic token and the semantic token is the only thing that changed. There is no find-and-replace, because nothing references the raw value directly. The component layer never knew the specific blue; it only ever knew "primary."

This is what turns a rebrand from a week of grep into a deliberate change to a handful of values. And it scales: whether the change has to reach one product or five, the work is the same, because all five reference the same semantic tokens. One change, defined once, applies to everything downstream.

Theming, light and dark, falls out for free

The same structure that handles rebrands handles theming, because a theme is just a different set of mappings from semantic tokens to primitives. In light mode, color-surface points at a light gray; in dark mode, the same color-surface points at a dark one. Your components reference color-surface and never change. Switching themes is switching which primitives the semantic layer resolves to, and every component follows because every component speaks in semantic tokens, not raw values.

This is why the semantic layer is not optional ceremony. Without it, light and dark mode means every component knowing about both palettes and choosing between them, which is exactly the tangle the token system exists to prevent, and the same one motion tokens prevent when you need to respect users who get sick from motion without auditing every animation by hand. With it, components express intent, "I want the surface color," and the theme decides what that resolves to. The catch is that a dark theme is more than inverted swatches, which is the whole point of building real dark mode that is not just an inverted color sheet, and whichever palette resolves still has to clear contrast, the subject of hitting WCAG contrast on every screen without wrecking your brand palette. Multiple themes, multiple brands, all handled by swapping the middle layer while the components stay still.

Build on the standard, not a bespoke format

If you are setting up a token system now, there is a reason to use a standard format rather than inventing your own. In October 2025, the W3C Design Tokens Community Group released the first stable version of the Design Tokens specification, with contributors from Adobe, Google, Microsoft, Meta, Figma, Salesforce, and Shopify. Building on that spec means your tokens are portable across design tools and code, and you avoid locking yourself into a one-off format that only your build pipeline understands.

The practical benefit is that your tokens become a shared source of truth that designers in Figma and engineers in code both consume from the same definition, rather than a designer's palette and an engineer's variables drifting apart over time. The token file is the contract, the standard format makes it portable, and the tools on both sides read from it. That same single-source discipline is what lets visual pickers users can see render every brand color and icon straight from the tokens instead of a hand-maintained list, and it is the connective tissue behind treating your site as a connected graph rather than a stack of pages, where shared definitions keep every surface coherent.

When it is worth it, and when it is overkill

A token system is not free, and for a single small landing page it is more structure than the situation needs. The honest assessment is that for a product in its scale-up phase, especially a SaaS product growing toward multiple surfaces, tokens almost always pay off, because the upfront effort is small compared to the maintenance cost of inconsistent design across a growing product. The cost is defining the tiers once. The benefit compounds every time the design changes, every time a new product joins the system, every time someone would otherwise have hardcoded a value that drifts.

The signal that you need it is repetition: more than one product, an anticipated rebrand, a dark mode on the roadmap, or simply a design that keeps getting tweaked and keeps producing inconsistency when it does. At that point the tiered token system stops being overhead and starts being the thing that keeps the design coherent as it scales, the same way the micro-interactions that separate a premium product from a prototype stay consistent when motion is defined once and reused everywhere. This is the kind of foundation we put under the web applications and the broader design systems we build for clients who are going to be many products and several iterations down the road, because the cost of retrofitting consistency later is far higher than the cost of structuring it now.

The system that survives change

The measure of a design token system is what happens when the design changes. A flat system, or hardcoded values, turns every change into a hunt. A tiered system, primitives at the bottom, semantics in the middle, component tokens at the top, turns the same change into an edit to a few values that propagates everywhere on its own.

That is the entire promise: a single color or spacing change that ripples through five products and survives three rebrands without a week of find-and-replace, because nothing in your components ever pointed at the raw value to begin with. They pointed at meaning, and meaning is the layer you control. Set up the tiers once, and the design stays coherent no matter how many times it changes or how many products it has to cover.