Design systems are sold as the grown-up way to build software. For a small team they can just as easily become a second product nobody has time to maintain. The size of the system should follow the size of the problem.
- Start with tokens: colors, type scale, spacing and radii.
- Promote a component only after it's used three times.
- Keep one source of truth — code, not a separate Figma library.
- Document decisions, not every prop.
Signs you need one
You have more than one surface (marketing site, app, emails) that should feel related. Designers and developers debate spacing in reviews. New pages take as long as the first ones did. Any two of these and a lightweight system will pay off within a quarter.
Start with tokens, not components
Colors, type scale, spacing and radius cover most of the consistency people notice. They're cheap to define, easy to adopt and hard to get wrong.
Takeaway
Tokens give you 80% of the consistency for 20% of the effort. Components can wait until patterns repeat.
The rule of three
Build something once as a one-off. The second time, copy it. The third time, turn it into a component — by then you know which variations are real and which were guesses.
The best design system for a small team is the one the developers actually import.
Keep it in code
A Figma library and a code library drift apart within months. For small teams we make code the source of truth, keep a live styleguide page, and treat Figma as the place to explore — not the place things are defined.

