Design Systems for Startups: What to Build First

Startups tend to get design systems wrong in one of two opposite ways. Some have nothing: four shades of nearly identical gray, three button heights, and a codebase where every modal is a fresh invention. Others watched a conference talk and spent a quarter building a 200-component library with governance documents, which went stale as soon as the product changed direction. The value of a design system is heavily front-loaded. A small set of decisions and components covers most of what appears on screen, and the rest can wait. This post covers which part to build, in what order, and what to skip on purpose.

When a Design System Is Premature

Start with a gate. If you have not found product-market fit, and one designer and two engineers are reshaping the core product every week, a formal design system will slow you down. Rebuilding components to spec while the product underneath them keeps changing is how a team spends a month polishing screens that later get deleted.

In that phase, do three things. Pick a competent component library off the shelf, such as shadcn/ui, Radix or MUI (the choice matters less than sticking with it). Define your color and spacing tokens at the start. Defer everything else. Tokens cost an afternoon and keep paying off. A custom component library costs months and pays off only once the product stabilizes. If you are still deciding what the first version should contain, our guide to scoping an MVP is the better place to spend your time.

You have crossed the threshold when the same UI pattern gets built a third time by a third person, when a second product surface appears (an admin panel, a marketing site, a mobile app), or when you hire a second designer. At that point the cost of duplication is higher than the cost of building the system. For many companies that happens somewhere between 5 and 15 people working on the product.

Phase 1: Tokens in Week One

Design tokens are named decisions (colors, type scale, spacing, radii, shadows) expressed as variables that both Figma and code consume. They are cheap to define and expensive to retrofit, which makes them the best first investment. A starter set that suits most products:

• Color. One brand palette with 9 or 10 steps, one neutral ramp, and four semantic roles (success, warning, danger, info). On top of those, define aliased semantic tokens: surface, surface-raised, text-primary, text-muted, border, accent. Components reference the aliases and not the raw palette. That one level of indirection is what turns dark mode into a matter of days, not a rewrite.
• Spacing. A 4px base scale with about twelve values, enforced in code review. Arbitrary spacing is the quickest way for a UI to start looking slightly off.
• One typeface, two at most, with a six-step modular scale and three weights. Every text style in Figma maps one-to-one to a code token.
• Three radius values and three shadow levels. Beyond that, few people can tell them apart.

One implementation detail matters more than the rest: define tokens once in a neutral format and generate both sides from it, CSS variables (or a Tailwind theme) for code and Figma Variables for design. Style Dictionary does this, and so does a short script of your own. The Design Tokens Community Group publishes a vendor-neutral token format that is worth following so your file stays portable between tools. Once tokens are maintained by hand in two places, they drift apart, and the system starts to lose its authority.

Phase 2: The Twelve Components That Earn Their Keep

A dozen components appear on almost every screen, and the long tail appears a couple of times a year. Build the first group; buy or improvise the second. A sensible first twelve: Button, Input (with label, error and help text as one composed unit, not four loose pieces), Select, Checkbox/Radio/Switch, Modal, Toast, Card, Table, Tabs, Badge, Avatar, and an Empty State pattern. The last one is easy to overlook. Every list view has an empty state, and teams without a pattern ship blank white screens.

Three rules keep this phase from bloating.

1. Extract, don’t speculate. A component enters the system after it exists in the product twice, and it is built from the best existing instance. Components designed in the abstract for imagined future uses usually end up with the wrong API.
2. Build on primitives. A startup has little reason to hand-roll focus traps, keyboard navigation and ARIA wiring. Brand-styled components over headless primitives such as Radix Primitives or React Aria give you a sound accessibility baseline, which you should still test against the WAI-ARIA Authoring Practices and WCAG 2.2 AA. Hand-rolled modals are a common source of accessibility bugs.
3. Cap variants firmly. A Button needs about three variants and three sizes, nine combinations in total. Suppose a team inherits a Button with dozens of variant combinations: people become afraid to touch it and build new buttons beside it, which is the exact failure the system was meant to prevent. A variant used once is a one-off, and one-offs can live outside the system.

Phase 3: Documentation, Less and Later Than You Think

For a system of this size, a heavyweight documentation site is a poor use of time. The documentation people read is a Storybook (or equivalent) showing every component in every state, one-line usage notes on the Figma components (“use Danger only for destructive actions”), and a single do and don’t page for the five most misused patterns. Write down only what people repeatedly get wrong, and let the components and a quick question in Slack cover the rest.

A Figma-to-Code Workflow That Prevents Drift

A design system fails quietly when Figma and code disagree and nobody notices for a quarter. Four habits prevent that.

• Same names on both sides. The Figma component Button/Primary/Md corresponds to <Button variant="primary" size="md">, and props mirror variant properties exactly. Designers and engineers then share one vocabulary.
• Tokens flow one way. Changes happen in the source file, regenerate to Figma Variables and code on merge, and are announced. Nobody edits a hex value directly on either side.
• Connect the core components to code. With Figma Code Connect or a similar tool, an engineer inspecting a design sees the real prop names and import path, not generated markup. For a dozen components the setup is small, and it removes a lot of guesswork, including for AI coding tools, which work better from real component APIs than from pixels.
• Hold a 30-minute triage every week. One designer and one engineer go through each deviation flagged that week and decide whether the code is wrong, Figma is wrong, or the system has learned something new. A small, regular meeting keeps drift measured in days.

What to Skip at Startup Scale

• Multi-brand theming architecture, until you have a second brand. The semantic alias layer described above keeps that door open at almost no cost. The full theming machinery does not.
• A dedicated design-system team. Below roughly 30 engineers, the system works best as a shared responsibility with one named maintainer who gives it a modest, fixed part of the week. A full-time platform squad in a company of 12 is more structure than the work needs.
• Visual regression tests on everything. Snapshot the twelve core components, which is cheap and worthwhile. Screenshot-diffing every page in CI at this size tends to produce more flaky failures to triage than bugs caught.
• Versioned releases with changelogs and deprecation policies. If the system and the product live in the same repository (at this stage they should), ship system changes together with product changes. Semantically versioned packages are for the day several repositories consume the system.

Multi-Platform Tokens

If a mobile app is on your roadmap, the token layer pays off twice. The same source file that generates CSS variables and Figma Variables can also emit a Dart theme for Flutter, Swift constants or a React Native theme object, and Style Dictionary supports these targets. Picture a product shipping on web, iOS and Android: one pull request that changes accent reaches all three platforms in the same release and is reviewed once. Without a generated pipeline, the same change is three tickets and three reviewers, and the brand color slowly diverges between platforms. Components rarely share across web and native; tokens should. Setting this up before the second platform exists is a small piece of build configuration, and doing it afterwards means auditing every hard-coded value. Our post on when to choose Flutter covers the platform decision itself.

Why the Small System Pays Off

We do not publish speed-up percentages, because they depend on the team, the product and what you compare against. The reasoning holds without them. Every screen built from existing components skips decisions that were already made, so implementation gets faster as coverage grows. Design review shifts from “this padding is wrong” to questions about the flow, because the padding comes from a token. Theme changes such as dark mode or a rebrand become edits to the alias layer instead of a hunt through every stylesheet. The cost is a steady, modest share of one designer’s and one engineer’s time.

If you want a design system sized to your actual stage, including being told you do not need one yet, our UI/UX design team works this way, with a design review every week. Get a quote and tell us where your product is today.