Most startups make one of two mistakes with design systems: they either build nothing and end up with an inconsistent product full of one-off components, or they try to build the full Google Material-style library too early and grind to a halt before shipping anything.
I've worked with early-stage SaaS companies at various stages — seed to Series B — and the pattern is consistent. What actually helps isn't a perfect system. It's a useful minimum one. A foundation that's easy to maintain, fast to extend, and doesn't require a dedicated design systems team to stay consistent.
This is the checklist I use when I start a design system engagement with a startup. Not everything here needs to be done before you ship — but everything here needs to be done before you scale.
Why startups get this wrong
The failure mode I see most often: a product team starts building screens one by one in Figma, each designer (or developer) making slightly different spacing, colour, and typography decisions. By the time they decide to "do design systems properly," there are 200 components to retrofit and nobody knows which version of the button is the right one.
The earlier you lay the foundation, the cheaper it is. Even a simple set of tokens and a core component library built in week one will save you weeks of design and development time by month six.
"A design system isn't a project you complete — it's an infrastructure you maintain. Start small, stay consistent."
Phase 1: Foundation (do this first)
Design tokens
- Define a colour palette: primary, secondary, neutrals, semantic (success / warning / error)
- Set a type scale: 5–7 sizes maximum, with clear naming (display, heading, body, caption, label)
- Establish spacing units: pick a base unit (4px or 8px) and stick to it everywhere
- Define border radius values: 2–3 values max (small, medium, large)
- Set shadow levels: flat, raised, overlay — nothing more at this stage
Figma setup
- Create a dedicated "Design System" Figma file separate from product files
- Set up local styles for all colours, type styles, and effects
- Use Figma variables if your plan supports it — map them to your tokens
- Document naming conventions early: Button/Primary, not "Button 1 Final v3"
Phase 2: Core components (before you scale the team)
You don't need everything. You need the components that appear on every screen. For most SaaS products, that's roughly 15–20 components. Start there.
Component library — minimum viable
- Button — primary, secondary, ghost, destructive, disabled states
- Input field — default, focus, error, disabled states
- Dropdown / select
- Checkbox and radio button
- Toggle / switch
- Badge / tag / chip
- Alert / toast notification
- Modal / dialog
- Card — with consistent padding and border radius
- Navigation bar (top or sidebar, depending on your product)
- Empty state
- Loading / skeleton state
Each component should have all interactive states designed in Figma before it's handed to development. "I'll add the error state later" is how you end up with 12 different versions of a broken input in production.
Phase 3: Documentation (when the team grows)
Documentation is not optional once you have more than two people touching the product. It doesn't need to be a dedicated website — a well-structured Figma file with usage notes and a simple Notion page covering "when to use X vs Y" is enough for most startups under 30 people.
Documentation checklist
- Usage guidelines for each component: when to use it, when not to
- Do/don't examples for key components (button labels, error messages)
- Accessibility notes: minimum contrast ratios, focus states, aria labels
- Contribution guide: how to propose a new component or pattern
- Version history: what changed and when
Phase 4: Dev handoff (before your first engineering sprint)
A design system that only lives in Figma isn't a design system — it's a style guide. The goal is a shared language between design and engineering. That means tokens need to exist in code too.
Engineering alignment
- Tokens exported to code (CSS custom properties, Tailwind config, or a token JSON)
- Component naming consistent between Figma and codebase
- Agreed on a component library (build in-house vs. headless UI like Radix or shadcn)
- Storybook set up for interactive component documentation (optional but highly recommended)
- Agreed review process: who approves new components in design? In code?
What to skip at the early stage
Just as important as what to build: what not to build yet. Time spent on these before you have product-market fit is often wasted.
- Dark mode — unless it's a hard requirement for your users, this doubles every design decision
- Internationalisation (i18n) layouts — design for one language first
- Fully custom icon library — use an existing set (Lucide, Phosphor, Heroicons) and customise later
- Animation system — one easing curve and two duration values is enough
- Design token tooling like Style Dictionary — add it when you have multiple platforms to serve
The mindset shift
The startups that get design systems right treat them like product infrastructure, not a design deliverable. They evolve iteratively, they're owned by the whole team (not just design), and they're always slightly incomplete — because the product keeps changing.
The goal isn't a perfect library. It's a living system that makes every future design and development decision faster and more consistent than the last one.
If you're an early-stage team trying to figure out where to start, this checklist covers about 80% of what you need. The remaining 20% will emerge from your specific product — and that's okay.
