Your front-end engineer just shipped the third date picker this year. One closes on Escape, two don't, and nobody decided that on purpose. Somebody in the retro says "we need a design system", and everyone nods, because nobody wants to argue against consistency.
Hold the nod. A design system for startups at 10–80 people usually isn't the thing a design-systems team at a 5,000-person company runs. What you need first is smaller: a component library your code agrees with, plus a token file, with one person who owns both. Add governance only when you can count the problem.
A minimum viable design system is a token file (colour, type, spacing) plus a set of coded components that map one-to-one to a single Figma library, with one named owner and a changelog. A full design system adds documentation, governance, contribution rules and a team to run them.
Key takeaways
The words get used interchangeably, and that's how small teams end up planning for something they can't staff.
NN/g defines a design system as "a complete set of standards intended to manage design at scale using reusable components and patterns." [C1] Its repository often contains a style guide, a pattern library and a component library, which documents reusable UI elements down to their states and code [C1]. The component library is the piece that touches code.
The rest is the expensive part. NN/g puts the minimum maintenance team at an interaction designer, a visual designer and a developer [C1], and calls creating and maintaining one "a time-intensive activity". [C1] At a 30-person SaaS with one product designer, that sentence describes a team you don't have.
The survey data says the same. In zeroheight's Design Systems Report 2026, companies of up to 100 people averaged a two-person design-system team, against eleven at companies of 5,000+ [C2]. Only about 11% of the 147 respondents worked at companies that small [C2], so treat it as a direction, not a benchmark.
So start where the code is. The shadcn/ui docs put it in one line: "This is not a component library. It is how you build your component library." [C4] Whatever kit you start from, the components live in your repo and you own them.
You need more design system when the cost of inconsistency shows up in your backlog, and you can point to it. If you can't count any of the six signals below, a consistent component library is enough for now.
1. The same component exists more than once. Run an interface inventory: Brad Frost describes it as "a comprehensive collection of the bits and pieces that make up your user interface." [C5] Screenshot one instance of each unique UI pattern, from buttons to form fields [C5]. HMRC's inventory covered 60 services, about 1,000 screens [C6]. Yours is an afternoon. Three date pickers is a signal. One date picker used everywhere isn't.
2. Figma and production disagree. This failure lives in code, not in the design file. In Sparkbox's 2022 survey, maintainers ranked "parity between design & code" their second-biggest challenge, at 37% [C7]. In an analysis of 4,714 issues from 41 open-source design systems, 42.7% were about component behaviour and 10.2% about visual design [C8]. Keyboard handling and focus states are behaviour, and a Figma frame doesn't define them.
3. You're adding a second product, platform or theme. Dark mode, a white-label tier or a mobile app turns hard-coded values into maintenance. The Design Tokens Community Group's first stable format, 2025.10, was built partly for this: it supports light/dark modes, accessibility variants and brand themes "without file duplication". [C9]
4. A rebrand or replatform is coming. Frost suggests piggybacking the system on a redesign or replatforming project you're already running [C5]. You're touching every screen anyway.
5. You've taken on accessibility obligations. The European Accessibility Act can be enforced by EU member states from 28 June 2025 [C10]. It covers services including e-commerce and consumer banking, and a law-firm briefing says businesses should aim, at a minimum, for WCAG "AA" level on websites and apps [C10]. Microenterprises with fewer than ten employees and under €2 million turnover are exempt from some requirements [C10]. Check your own scope with counsel. One WCAG 2.2 AA criterion is a consistency rule: "Components that have the same functionality within a set of web pages are identified consistently." [C11] Fixing a focus state in one shared component fixes it on every screen that uses it. Fixing it in three date pickers is three tickets.
6. More than one team ships UI. Nathan Curtis names one team model "solitary": "A solitary model sees a one team make a system available, but with efforts focused primarily on that team's needs." [C12] That's fine while one team builds everything. Once a second squad builds screens, you need a way to decide together, or they'll fork.
Two signals firing is a reason to formalise. One is a reason to fix that one thing.
The minimum version is three things, and none of them needs a team.
A token file with two layers. Primitives (the raw palette, the type scale, the spacing steps) and semantic tokens (what "danger" or "surface" means). In zeroheight's 2026 data, 90% of systems have primitive tokens and 85% semantic, while only 52% go as far as component-level tokens [C2]. Skip that third layer until you need it. Write them in the Design Tokens Community Group's stable 2025.10 format. It's a W3C Community Group report, not a W3C Standard, and tools such as Style Dictionary and Tokens Studio already implement it [C9].
Coded components mapped one-to-one to one Figma library. Same names, same props, same states. Figma's Code Connect links components in your repositories to the components in your design files [C13], which keeps the mapping visible to engineers in Dev Mode. Build components from the screens you've already shipped, not from a blank canvas. Summarising their interviews with design-system leaders, Lamine and Cheng report that components and guidelines "are emerged and elevated from existing digital products in the company" [C8], rather than designed top-down.
One named owner and a changelog. This is the step teams skip. Curtis describes a system as "a living, funded product with a roadmap & backlog, serving an ecosystem." [C14] At your size, "funded" means a few hours a week of one person's time. Figma suggests watching component detachments and style overrides as signals that the system isn't meeting a team's needs [C15], and warns to "Look beyond surface numbers for context." [C15]
That's the whole thing: one repo, one Figma file.
The case for building more leans on one number. In Figma's study, designers with a design system finished a task 34% faster [C3]. Read the caveat in the same post: "we expect that this time-savings finding is the maximum time savings one would find in a real-world scenario." [C3] The system in the test was relevant and up to date [C3]. Yours will be neither after six months without an owner.
Then there's the upkeep. In zeroheight's 2026 survey, 61% of design-system teams said they were understaffed [C2]. Lack of resourcing was the top maintenance challenge, at 56% [C2]. Satisfaction with leadership buy-in fell to 32%, from 42% the year before [C2]. And only 7% of respondents described their system as fully adopted [C2].
Ownership is what decays first. In a CHI 2023 survey of 114 UX practitioners, 20% of the responses about challenges in getting design systems adopted cited "lack of communication and ambiguity in ownership". [C16] One respondent put it plainly: "We all use [a design system] if it's there, but since nobody has ownership, it may fail to have new assets or stylings." [C16] Frost quotes Airbnb's Alex Schleifer on the same risk: "The biggest existential threat to any system is neglect." [C14]
Mature systems show what you'd be signing up for. The GOV.UK Design System is "maintained by a team at the Government Digital Service." [C17] IBM's Carbon ships dozens of components, plus patterns, React and Web Components implementations, and accessibility guidance [C18]. Even Shopify moved on: "The Shopify Polaris React library is deprecated," its README says, after Polaris Web Components shipped on 1 October 2025 [C19].
A design system is a product with a permanent backlog. Size it to the team you'll actually have next year, not the one in the conference talk.
Before product–market fit, even the minimum version can wait. NN/g says a full-fledged design system "is probably not going to generate a desirable ROI in the near term" for proofs of concept or prototypes likely to change [C1]. It also says "using an existing design system is the lowest-cost approach". [C1] Pick a stock library, keep it consistent, and spend the design hours on the product.
The same goes if you have no product designer yet. Who should own design at all comes first, and we covered that in founder-led design and the five signals that end it.
Frost suggests time-boxing an interface inventory to 30–90 minutes for a first pass [C5]. Book the 90. Put your product designer and one front-end engineer in a room, split the categories, and screenshot one instance of each unique pattern [C5]. Then count.
If the count is low and Figma matches production, stop. You don't need a design system yet. If you find duplicates and drift, pick the canonical version of each and build the minimum version above. Our design-debt UX audit post covers the triage pass.
If you'd rather not take that on in-house, it's a task-sized job. Our UX On Demand product designers build exactly this: "Tokens, primitives, and patterns in Figma, mapped 1:1 to your front-end components." If you have no system yet, "We can build one." Plans are $3,495 a month for a single stream, one task at a time, or $6,795 for two tasks in parallel, with a 3-day turnaround per task. You can cancel any time, and every Figma file, prototype and asset lives in your workspace and belongs to you. "Start with one real task — judge the designer before you subscribe." If you want the components built in code too, Dev On Demand engineers pick that up on the same task cadence.
Either way, count the date pickers first.
Most 10–80-person SaaS companies need a minimum viable one: a token file, coded components mapped to one Figma library, and one owner. NN/g says a full design system needs at least an interaction designer, a visual designer and a developer to maintain. [C1]
A component library documents reusable UI elements with their states and code. A design system is the wider set of standards around it, often a style guide, a component library and a pattern library, plus the team that maintains them. [C1]
When you can count the problem: duplicated components in an interface inventory, design-to-code drift, a second product or theme, a rebrand, accessibility obligations, or a second team shipping UI. In Sparkbox's 2022 survey, maintainers ranked design-and-code parity their second-biggest challenge, at 37%. [C7]
Figma measured designers finishing a task 34% faster with a design system, and called that the maximum saving to expect in a real-world scenario. [C3] The saving depends on the system being current, which takes an owner.
