# Does a startup need a design system? Cost, timing, what to build

> When a startup needs a design system, what it costs in people and upkeep, what to build first (tokens, core components, states) and whether to adopt, adapt or build your own.

By Alterra Studio. Updated 2026-10-08. Canonical: https://alterra.studio/insights/does-a-startup-need-a-design-system

A startup needs a small design system once more than one person is designing or building its interface every week, and rarely before. Before product-market fit, set colours, type and spacing as tokens on top of an existing component kit and stop there. From seed onwards, build out the core components your main flows use, with all their states, and ship them as code. In Figma's own experiment, designers finished a task 34% faster with a relevant, up-to-date design system. A full system with its own team and documentation site is a Series A or later decision. The cost is mostly people's time: building it, and keeping it in use.

## What is a design system, and what isn't it?

Nielsen Norman Group defines a [design system](https://www.nngroup.com/articles/design-systems-101/) as "a complete set of standards intended to manage design at scale using reusable components and patterns." In practice it has four layers:

- **Tokens.** Named values for colour, type, spacing, radius and shadow, used in both design files and code.
- **Components.** Buttons, inputs, menus, tables and modals, each with its states.
- **Patterns.** How components combine for a recurring job, such as a form, an empty screen or a settings page.
- **Documentation.** Short notes on when to use what, so new people use it the same way.

A brand style guide on its own is not a design system, and neither is a Figma file of polished screens. A public documentation site is optional. Most startups never need one.

## Does an early-stage startup need a design system?

Not a full one. Nielsen Norman Group warns that for a proof of concept or an early prototype likely to change, a full design system probably won't pay back in the near term, because its value is in repeating design work later. In its words, design systems "are best when the company foresees years of future, replicable design work."

Most of the practitioners in design system surveys work at large companies. In zeroheight's [Design Systems Report 2026](https://report.zeroheight.com/), a survey of 147 design system practitioners, 39% work at companies with more than 5,000 employees and 11% at companies with 100 or fewer. Much of the advice you'll read is written for teams that size, so scale it down.

That doesn't mean doing nothing. The small decisions you make early (one button style, one spacing scale, one way to show an error) are the start of a system. Making them once, on purpose, costs very little.

## When is the right time to start one?

Start when you see two or three of these signals:

- A second designer joins, or several engineers build UI every week.
- Engineers rebuild the same component in slightly different ways.
- The same screen type (a table, a form, a settings page) looks different in different parts of the product.
- You're adding dark mode, a second product or a white-label version, which all need themes.
- Design reviews keep debating spacing and colours instead of the flow.
- A rebrand or redesign is planned, and you'd rather change values once than screen by screen.

Here is a rough guide by stage, based on how much UI work repeats at each one:

- **Pre-seed.** A light layer of tokens on an existing kit, and a handful of components used consistently. No documentation and no dedicated team.
- **Seed.** Full tokens, a working set of core components with their states, and a short page of notes. Still no dedicated team.
- **Series A.** A complete component library in code, real documentation and one named owner, often part-time.
- **Series B and beyond.** A mature system with full documentation and a small dedicated team.

> Figure: How much design system you need at each stage: Pre-seed: Tokens low, Core components low, Documentation none, Owner or team none; Seed: Tokens high, Core components medium, Documentation low, Owner or team none; Series A: Tokens high, Core components high, Documentation medium, Owner or team low; Series B and beyond: Tokens high, Core components high, Documentation high, Owner or team high. A rough guide from the stage section of this guide, based on how much UI work repeats at each stage. Not survey data.

## What should you build first?

Build in this order, and stop each step at what your product uses today.

**1. Tokens.** Colour, type scale, spacing, radius and elevation. Name them by role (`text-primary`, `surface-raised`) as well as by value, so a theme or rebrand changes one layer. zeroheight found that only 10% of teams run a single token layer; most separate raw values from semantic ones. The W3C Design Tokens Community Group published the [first stable version](https://www.designtokens.org/) of its shared token format, 2025.10, so tokens can move between design tools and code.

**2. Core components with every state.** Start with the components your main flows use, and only those. A button needs its hover, focus, disabled and loading states. A table needs empty, loading, error and far-too-much-data versions. This is where design systems save the most engineering time, and where cheap quotes cut corners, as we explain in [how much SaaS product design costs](/insights/how-much-does-saas-product-design-cost).

**3. Patterns for your top flows.** Forms, onboarding steps, empty screens, confirmation dialogs. Document the decisions once so new features don't reopen them.

**4. Short documentation.** A page per component is enough at first: what it's for, when not to use it, and its states. Include accessibility rules here. In zeroheight's survey, 4 in 10 systems don't include accessibility guidelines.

**5. A code library your engineers use.** A Figma library with no matching code is a drawing of a design system. zeroheight found that 22% of systems don't have a code library, and only 54% of teams have tokens in design tools, code and documentation together. Only 40% have any token pipeline, so most teams sync design and code by hand.

## Should you adopt, adapt or build your own?

Nielsen Norman Group describes three approaches: adopt an existing system as it is, adapt one to your needs, or create your own. It calls adopting an existing system the lowest-cost approach and the fastest to implement. The more custom you go, the more time and money it takes.

For most startups, adapting is the right middle. Take an open-source base such as Google's [Material Design 3](https://m3.material.io/) or [shadcn/ui](https://ui.shadcn.com/docs), and apply your own tokens. shadcn/ui puts its own approach plainly: "This is not a component library. It is how you build your component library." You get accessible, tested components and keep your own look.

Build from scratch when your product has interaction needs a kit can't meet, such as dense data tools, a canvas, or Web3 wallet and transaction states, or when your brand depends on a look a themed kit can't reach. Even then, keep a kit's accessibility behaviour where you can.

## How much does a design system cost?

There's no reliable market price for a startup design system. We couldn't find a published source that prices one, so treat any single figure with care. The cost is people's time, in two parts: building it and keeping it in use.

Building it is driven by:

- **Component count and states.** A handful of components with full states is a different job from a full library.
- **Platforms.** Web only, or web plus iOS and Android, which each need their own code.
- **Themes.** Light and dark, several brands or a white-label product multiply token work.
- **Design only, or design and code.** A coded library takes engineering time as well as design time.
- **Documentation and accessibility.** Writing it down is where most teams fall behind.

Keeping it in use is the part founders forget. Nielsen Norman Group says that at a minimum a design system team should include one interaction designer, one visual designer and one developer. zeroheight found that the average design system team at companies with 100 or fewer employees is 2 people, and that 3 in 5 design system teams say they don't have enough people to meet their goals.

For a sense of the people cost: the [BLS](https://www.bls.gov/ooh/computer-and-information-technology/web-developers.htm) reports a May 2025 median wage of $104,000 for web and digital interface designers, and wages make up 70.0% of private-industry employer compensation costs. That puts one designer at about $148,600 a year with benefits. This is why most startups build their system inside product work rather than as a separate project. Our guide to [agency vs freelancer vs in-house](/insights/design-agency-vs-freelancer-vs-in-house) covers who should do that work at each stage.

The return shows up as speed. In Figma's [experiment](https://www.figma.com/blog/measuring-the-value-of-design-systems/), designers with a relevant, up-to-date design system completed their task 34% faster than without one. Figma notes that this is the most you'd expect in practice, because the system fitted the task exactly.

## What makes a design system actually get used?

Completeness and a clear owner. In zeroheight's report, teams with a well-adopted system most often credit component completeness (79%). Teams with poor adoption most often blame a lack of company mandate (73%). Driving adoption has topped the list of biggest challenges for five years in a row.

Stability matters too. Only 8% of practitioners describe their system as very stable, while 34% call it unstable and 10% very unstable. A system that keeps breaking teaches engineers to work around it.

For a startup, that comes down to three habits. Cover the components your team actually reaches for before adding new ones. Have the founder or product lead say the system is the default. Name one owner who answers questions and ships changes.

## How does Alterra Studio help with design systems?

Design systems are part of our [product design service](/services/product-design). We map the flows that matter first, then design the interface against real content and edge cases, and finish with reusable components and tokens your engineers can implement once and use everywhere. Specs are organized for your engineers, and we review builds so the shipped product matches the design. Once paid, the Figma files and the design system are yours.

For HubsAI we mapped every path first, then designed 50 screens and states, from wallet connect to claiming rewards. The landing page, the staking dashboard and the brand film share the same near-black surfaces, glass cards and teal for every action and status. See the [HubsAI case study](/projects/hubsai). We price after a short call; [how we price](/pricing) is on our pricing page.

## The short version

- Most startups need a small design system once more than one person designs or builds UI every week. A full system with a dedicated team is a Series A or later decision.
- Build in order: tokens, then the core components your flows use with every state, then patterns, short docs and a code library. 22% of systems in zeroheight's 2026 survey have no code library.
- There's no reliable market price. The cost is people's time to build and maintain it, and one designer costs about $148,600 a year with benefits at the BLS median.
- Adopt or adapt an open-source base such as Material 3 or shadcn/ui before building your own.
- Adoption depends on completeness and an owner: 79% of well-adopted systems credit component completeness.

## Sources

Checked October 4, 2026. Rechecked October 8, 2026.

- Nielsen Norman Group, [Design Systems 101](https://www.nngroup.com/articles/design-systems-101/) (April 11, 2021), definition, when a system pays back, minimum team, adopt, adapt or create.
- zeroheight, [Design Systems Report 2026](https://report.zeroheight.com/) (published September 30, 2026), survey of 147 design system practitioners: company size, team size, staffing, contents, tokens, adoption and stability.
- Figma, [Measuring the value of design systems](https://www.figma.com/blog/measuring-the-value-of-design-systems/) (December 19, 2019), experiment with Figma's designers.
- Design Tokens W3C Community Group, [designtokens.org](https://www.designtokens.org/), first stable version 2025.10 of the Design Tokens specification.
- Google, [Material Design 3](https://m3.material.io/).
- shadcn/ui, [Introduction](https://ui.shadcn.com/docs).
- US Bureau of Labor Statistics, [Occupational Outlook Handbook: Web Developers and Digital Designers](https://www.bls.gov/ooh/computer-and-information-technology/web-developers.htm), median wage for web and digital interface designers, May 2025.
- US Bureau of Labor Statistics, [Employer Costs for Employee Compensation, June 2026](https://www.bls.gov/news.release/ecec.nr0.htm).