Design systems for AI startups: what to build before Series A.

Every founder we work with eventually asks: "do we need a design system yet?" The honest answer is — yes, but a small one. Most pre-Series-A teams either build none or over-build one. Both kill velocity.

Here's what a minimum viable design system looks like for an AI startup at seed-to-Series-A stage, and the over-engineering trap to avoid.

The minimum viable system

Tokens (1 hour of work)

• 5 colors: background, surface, text-primary, text-muted, brand-accent
• 4 spacing values: 4px, 8px, 16px, 24px (most UI is built from these four)
• 3 type sizes: body, label, heading
• 1 border radius: rounded-md (don't waste time picking three)

That's it. You can extend later. Named semantically (bg-surface, not gray-100) so refactoring color is one variable change.

Components (1 sprint of work)

Seven components handle 90% of any SaaS dashboard:

1. Button (primary, secondary, ghost)
2. Input field (with label + error state)
3. Card / surface container
4. Table row + header
5. Modal / dialog
6. Badge / status pill
7. Navigation item (sidebar + tab)

Build these once in Figma, mirror them in code (Tailwind components or shadcn/ui), document the basic variants. Move on.

Documentation (1 page)

A single Notion or README page covering: what tokens mean semantically, when to use each button variant, and the rule "if it's not in the system, ask before adding." That's the entire docs requirement at this stage.

---

The over-engineering trap

Here's what kills early-stage teams. They look at Stripe, Airbnb, Material — beautifully documented systems with hundreds of components — and try to reach parity. They spend a quarter building a system before shipping a feature.

Don't do this. At your stage, the actual constraint is:

The number of distinct UI surfaces you have isn't enough to justify abstraction.

If you have 6 screens, you don't need a button library with 14 variants. You need a button. Add variants when the second screen needs a different one. Add components when the third screen needs them.

Build it in Tailwind, not custom CSS

For pre-Series-A teams, Tailwind + a shadcn/ui starter pack is the right base. You get:

• Tokens that already exist (just override the 5 you care about)
• Components that already work (Button, Dialog, Input, Table)
• Accessibility built in
• Dark mode toggle that's one class change
• An ecosystem of recipes when you need new patterns

If your engineers fight you on this, ask them how many weeks they want to spend rebuilding what's already free. Usually the answer is zero.

When to actually invest

Three signals tell you it's time to put real effort into the system:

1. You hire a second designer and they can't move fast without it
2. Engineering velocity is bottlenecked on "let me find the existing component"
3. The product has 30+ distinct screens and inconsistency is showing in demos

Before that, the system you have should be small, tight, and treated as scaffolding — not architecture.

Build small. Ship fast. Refactor when reality demands it.