Why your design system should be code first

Most design systems are a beautiful Figma file and a PDF nobody opens. The products they govern drift within a quarter. The fix is unglamorous: make the code the system.

A document describes. A build enforces.

If the spacing scale lives in a PDF, every developer re-implements it from memory — slightly differently. If it lives in design tokens consumed by the build, there is nothing to remember. The wrong value is not a style-guide violation; it is a failed CI check.

One implementation per component

The moment two button implementations exist, the system is over. The component library is the only place a button is defined — product teams compose, they do not copy. That demands the library be good enough to prefer: documented, accessible, themable, and faster than rolling your own.

What code-first looks like in practice

• Tokens as the contract — colour, type, spacing and radius exported from design tooling as data, versioned with the code, consumed by web, mobile and email templates alike.
• Lint rules as brand police — raw hex values and ad-hoc margins fail review automatically; nobody argues with a robot twice.
• Visual regression on every PR — screenshots diffed against baseline, so a padding change in the library is seen before customers see it.
• Designers review rendered components, not mock-ups of them — the artefact in review is the artefact that ships.

Start smaller than you think

Twelve solid components with enforced tokens beat eighty aspirational ones. Systematise the primitives first — colour, type, spacing, buttons, forms — and grow the library only when a third team needs the same thing twice.