Architecting Scalable Design Systems: From Tokens to Production-Ready Components

The dealer storefronts I work on share a skeleton but not a face: three brands, one component system, editorial teams publishing daily. A design system in this world isn't a Figma library — it's the mechanism that lets a brand refresh not become a rewrite. Here's the layering that's held up.

Tokens are the contract; components are the implementation

Everything a brand might want to change — color, radius, type scale, spacing rhythm — lives in tokens. Components consume only tokens, never raw values. Tailwind's CSS-first theming makes the contract explicit:

@theme {
  --color-background: var(--brand-background);
  --color-accent: var(--brand-accent);
  --radius-card: var(--brand-radius);
}

A brand swap is a token layer change. When The Backyard needed its warmer outdoor tone, no component file opened.

Composition beats configuration

Early on I made the classic mistake: a Card with twelve variants covering every marketing whim. The system got cheaper the day it got smaller — primitives (Surface, Stack, Media, Meta) that compose into the few real patterns (vehicle card, location card, promo band). Fewer props, more predictable output, and editors still can't build something broken because the composable units each carry their own constraints.

• Variants for meaning, not pixels — intent and tone, not bigBlueButton.
• CMS blocks as compositions — the editorial block library maps to component compositions, so design and content vocabularies stay in sync.
• Accessibility as a primitive concern — focus, contrast and reduced-motion live in the base layer; feature teams can't opt out.

The metric that matters

Not component count — time-to-new-page. When marketing asks for a seasonal landing page and it's assembled from existing blocks in an afternoon, with performance budgets intact, the system is working. Everything else is documentation theater.