What Is a Design System and Does Your SaaS Product Need One?

Most SaaS products start without a design system. That is the right call at the MVP stage, spending weeks building a comprehensive component library before you know what the product looks like in the hands of users is premature investment. But most products also reach a point where the absence of a design system starts costing them: inconsistent interfaces across features, design-to-development handoffs that produce unexpected results, new features that look slightly different from old ones, and designers spending hours rebuilding components that already exist somewhere in a previous Figma file. At Inity Agency, we build design systems as part of SaaS product engagements, from the first design token to the component library that scales with the product. This post explains what a design system actually is, what it contains, and when your product needs one.

What a Design System Actually Contains

A design system is not one thing — it is a layered set of assets and standards that work together. Understanding the layers helps clarify what a design system is versus what it is not.

Layer 1: Design Tokens

Design tokens are the foundation of the system. They are named variables that store visual design decisions — colours, typography scales, spacing values, border radii, shadow definitions, animation durations – in a way that applies consistently across the entire product.

The practical value of tokens: instead of hardcoding a hex value (

) in every component, a designer uses a token (). If the brand colour changes, updating the token once propagates the change everywhere the token is used — across every button, every link, every highlighted state in the product simultaneously.

Two types of tokens matter in a mature design system:

Primitive tokens – raw values:

, . These define the palette and scale.

Semantic tokens – purpose-driven values that reference primitives:

, . These describe the token’s role rather than its appearance, enabling theme switching (dark mode, white-label, high contrast) without rebuilding components.

Layer 2: Component Library

The component library is the set of reusable UI elements built on top of the design tokens. Buttons, form fields, dropdowns, modals, tables, navigation bars, tooltips, empty states, loading indicators, every repeating interface element exists as a single, documented, reusable component rather than being recreated independently for each feature.

Each component has documented states: default, hover, focus, active, disabled, error. Each state is built from tokens. This means that when a token changes, every component state that uses it updates automatically.

In Figma, the component library is a shared library that design team members can pull from when designing new features. In code, it is a component library (typically in React or Vue) that developers import rather than rebuild.

Layer 3: Usage Guidelines

Components alone are not enough. A design system includes documented guidelines explaining: when to use a primary button versus a secondary button, when to use a modal versus a drawer, how to structure form layouts, what information architecture patterns to follow for navigation. Without usage guidelines, two designers will use the same components differently, producing inconsistent interface patterns even from the same component set.

Layer 4: Code Standards and Developer Handoff

A design system is only useful if it connects the design to the code. This means: design component names match code component names, design tokens are exported and consumed by the codebase (via CSS custom properties, Sass variables, or a dedicated token pipeline), and there is a documented process for when and how components are updated. In mature design systems, tools like Storybook provide a living documentation of the coded component library that developers reference during implementation.

What a Design System Is Not

A design system is not a style guide. A style guide covers visual rules; fonts, colours, logo usage, imagery tone. A design system includes those rules but adds reusable components and code standards. You can follow a style guide and still produce an inconsistent interface. A design system makes consistency the path of least resistance.

A design system is not a Figma file. A Figma component library is one artefact within a design system. Without the corresponding coded components, the usage documentation, the token structure, and the governance process, a Figma file is a component inventory, not a design system.

A design system is not a one-time project. It is a living product that requires maintenance as the product evolves. New components need to be added. Existing components need to be updated when design decisions change. Tokens need to be extended when new themes are introduced. The governance process, who owns the system, how changes are approved, how components are versioned: is as important as the system itself.

When Does a SaaS Product Need a Design System?

At the MVP stage: almost certainly not yet. The product is changing too rapidly, the feature set is not stable enough, and the team is too small for a comprehensive design system to be worth the investment. Building a full design system before the core product is validated is one of the most common forms of premature investment in early-stage SaaS.

The signs that a design system is now worth the investment:

1. Interface inconsistency is visible to users. Different features look slightly different. Buttons are subtly different sizes. Spacing is inconsistent between sections. The product does not look like a cohesive whole. This is the most visible signal.

2. New features take longer to design than they should. Designers are rebuilding components that already exist, or hunting through old Figma files for how a specific pattern was handled six months ago. Design velocity has slowed despite the team growing.

3. Development does not match design. Developers are making approximation decisions during implementation because the design specification is not specific enough, or because there is no shared component library to reference. The gap between design intent and production output is growing.

4. A rebrand or visual refresh is coming. Without a design system, updating brand colours and typography across a product requires finding and updating every instance manually. With a design system, it requires updating the relevant tokens.

5. The team is growing. A design system accelerates onboarding. New designers and developers have a clear reference point for how the product is built. Without one, onboarding time increases and design drift becomes inevitable.

For most SaaS products, the right time to invest seriously in a design system is at seed stage, after the product is validated, before the team expands significantly and inconsistency compounds.

What Happens to Products That Scale Without One

The cost of not having a design system is not felt at day one. It compounds. Here is the pattern we see repeatedly:

A product launches with a clean, consistent interface designed by one or two people who shared a common visual language. Features are added by a growing team. Each designer makes slightly different decisions, slightly different spacing, slightly different button hierarchy, slightly different modal patterns. Over 18 months, the product develops visual inconsistency across its surfaces.

A new hire joins the design team. They spend weeks understanding how existing patterns work before they can contribute. They build a component that already exists in a slightly different form somewhere else. The codebase now has two implementations of what should be one component.

A rebrand is proposed. The design team estimates eight weeks of work to update every screen. The development team estimates four weeks of implementation. A change that should have taken two days, updating design tokens, takes twelve weeks and introduces regressions.

Design systems exist to prevent this compounding. The earlier they are introduced, the less retrofit work is required.

How Inity Builds Design Systems

At Inity, every SaaS product engagement includes a design system as a standard output, not as an optional add-on. The design system is built alongside the product, not after it.

The process starts with tokens: colour palette (including semantic naming), typography scale, spacing system, border radius, elevation/shadow scale, and motion tokens. These are defined before a single component is built, and they are defined in Figma variables that export to CSS custom properties in the codebase.

Components are built from tokens — every state, every variant, every responsive behaviour documented in the Figma shared library and implemented in the React component library. Design and development use the same naming conventions so that “Primary Button / Large / Active” in Figma maps directly to

in code.

For clients at later stages with existing products and accumulated design debt, we conduct design system audits, cataloguing the existing component inventory, identifying inconsistencies, and producing a phased remediation plan that allows the team to keep shipping while the system is introduced.

Conclusion

A design system is not about aesthetics. It is infrastructure, the mechanism by which a SaaS product stays consistent, ships faster, and onboards new team members without introducing drift. At the MVP stage, it is premature. At seed stage and beyond, the absence of one starts costing time, quality, and velocity in ways that compound. The design system that is built alongside a product from the beginning requires far less investment than the one that has to be retrofitted onto a product whose interface has already diverged across dozens of screens and two codebases.

→ Scaling a SaaS product and starting to feel the friction of inconsistency? Inity builds design systems as part of every SaaS engagement — tokens, components, documentation, and code standards. Book a call.