Design Systems for SaaS: When to Build One, What It Costs, and How to Keep It Alive

Your product has nine button variants. Four shades of the same blue. A modal that looks different on every page it appears. A designer who, when asked which is the correct primary button style, opens four different Figma files before giving up.

This is not a design problem. It is a coordination problem — and a design system is the coordination mechanism. But it is also not a problem every product needs to solve with a full design system. Most products that commission one don’t need one yet. Some that need one commission the wrong kind. And most that build one let it decay within six months.

This article covers what a design system actually contains, when building one is the right decision, what it costs, and — the part most guides skip — how to keep it alive after it’s built.

---

What a Design System Actually Contains

Tokens, Components, Patterns, Guidelines — The Four Layers

A design system has four layers. Conflating them is the most common reason systems are either over-built or under-built.

Tokens are the raw design decisions expressed as named variables: color values, typography scales, spacing units, border radius, shadow definitions. A token is not a color — it is a named relationship between a color and its intended use. color-primary-action: #1A73E8 is a token. #1A73E8 alone is a value.

A token hierarchy for a typical SaaS product works across three levels. Primitive tokens hold raw values — blue-500: #1A73E8, space-4: 16px. Semantic tokens reference primitives with intent — color-button-primary: blue-500, padding-input: space-4. Component tokens reference semantic tokens with scope — button-primary-background: color-button-primary. This three-level structure means a global change propagates without touching component definitions.

Components are the reusable UI elements built from tokens: buttons, inputs, modals, tables, navigation elements. A component in a design system is defined in both Figma and code. A Figma component with no code equivalent is a UI asset, not a system component.

Patterns are compositions of components that solve recurring product problems: an empty state pattern, a data table with sorting and filtering, a notification system. Patterns answer “how do we handle this situation?” rather than “what does this element look like?”

Guidelines are the documented rules governing when and how tokens, components, and patterns are used. Without guidelines, a component library produces inconsistency at a higher level of abstraction — you’ve standardized the button, but seventeen different page layouts still exist because nobody documented how pages should be structured.

The Difference Between a UI Kit and a Design System

A UI kit is a set of Figma assets — organized components, color styles, text styles — that designers use to build screens faster. It solves the design consistency problem for the design team.

A design system includes the UI kit, the corresponding code implementation, a governance model for how changes are proposed and approved, a versioning scheme, and documentation that explains how to use everything correctly. It solves the consistency problem for the entire product organization — design, engineering, and product management.

Most teams that say they have a design system have a UI kit. This is not a failure, but it is a different thing with different capabilities and different limitations.

The Code Side: Why a Figma Library Alone Solves Nothing

A Figma component library that isn’t reflected in the codebase creates a new problem: design and implementation diverge. A real design system requires a code component library — React, Vue, or framework-specific — built from the same tokens as the Figma library. When the primary button color changes, it changes in Figma and in production simultaneously, from one source of truth.

When You Should Build One — and When You Should Not

The Triggers: Team Size, Surface Count, Release Cadence

Three signals indicate a design system investment is warranted: more than one designer working in parallel on the same product, more than one product surface requiring shared design language, and repeated inconsistency bugs appearing in engineering tickets more than twice a month.

Headcount alone is not the signal. A two-person team shipping across a web app, mobile app, and admin panel needs a system more than a ten-person team with one well-maintained surface.

Why Pre-PMF Products Usually Should Not

A design system is infrastructure. Building infrastructure before the product it serves is stable is expensive. If your product hasn’t reached product-market fit, your UI is still changing significantly based on what you learn from users. A design system locks in decisions — about component behavior, token structure, interaction patterns — that are likely to change. The calculus changes when the product stabilizes. If your core flows have been consistent for six months and you’re hiring a second designer, that is the time.

The Middle Path: A Component Inventory Instead

Between “no system” and “full design system” is a component inventory: a documented list of every UI element currently in production, with screenshots, their variations, and which are the intended canonical versions. It takes days rather than months, requires no tooling decisions, and immediately solves the “which button is correct” problem. It is not a design system — but it is the foundation one gets built from, and for many teams it’s sufficient for the next six to twelve months.

Building It Without Stopping the Roadmap

Start From an Audit of What Already Exists

Before creating anything new, document everything that already exists in production. Google’s Material Design was built from an audit of inconsistency across Google products — the team counted 27 different blue values before establishing a token hierarchy. Shopify’s Polaris began with an audit of the Shopify admin UI. In both cases, the audit defined the scope of the work rather than assumptions about what the system needed.

Tokens First, Components Second

The most common sequencing mistake: starting with components before establishing tokens. Components built without a token foundation embed raw values directly into their definitions. When those values need to change, every component must be updated individually. Establish tokens first. Build components that consume tokens, not raw values. Token changes then propagate automatically to every component that uses them.

Adopt Incrementally: The Next-Feature Rule

Do not pause the roadmap to build the design system as a standalone project. Instead, apply the next-feature rule: the next feature that gets built uses system components. When a system component doesn’t exist for what’s needed, it gets built as part of that feature’s scope. This approach means the system grows alongside the product, is tested against real product needs rather than hypothetical ones, and never becomes a blocking dependency for shipping. IBM’s Carbon Design System was adopted across IBM’s product portfolio incrementally over eighteen months rather than in a single migration.

Accessibility Baked In, Not Retrofitted

Accessibility compliance — WCAG 2.1 AA as a minimum — is significantly cheaper to build into a design system than to retrofit into a production codebase. Color contrast ratios, focus states, keyboard navigation, ARIA labeling become default behaviors of system components rather than per-feature considerations. The cost of retrofitting accessibility into a SaaS product that hasn’t considered it is routinely underestimated.

What It Costs

Initial Build: Effort by Product Size

For a focused SaaS product with one primary surface: six to ten weeks of dedicated designer time plus four to six weeks of engineering time to build the code library.

For a multi-surface SaaS product — web app, mobile, admin panel — with cross-surface consistency requirements: twelve to twenty weeks of designer time plus eight to twelve weeks of engineering time.

These estimates assume the system is being built alongside the roadmap. A standalone project compresses the timeline but typically produces a system that doesn’t reflect real product needs as accurately.

The Ongoing Cost Everyone Forgets

A design system has a maintenance cost from the day it ships. Component updates when the product evolves. Token changes when the brand updates. Deprecation of components no longer used. Documentation updates when behavior changes. New component creation when new features require them.

This ongoing cost is typically ten to twenty percent of a senior designer’s time and five to ten percent of an engineer’s time, indefinitely. Teams that build a system without planning for this cost end up with one that decays — which is worse than not having one, because decay is invisible until it’s severe.

Where the Savings Actually Show Up

The return shows up in three places: reduced design time (thirty to fifty percent faster for screens within system coverage), reduced engineering time (twenty to forty percent faster implementation), and reduced QA time (fewer inconsistency bugs, clearer expected behavior). The savings compound over time as coverage increases and are largest when the product is shipping at high velocity across multiple surfaces.

Keeping It Alive

Ownership Models: Central Team, Federated, Hybrid

Central ownership: a dedicated team or individual owns the system, reviews all contributions, and controls releases. Produces the most consistent system. Becomes a bottleneck at scale.

Federated ownership: teams own their own component domains. Faster iteration. Produces drift between domains without strong governance.

Hybrid: a small central team owns tokens and core components. Feature teams own domain-specific components and contribute back through a defined process. This is the model both Material Design and Polaris operate on at scale — and it’s appropriate for most growth-stage SaaS teams.

Contribution and Deprecation Workflows

Without a defined contribution process, the system grows by accretion — components get added without review, creating redundancy. Without a deprecation process, old components stay alongside replacements, creating confusion about which is canonical.

A minimal contribution workflow: propose, review, build, approve and merge. A minimal deprecation workflow: announce, migrate, remove after a defined period.

Versioning and Breaking Changes

Adopt semantic versioning from the start. Major versions introduce breaking changes. Minor versions add functionality without breaking changes. Patch versions fix bugs. Document breaking changes explicitly and give consuming teams a migration period. This is the difference between a system teams trust and one they fork to avoid.

Measuring Adoption and What to Do When It Stalls

Track adoption as a percentage of production UI covered by system components. A new system should aim for sixty to seventy percent coverage within six months. Below forty percent at six months signals that the system doesn’t cover what teams actually need, or using it is slower than improvising. Fix the friction rather than mandating adoption.

Common Failure Modes

The System Nobody Uses Because It Is Slower Than Improvising

A design system that makes designers and engineers slower to ship will be abandoned, regardless of how technically correct it is. If using a system component requires more steps than writing a one-off solution, teams will write the one-off solution. Speed of use is a first-class requirement.

Over-Abstraction: Components With Nineteen Props

A button with nineteen configuration props is not a component — it is an interface that requires reading documentation to use correctly. Build for the cases that actually exist. Add props when real product needs require them, not in anticipation of hypothetical future needs.

Documentation That Went Stale in Month Three

Documentation that doesn’t reflect current component behavior is worse than no documentation — it produces incorrect implementations that look correct. Treat documentation as a deliverable of every component change. Merge requests that change component behavior require documentation updates before they’re approved.

Conclusion

A design system is infrastructure. Like all infrastructure, it should be built when the cost of not having it exceeds the cost of building and maintaining it — and not before.

When the triggers are present — multiple designers, multiple surfaces, visible inconsistency — a system investment pays back quickly and compounds over time. When they’re not, a component inventory and a shared Figma library are sufficient.

The systems that survive are the ones with an owner, a governance model, and a version history. The ones that fail are treated as a project that ends at launch.

If your SaaS product’s UI has drifted and you’re evaluating whether a design system is the right investment, the starting point is usually a UI/UX audit — inventory what exists before deciding what to build. See how we’ve approached design systems across our case studies. Book a scoping call to discuss your specific situation.

FAQ

• What is a design system?

  A design system has four layers: tokens (named design decisions like color values and spacing), components (reusable UI elements built from tokens), patterns (compositions of components for recurring product problems), and guidelines (rules governing when and how each layer is used). A design system is distinct from a component library — it includes governance, versioning, and documentation, not just assets.

• When is a SaaS product ready for a design system?

  Three concrete triggers: more than one designer working in parallel on the same product, more than one product surface requiring visual consistency, and repeated engineering tickets about inconsistency. Headcount alone isn’t the signal — a two-person team shipping across four surfaces needs a system more than a ten-person team with one.

• How long does it take to build a design system?

  For a focused SaaS product: six to ten weeks of designer time plus four to six weeks of engineering time. For a multi-surface platform: twelve to twenty weeks of design plus eight to twelve weeks of engineering. Adoption takes longer than creation — seventy percent production coverage at six months is ahead of average.

• What is the difference between a design system and a UI kit?

  A UI kit is a Figma asset library — components and styles for designers to use when building screens. A design system includes the UI kit, a corresponding code library, governance rules for how changes are proposed and approved, semantic versioning, and documentation. A UI kit solves design-side consistency. A system solves it across design and engineering simultaneously.

• Should we use Material UI instead of building our own?

  Yes, in specific cases: when speed to market matters more than brand differentiation, when your team lacks dedicated design system capacity, or when your product’s visual identity is flexible. The long-term cost is real — Material UI’s component API shapes your UI decisions and significant customization becomes progressively harder. Polaris and Carbon are worth studying for their token architecture even without full adoption.

• Who should own the design system?

  A named owner is non-negotiable — unowned systems decay predictably. Central ownership produces consistency but creates bottlenecks at scale. Federated ownership moves faster but drifts without governance. The hybrid model — a small central team owns tokens and core components, feature teams contribute domain components — is the right default for most growth-stage SaaS companies.