“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.
This is the discipline behind our product design service, where these patterns ship in real software.