When to Invest in a Design System (And What It Actually Costs You)
Design systems are seductive. The idea of a single source of truth for every button, every input, every modal — it sounds like engineering done right.
The problem is that most startups build their design system for the product they imagine they'll have, not the product they're building. The result is months spent on infrastructure for a product that changes direction after the first user interviews.
Here's how to think about it.
What a design system actually is
A design system has two parts: design tokens (the values that make your product look like itself — colours, spacing, typography, border radii) and components (the reusable building blocks built using those tokens — buttons, inputs, cards, modals).
Tokens are cheap to define and valuable from day one. They make everything automatically consistent. A change to your primary colour updates everywhere at once.
Components are expensive to build correctly. Accessibility, keyboard navigation, focus states, edge cases across browsers — a production-quality button component has more to it than it looks.
The mistake is treating both as a package deal that needs to be shipped before building product. Tokens, yes. Full component library, no.
The right sequence
Start with tokens. Before any product UI is built, define your colour palette, spacing scale, and typography. This takes a few hours and prevents the inconsistency that makes redesigns painful later.
Build components when you're about to use them twice. The rule for extracting a component: you're building it for the second time. One-off components don't need abstraction. If you built a specific card layout once and you're about to build a second different card, that's when a shared Card component earns its existence.
Adopt a library as a foundation. Building from scratch makes sense for a handful of truly custom components. For primitives — modals, dropdowns, form elements where accessibility matters — starting from a maintained library saves weeks. Your developer customises with your tokens; you build bespoke components for your differentiated UI.
Skip Storybook until you're ready. Storybook is a powerful tool for documenting components at scale. It's also real maintenance overhead for a startup moving fast. Your "documentation" at this stage is the component usage itself — good naming and sensible defaults in a real product page are enough.
Introduce Storybook when you have multiple developers who need to discover what exists without reading code, or a designer reviewing components in isolation.
The cost of building it too early
The cost isn't just the time to build the system. It's:
- Opportunity cost — the product features that didn't get built while the team worked on infrastructure
- Rigidity cost — a well-built component library creates pressure not to deviate from it, even when a specific UI case calls for something different
- Maintenance cost — every component you extract is a component you maintain as the product evolves
At the early stage, flexibility is more valuable than consistency. Users won't see a design system; they'll see a product. Build the product.
What a lean design system looks like at six months
A realistic baseline that covers most of what you need:
- 10–15 UI components — button, input, textarea, select, badge, card, modal, avatar, toast, tabs, dropdown
- Design tokens file — colours, spacing, typography in one place
- A shared Figma file with components matching the code
- No Storybook — not yet
- Conventions documented in a README or Notion page — what exists, how to use it
That's enough to build consistent UI fast, onboard a new contributor, and evolve as the product grows. When you feel friction from the current approach, that's the signal to invest more.