Design systems for early-stage SaaS: when, how much, how small

Design systems have a reputation problem with early-stage teams. The words suggest a documentation site, a dedicated team and months of work before anyone ships a feature. That version is real, and most startups don’t need it. What they do need, earlier than they expect, is a small set of decisions written down so the product stops drifting.

The drift comes faster now. When engineers and AI coding tools generate UI on demand, a product can pick up five button styles in a week. A small system is what keeps it consistent at that speed.

Signs you need one now

• 01The same button exists in five slightly different versions.
• 02Every new screen takes debate about spacing and colors.
• 03AI coding tools keep generating off-brand UI.
• 04Design and engineering use different names for the same component.

If more than one person is building UI, or one person plus an AI tool, you’re already at the point where a small system pays for itself. Before that, with a single founder building a prototype, it’s fine to move fast and clean up later.

What is the smallest useful design system?

Three parts. Everything else can wait.

• 01Tokens: color, type scale, spacing, radius. Name them by role, like text-muted or surface-raised, not by value, so you can change the palette without renaming everything.
• 02Core components: button, input, select, card, table, modal, toast, empty state. They cover most screens in a typical SaaS product, and each one should handle its real states: hover, focus, disabled, loading and error.
• 03A one-page guide: when to use what. Which button is primary, when a modal is right and when it isn’t, how errors are written.

That’s it. It fits in one design file, one folder of components and one page of text. Most of the value comes from the tokens and the guide, because they’re what stop small inconsistencies from adding up.

Start with the decisions you keep making twice. That’s your design system.

Should you start from an existing component library?

Usually, yes. An established open-source library gets you tested, accessible components on day one, and nobody at a ten-person company should be hand-building a date picker. Your design system is then the layer on top: your tokens, your rules and the handful of components specific to your product. The risk is shipping the library’s defaults and looking like everyone else who used it. Tokens for type, color, spacing and radius are what make it yours.

How do AI coding tools change this?

AI tools follow whatever context they have. Without a system, they fall back on their defaults, and your product starts to look like every other app built with the same tool. Written down in plain text in your repo, the same rules become instructions the tools read before every change. We cover how identity rules work this way in Systems outlive logos.

In practice that means three things: tokens in code, not only in a design file; components the tools can import instead of recreating; and a short text file that describes the rules in words. The guide you write for people is the guide your tools need too.

What should you skip early?

Big documentation sites, every edge-case variant, and a separate design-system team.

• 01A documentation site. One page in your repo is enough until other teams depend on the system.
• 02Every edge-case variant. Build the variants you use today, and add a new one when a second screen needs it.
• 03A separate design-system team. At this stage the system is part of building the product, not a product of its own.
• 04Long naming debates. Pick a convention, write it down and move on.

The rule for growing it: a pattern earns a place in the system when it shows up a second or third time. Until then, it lives in the screen that needs it.

Who maintains it?

One owner, usually your designer or design partner, plus engineers who add components as they need them.

The owner decides what goes in, keeps the tokens and the guide current, and says no to one-off variants. Engineers contribute components as they build features, following the same rules. Without a named owner, the system slowly stops matching the product, and people go back to copying whichever screen looks closest.

How much does a design system cost?

It depends on scope. A starter kit fits inside a launch sprint; a full system is ongoing work. The cost isn’t only the first build. It’s the upkeep: every new feature either uses the system or adds to it, and someone has to keep the two in sync.

Where we fit

Launch (from US$12k) includes a UI kit to start from, built alongside your core product flows. Partner (from US$6k/mo) keeps it up to date as the product grows. Details on /partner.

A starter checklist

• 01Name one owner.
• 02Define tokens for color, type, spacing and radius, named by role.
• 03Build or adopt the core components, with all their states.
• 04Write a one-page guide and keep it in the repo.
• 05Point your AI coding tools at the tokens, the components and the guide.
• 06Add to the system only when a pattern repeats.

If you need a small system your team and your AI tools can build on, send your brief.

• Systems
• Product
• AI