Design Systems for SaaS — The Pragmatic Build (Not the Figma One)

If you've ever joined a SaaS company at series A or B, you've heard "we need a design system." Six months later, there's a beautiful Figma file and 200 ad-hoc components in code that nobody reuses.

The problem isn't ambition. The problem is treating the design system as a design artefact instead of a code contract.

This is the 4-week build we use to ship one that actually sticks.

The wrong way (don't do this)

The pattern that fails:

1. Designer creates a Figma file with primary colors, type scale, button variants
2. Designer shares it with the eng team
3. Eng team builds components "according to Figma"
4. Six months later, the Figma file and the code have drifted irreconcilably
5. Designer adds new variants in Figma without telling eng
6. Eng adds new variants in code without telling design
7. Both halves rot

The pragmatic way

Treat the design system as a shared API contract. Same way you'd treat a REST API between frontend and backend.

Week 1: tokens, not components

Don't start with components. Start with design tokens:

• Color (12 grays + 1 accent + 4 status colors max — Microsoft Fluent does this)
• Typography scale (5 sizes, 3 weights — not 14 sizes, 7 weights)
• Spacing (4px base unit, geometric scale: 4, 8, 12, 16, 24, 32, 48, 64)
• Radius (3 values: 4px, 8px, 12px — not 7 random values)
• Shadow (4 levels: subtle, card, popover, modal — not "shadow-1" through "shadow-9")

These tokens live as CSS custom properties in code, mirrored as Figma variables. One source of truth for each token, synced via Tokens Studio or a custom script.

Week 2: 12 components, no more

Build only the 12 components that you use every day:

1. Button (3 variants: primary, secondary, ghost)
2. Input + Select (textual form fields)
3. Card (the container — your bread and butter)
4. Modal
5. Drawer
6. Toast
7. Table (the workhorse for SaaS dashboards)
8. Avatar
9. Badge / Tag
10. Tooltip
11. Tabs
12. Empty state

Resist the urge to build "all the components." The 12 above cover 90% of a SaaS UI. The remaining 10% can wait.

Week 3: documentation as code

For each component, write a single Markdown file that contains:

• A live React playground (via Storybook or Histoire)
• The component's TypeScript interface
• A "do" / "don't" example pair
• A link to the relevant Figma frame

The Markdown lives next to the component code, not in a separate docs site. This is non-negotiable. Docs that live in a separate repo always rot.

Week 4: the migration script

Before you start migrating existing pages, write a codemod that does 80% of the work mechanically:

• <div className="card"> → <Card>
• className="text-lg font-bold" → <Heading size="md">
• Inline colour hex → token CSS variable

A good codemod handles 80% of cases. The remaining 20% becomes the design team's "review queue" for the next 2 sprints.

The governance pattern

Pick one engineer and one designer as the design system owners. Every new component or token change goes through a 24-hour async review with both of them.

Without this, you'll have 14 button variants by month 3.

What we built for ourselves

The NextGen Digital Craft website itself uses this exact pattern:

• 11 tokens total (color, type, spacing, radius, shadow)
• 14 components in the design system
• All token changes are PR-reviewed
• Figma stays in sync via a 30-line sync script run nightly

After 12 months we have zero ad-hoc colour or spacing values anywhere in the production code. Every change is a token edit.

When this fits you

• Your SaaS has 3+ frontend engineers
• You've started writing the same button variant in 4 different files
• Your designer has stopped trying to update Figma because "engineering won't follow it anyway"

If that's you, book a call and we'll share the exact 4-week plan, customised to your stack.