“We need a design system” is often true and often premature. The difference costs months.
What a design system actually is
Not a Figma file of pretty components — a set of decisions made once: colors, type scale, spacing, component behavior, and the rules for combining them. Its value is subtraction: every decision the system makes is one your team stops re-making (and re-arguing).
When you don’t need one yet
One designer, one product surface, pre-product-market-fit: a well-organized Figma library and consistent tokens are enough. A full system at this stage is armor that slows you down — you’ll redesign everything after the next pivot anyway.
The thresholds that change the answer
- A second designer. Two people make drift; three make chaos. The system is how they agree without meetings.
- A second surface. Product + marketing site, or web + mobile. Without shared tokens they diverge within a quarter.
- Developers rebuilding the same button. When engineers ask “which of these five modals is canonical?”, you’re paying the missing-system tax in code.
- Handoff friction. If every feature needs a spec conversation about spacing and states, the system is overdue.
What a right-sized startup system contains
Tokens (color, type, spacing — the non-negotiables), ten to fifteen core components with states (the empty, loading, and error states are where quality lives), usage notes in plain language, and nothing else. You can run a serious product on that. Grow it when it hurts.
We build systems this way for every product we design — TaskFlow and Merchant OS each run on exactly this structure. Wondering which side of the threshold you’re on? Ask us — it’s a ten-minute answer.