When a startup needs a design system
Guide · 7 min read · By Utkarsh Dhairya Panwar · Updated
A startup needs a design system once the same components keep getting rebuilt slightly differently, usually by the second or third major feature. Start small: tokens, the ten or so components on every screen, and shared empty, loading and error states. At CodeAnt, standardising 18+ patterns cut design turnaround 30%.
Signs your startup needs a design system now
- Production has three slightly different buttons, tables or modals, and nobody can say which one is right.
- Design reviews spend their time on spacing and colour instead of behaviour.
- Engineers ask for a spec on every small screen because there's nothing to copy from.
- A new feature takes longer to build than the last similar one did.
- A second product line or a second designer is about to arrive.
With one designer, one engineer and one main screen, you don't need a system yet. A Figma file with shared styles is enough, as long as people stick to it.
The two systems I built, and what they changed
Neither began as a design system project. Both began as "stop drawing the same table twice".
At xPay (YC W24) I was shipping checkout UX for live sales demos, and the same parts came up on every screen. I built a reusable UI system of 25+ components while shipping, rather than as a separate project. There was no governance process, docs site or versioning policy, and none was needed: on a team that size, agreeing on a button takes one conversation. Feature delivery time dropped 35%, mostly because engineers stopped rebuilding parts that already existed and frontend rework cycles went down.
CodeAnt AI was the bigger case. As founding designer I built the brand, the component library and the guidelines in parallel with the product. The platform grew across AI code review, security scanning, code quality and developer metrics, and the same building blocks (tables, filter bars, severity labels) drifted into separate versions across the scan centre, code review and security screens. Design reviews kept turning into debates about which version was correct.
I didn't redesign anything. I listed every version of each pattern, made one decision per pattern and put the result in a library engineers could import. That came to 18+ standardised UI patterns. Design turnaround dropped 30%, and most of the saving came from fewer debates: once a pattern was written down, reviews went back to being about the feature.
- 25+ Reusable components at xPay
- 35% Shorter feature delivery time at xPay
- 18+ UI patterns standardised at CodeAnt
- 30% Faster design turnaround at CodeAnt
Library first, system later
xPay needed a component library with a page of rules. CodeAnt needed more: shared rules for page layouts, states and naming on top of the components, because scan results, review comments and dashboards had to sit side by side and still read as one product. Most startups are in the xPay situation for longer than they think.
| You're here | Build this |
|---|---|
| One designer or none, one product, engineers building straight from Figma | A component library in Figma and code, a token file and one page of usage rules |
| A second designer, a contractor, or screens you didn't review | Written page patterns and state rules, and a named owner for changes |
| A second product line or surface | Shared tokens and naming across both, so a pattern means the same thing everywhere |
| A rebrand coming, with hex values hard-coded everywhere | Role-named tokens first, before any new visuals |
A library gives you parts, and a system tells a new engineer which part to use when. My design system vs component library page goes into the difference.
What to standardise first
- Tokens: Colour with semantic roles (success, warning, danger), a type scale of four to six sizes, a spacing scale, radius and shadow. Name them by role, not by value, so text-muted survives a rebrand.
- The everyday components: Button, input, select, checkbox, modal, toast, table, tabs, badge and empty state. Those ten cover most screens in a SaaS product.
- State patterns: Loading, empty, error, partial data and no permission. When these behave differently from screen to screen, the product feels broken even if every screen looks fine.
- Page-level patterns: List page, detail page, settings and the shape of a dashboard card. In a product like CodeAnt these rules mattered as much as the components.
- Writing rules: Button label format, error message structure, and whether you say "repository" or "repo". Cheap to write down, and they remove a whole category of review comments.
How small to start
Smaller than you'd think. I'd rather have fifteen components that match production than eighty that don't. A good first version has:
- One Figma library, with variants only for the states the product uses today.
- A matching code library that engineers own, even if it's a thin layer of your styles on an open-source component set.
- One page of guidelines: modal or full page, how tables sort, how errors are worded.
- An owner, usually the founding designer plus one front-end engineer.
Take behaviour and accessibility from an open-source or headless library and put your tokens and styling on top. Building primitives like dropdowns from scratch rarely pays off at seed stage. My design system examples page goes through what to borrow from Primer, Atlassian, Geist, shadcn/ui and Polaris.
Mistakes I see in startup design systems
- Building it before the product settles, then redesigning components that were used once.
- Documenting in Notion what doesn't exist in code. If engineers can't import it, it isn't a system.
- Too many variants. Five button sizes is usually two too many.
- Treating brand and product as separate systems, so the website and the app drift into two shades of the same blue.
- No owner after launch. Without someone reviewing new components, a system drifts out of date within months.
Keeping it alive
Add a component only once two places need it. Review new patterns in the same design review as features, and delete variants nobody uses. Building the system alongside the product, as I did at CodeAnt, keeps it honest, because every component has a real screen waiting for it.
CodeAnt AI case study: Product, website, brand and design system, designed from the ground up as founding designer.
If a small system would save your team time, that's part of my brand and design systems work.
Questions people ask
How long does it take to build a design system for a startup?
A first version (tokens, the everyday components with their states, one page of rules) usually takes two to four weeks, depending on how many screens the product has. It keeps growing with the product after that.
Should a startup use an existing UI library or build its own?
Use an existing headless or open-source library for behaviour and accessibility, and add your own tokens and styling. Building primitives from scratch rarely pays off early.
Can a design system come before product-market fit?
A small one can: tokens plus the components your screens already repeat. A large documented library before the product settles mostly gets thrown away.
Who should own the design system at a startup?
The founding or lead designer, paired with one front-end engineer who keeps the code library in sync with Figma.
Sources
- Design Systems 101, Nielsen Norman Group
- Design Tokens Format Module 2025.10, W3C Design Tokens Community Group
Working on this?
Tell me what you're building and where it's stuck: book a 30-minute call, email work@utkarshdesign.com or send a brief.