Design Systems for Complex SaaS: Beyond the Style Guide

UI/UX30.07.26

Quick answer. A design system for a marketing site is a style guide. A design system for a complex platform (dealer management, marketplaces, multi-tenant SaaS, inspection tools) is a product. It needs density tiers, multi-context components, token layers, and a governance model. Most "design systems" cloned from public examples fail in B2B because they were built for content, not for dense data and long-running workflows.

The case page for Apolo Tech's WAH APP project frames the goal as "a consistent UI system that scales with features." The phrase sounds simple. The reality underneath has five moving parts.

Why Material clones fail for complex SaaS

The most common failure mode: a team forks a public design system (Material, Polaris, Carbon), strips the brand, ships it. Three months later, the same problems show up.

Dashboards feel cramped or wasteful, because there's no density story.
Components don't compose for nested data (tables inside cards inside sidebars).
Designers and engineers disagree on what counts as a "variant" vs. a new component.
Every new feature ships its own one-off table, modal, or filter pattern.

Public design systems are optimized for the products that built them: Google, Shopify, IBM. Your platform isn't those products. The patterns transfer; the components rarely do.

Density tiers, the silent killer of dashboard UX

Marketing sites have one density. Operational platforms have three.

Comfortable. Onboarding, settings, low-frequency screens. Generous spacing. ~16px base.
Standard. The default. ~12 to 14px base.
Dense. Power-user tables, ops dashboards, listing management. ~10 to 12px base.

A design system that ignores density forces a choice: too cramped for casual users, or too sparse for power users. The fix is a density token layer that swaps spacing, line-height, font size in a single switch, without redesigning every component.

Operational platforms with both occasional and power-user workflows benefit most from this pattern. A dealer-facing system, for example, may surface the same vehicle inventory table in a sales conversation (comfortable) and on a daily ops screen (dense). The component is the same. The density token is different.

Multi-context components vs. design system purity

Pure design systems insist that every component looks identical wherever it appears. Real platforms break this on day one. A button inside a table row needs to be smaller than a button on a landing page. A status pill in a dense list isn't the same as a status pill on a detail header.

The right model is multi-context components, where each component has:

A canonical version (the one in the documentation)
A small number of named contexts (in-table, in-row, in-toolbar)
Strict rules about which props change per context

This sounds like a violation of "one button to rule them all." It isn't. A <Button context="in-row"> is still one button. The rules just acknowledge that rows have different visual constraints than headers.

Tokens, themes, and the three-layer architecture

A design system that survives at platform scale uses three token layers, not one.

1. Primitive tokens. Raw values. color-blue-500, space-4, font-size-14. These almost never change.

2. Semantic tokens. Meaning. color-action-primary, space-component-inline, font-size-body. These map to primitives and change rarely.

3. Component tokens. Local overrides. button-padding-x, table-row-height. These change often as components evolve.

When a designer wants to switch from blue to teal, they update one primitive. When the platform adds a dense theme, they swap a layer of semantic tokens. When a component needs a one-off tweak, only its component tokens move.

Skip this and you'll be doing find-and-replace across a thousand files every time the brand changes.

Governance that scales without slowing teams

The biggest hidden cost of a design system is governance. Who decides what gets added, when, and how.

Three failure modes.

No governance. Every team adds components. The system bloats. Nothing is reusable.
Heavy governance. Every change requires a committee review. Teams stop using the system and ship locally.
Solo governance. One designer owns it. They become a bottleneck, then they leave, and the system rots.

The governance model that actually works:

A small core team (2 to 4 people across design and engineering) maintains the system.
Contribution rules are written down. What can be added without review (component variants), what needs review (new components), what needs an RFC (token changes, breaking patterns).
Quarterly audits remove unused components, deprecate old patterns, merge variants that have drifted apart.

Governance isn't a process document. It's a backlog with owners.

A pre-flight checklist before you start

What density tiers does the product need today, and in 12 months?
What are the top 5 contexts where components appear (table, modal, sidebar, header, form)?
Who owns the system after launch, and how is their time protected?
Are tokens going to be three layers from day 1, or are we adding the layers later?
What's the contribution model for product teams who need a new component?
How will we measure adoption: by team, by component, by page?

If any answer is "we'll figure it out later," figure it out now. "Later" is where design systems die.

The minimum viable design system for a complex platform

You don't need to ship the whole system at once. The smallest useful version covers:

Color, type, spacing tokens (3 layers)
Buttons (canonical + 2 contexts)
Inputs (text, select, search)
Tables (with density variants)
Modals (form modal, confirmation modal)
Status indicators (pill, badge, banner)
Navigation (sidebar, tabs)

That's it. Ship that, get adoption, then expand. Designing 60 components before any of them are used is the most expensive mistake in this space.

FAQ

For a complex platform: 8 to 14 weeks for v1, then ongoing. Anyone quoting 3 weeks is either shipping a Figma library (not a system) or skipping governance and engineering integration.

Should we build our own design system or fork an existing one? Fork the architecture (token layers, governance model). Build your own components. The architecture is a solved problem. Components need to fit your domain.

How long does a real design system take to build?How do we know our design system is working? Three signals. Time-to-ship a new screen drops. Visual inconsistency complaints stop. Engineers stop asking "where is the component for X?". If those three move in 90 days, it's working.

What's the biggest mistake teams make with design tokens? Skipping the semantic layer. Mapping components directly to primitive tokens forces rewriting hundreds of components every time the brand changes. Add the semantic layer on day one.