Design systems for SaaS: what to build, in what order, and when to set dates

Build a design system for a SaaS product in four steps: settle the shared foundations, build the few components that carry real product behaviour (data tables, conditional forms, permission states), agree who decides changes, and only then set a release calendar. Each step settles something the next one depends on, so doing them out of order means redoing work. You are ready to commit dates when you can name who approves a breaking change, say which built components depend on each foundation value, and point to no dated item that is still waiting for an approver.

The order at a glance

A list of components with dates against it answers a different question: what gets built when. The order above answers what has to be true before the next thing is worth building.

What a SaaS design system needs

The usual parts of a design system apply to SaaS too:

• Foundations: named values (design tokens) for colour, type, spacing, elevation and motion, plus the treatments every component needs for focus, hover, disabled, error, loading and empty.
• Components in design and code: each with its states defined in code, not only in Figma.
• Patterns: how components combine for recurring jobs, such as bulk actions on a table or a multi-step set-up flow.
• Guidance: when to use a pattern, when to extend it, and when a need should stay local to one product team.
• A way of deciding: who owns changes, what a contribution must show, and how a release reaches the products that consume it.

What makes a SaaS system harder than a marketing site's is where the behaviour lives. Business software spends much of its interface on dense data, roles and states: tables that sort, filter and select; forms whose fields depend on earlier answers; screens a user can see but not edit; status values with more states than there are sensible colours. If the product serves several customers' brands, or several products share one system, the tokens also have to carry themes. In our judgement these are where inconsistency costs users most, and they are the places a library of buttons and badges never reaches.

Step 1: settle the shared foundations

A component is, mechanically, a bundle of decisions about foundation values. When a component ships with a value typed into it rather than referenced from a token, that value now lives in two places. Change it later and every component that copied it needs a matching edit, so the cost of a late foundation change grows with how much has been built on top of it. Settling the foundations first keeps that cost near zero, because nothing yet depends on the value being changed.

For an existing product, start from an inventory rather than a blank file: collect the colours, spacing values, type sizes and state treatments the product actually uses today. The inventory does two jobs. It shows which values to consolidate into tokens, and it shows which components the product keeps rebuilding, which you will need in step 2.

Name tokens by meaning, not appearance: `surface-danger` survives a rebrand, `red-500` does not. The Design Tokens Community Group published the first stable version of its format specification (2025.10), a file format "to exchange design tokens between different tools", in which a token's value can be a reference to another token. That reference is what lets you change a value once and have every component that points at it follow.

Check: open the last three components your team shipped. If any of them uses a colour, spacing figure or font size that is not pulled from the token set, the foundations are not settled, however complete the token file looks.

Step 2: build the few components that carry real behaviour

This is our judgement, and it runs against common advice. Many guides recommend starting with a small core of simple, high-use components (button, input, badge) and working upwards. That advice echoes Brad Frost's atomic design, which describes interfaces built from small "atoms" up to whole pages, although Frost himself calls atomic design a mental model rather than a linear process.

We recommend building two or three behaviour-carrying components early, for three reasons:

1. Simple components do not test the foundations. A badge never asks what a spacing token does inside a five-line table cell, or whether a colour role can represent four permission states instead of two. A data table does.
2. They surface the decisions a design system exists to make. What happens when a variant does not fit the pattern? Who approves a new state? How is an exception recorded so the next team does not rebuild it? A divider raises none of these questions; a form with conditional fields raises all of them.
3. They carry the accessibility work that is hard to retrofit. The W3C's ARIA Authoring Practices pattern for data grids lists ten navigation keys, plus selection commands when the grid supports selection. Getting that right once, in a shared component, saves each product team from working it out again.

If the first components are all the easy ones, a plan can look like progress while the questions that would stall a hard component stay untested. By the time a hard one reaches the calendar, several easy ones have been scheduled on the assumption that those questions were closed.

One survey result is consistent with this, though it measures something neighbouring. In zeroheight's Design Systems Report 2026 (147 practitioners), "component completeness" was the most cited reason for good adoption, at 79% of those explaining why their system is well adopted. That is self-reported and does not say which components mattered; our reading is that a system earns use when it covers what product teams actually build, and in SaaS that means the heavy components.

The cost of this order is real: the first release is likely to take longer, and a hard component built on unsettled foundations will churn, which is why step 1 comes first. Simple components can still ship alongside. The point is that the hard ones set the pace of the plan.

To choose which ones, use your inventory and a test borrowed from the GOV.UK Design System's contribution criteria: there should be evidence that a component "would be useful for many teams or services", and it should not replicate something already in the system. If you cannot name two places in the product that need it, it can stay local for now.

Check: has any component you have built so far handled conditional state, permissions or validation in a real product screen? If every component is presentational, the foundations have not yet met real product logic.

Step 3: agree who decides changes

Before any calendar, three questions need answers:

1. Who can approve a new component, a new variant, or a breaking change to an existing one?
2. What happens when two teams need the same component to behave differently?
3. How does an agreed change reach the products that use it: version, release notes, migration steps?

A useful split, set out in Figma's guidance on design system governance, is by scope. Changes that ripple into every product, such as a base colour token, go to the same small group every time; a product team adding a variant for its own workflow decides for itself. The GOV.UK Design System is a public example of the first kind of rule written down: its team reviews proposals against published criteria (useful and unique to be accepted, then usable, consistent and versatile before publication).

The survey data shows what practitioners blame when adoption is poor. In the same zeroheight report, among respondents explaining why their system is not well adopted, 73% cited lack of company mandate and 55% a weak governance process; the report does not state how many respondents answered that question. Two cautions keep this honest. It is self-reported by people who run design systems. And the report itself notes that 3 out of 4 teams with good adoption did not mention governance at all. Read together, the figures suggest decision rights and leadership mandate are a precondition rather than a driver: a larger share of those explaining poor adoption blame their absence (73% for mandate, 55% for governance) than the share of those explaining good adoption who credit their presence (55% and 24%). Mandate is a leadership decision, so get it alongside the decision rights, not after.

This step does not need a committee. The same report found 28% of design system teams have one or two people and 33% have three to five; at companies of up to 100 employees the average team is two. For a team of that size, the proportionate version is one named owner with authority to accept or decline changes, and one page of rules for what needs their approval.

Check: who, today, is named to approve a breaking change to a shipped component? If the honest answer is nobody, or "we would sort it out", this step is not done, whatever governance document exists.

When you are ready to commit dates

Component count is not the signal. A plan can look far along by count while still sitting in an earlier step than it appears. Place your plan with three questions:

Then, before you put a date on any single row of the plan, test that row:

• Does it use a token or primitive that has not been agreed yet?
• Does it carry product behaviour that has not yet forced a decision about how changes are approved?
• Can you name who will accept it when it ships?

A row that clears all three is safe to date. A row that fails one still has a foundation decision, a governance decision or an approver missing underneath it, however many finished components sit around it on the list. A date only means something once someone is empowered to accept the work behind it.

Restarting a design system that stalled

Having a library is not the same as having a working system. Run the three checks: the first one that fails is where to restart, and adding components before that step holds risks repeating the stall.

Two signs in the product suggest which step failed. Values typed into components, or detached and overridden instances clustered around the same component, point to step 1 or step 2: the system does not yet cover what teams need. Local rebuilds of components the system already has, with nobody able to say who would approve the fix, point to step 3.

To judge an existing system in more depth, see how to audit a design system; to place it on a scale, the design system maturity model. The Design System Drift Checker lets you trace one component through design and code yourself.

What you can build on instead of starting from scratch

You do not have to build every layer yourself. The choice changes how much of step 1 and step 2 you write, not whether you need steps 3 and 4.

shadcn/ui is one example of the middle route. It says of itself: "This is not a component library. It is how you build your component library" (shadcn/ui documentation); it hands you the component code rather than a package to install. That gives control at the price of owning every change.

The first route carries a risk that is easy to miss. Shopify released Polaris Web Components on 1 October 2025, deprecated its Polaris React library in their favour, and archived the React repository on 11 September 2026. Every app still on the React components now has that migration to plan, or runs on code that no longer receives updates. Whoever owns your foundation, you inherit their roadmap.

Whichever route you take, the data tables, permission states and decision rights that make your product yours are still yours to define.

When this order is wrong

The sequence assumes there is a decision worth protecting: more than one team consuming the same components, and enough product surface that a shared pattern will eventually be stretched into a shape it was not built for.

• One team consumes everything. There is nobody for a decision process to arbitrate between, so step 3 has nothing to settle. A lighter shared library and a short list of conventions is the proportionate answer, revisited when a second team or product appears.
• The product is still changing shape release by release. Foundations settled now would likely need settling again once the interface stabilises. This order is work worth doing later, not skipping. In the meantime, a few tokens and naming conventions make the later clean-up cheaper.
• You have not decided whether to build one. This is a plan for teams that already need a design system. It says nothing about whether that decision is right for a given product and team count.
• You are adopting a published system wholesale. Most of step 1 is decided for you. Steps 2 to 4 still apply to the components your product needs that the system does not have.

Where Tcules fits

We are a digital product design studio creating ambitious new software products and making established ones better, with a particular focus on SaaS. For frontend design systems, we can implement tokens, components, documentation, tests, packaging and release acceptance within the agreed product stack. The first useful scope we describe is one component family and one consuming product route, which is step 2 of this order in practice. See Frontend Design Systems.

If you are weighing outside help at all, when to hire a design system consultant sets out what one should deliver. For the hand-off from design to code once components exist, see keeping a React build true to the Figma design.