The Smallest Design System That Actually Holds
You don't need a component library to stay consistent. You need about twelve tokens, three components, and the discipline to route everything through them.
Design Studio
Product design
Design systems fail small teams in two directions. Too little, and every page invents its own greys. Too much, and you're maintaining a library nobody has time to use. The version that survives is embarrassingly small.
Start with tokens, not components
Name the decisions, not the widgets. A dozen custom properties will absorb most of the inconsistency in a product, and they cost nothing to adopt because they're just values.
@theme { --color-deep-charcoal: #121212; --color-neon-cyan: #00f0ff; --color-neon-cyan-dark: #0e7490; /* the accessible-on-white variant */ --color-vivid-purple: #9b5de5; --radius: 0.625rem;}Then exactly three components
- Button — every variant you actually use, and no others.
- Surface / Card — one border, one radius, one shadow, one dark-mode treatment.
- Field — input, label, hint, and error as a single unit, because that's where inconsistency is most visible and most expensive.
Everything else can stay ad-hoc for far longer than people expect. A page-specific layout that's used once is not a component; extracting it early is how design systems become archaeology.
The one rule that makes it stick
If you're typing a raw hex code, a raw radius, or a one-off shadow, you're either adding a token or making a mistake. There's no third option.
That rule is enforceable in review in about five seconds, which is why it works and why elaborate governance documents don't.
