Explore
Building a Lean Design System for Your Startup

Building a Lean Design System for Your Startup

You don't need 200 components and a Storybook instance on day one. Here's how to build a design system that scales with your product rather than ahead of it.

Building a Lean Design System for Your Startup

Design systems are seductive. The idea of a single source of truth for every button, every input, every modal — it sounds like engineering done right.

The problem is that most startups build their design system for the product they imagine they'll have, not the product they're building. The result is months spent on infrastructure for a product that changes direction after the first user interviews.

Here's how to build a design system that actually serves an early-stage startup.

Start with tokens, not components

Before you write a single component, define your design tokens: colours, spacing scale, typography, border radii, shadows.

In CSS, these are custom properties:

:root {
  --color-brand: #2563eb;
  --color-brand-dark: #1e40af;
  --color-text: #111827;
  --color-text-muted: #6b7280;

  --space-1: 0.25rem;
  --space-2: 0.5rem;
  --space-4: 1rem;
  --space-8: 2rem;

  --radius-sm: 0.25rem;
  --radius-md: 0.5rem;
  --radius-lg: 1rem;

  --font-size-sm: 0.875rem;
  --font-size-base: 1rem;
  --font-size-lg: 1.125rem;
  --font-size-xl: 1.25rem;
}

With tokens defined, every component you build is automatically consistent. You don't need to coordinate colours across components — they all reference the same values.

The components you actually need first

Resist the urge to build everything. Start with what the product actually uses.

Phase 1 — Essentials:

  • Button (with variants: primary, secondary, ghost, destructive)
  • Input and Textarea
  • Badge / Tag
  • Card
  • Modal / Dialog
  • Avatar

Phase 2 — As needed:

  • Select and Combobox
  • Table
  • Toast / notification system
  • Tabs
  • Dropdown Menu

Don't build until you need:

  • DatePicker
  • DataGrid with sorting/filtering
  • RichTextEditor
  • DragAndDrop primitives

The rule: build a component when you're about to use it in a second place. One-off components don't need abstraction.

Composition over configuration

Two approaches to flexible components:

Option A — Prop-driven:

<Button variant="primary" size="lg" :loading="isLoading" :disabled="!isValid">
  Save changes
</Button>

Option B — Slot-driven:

<Button>
  <SpinnerIcon v-if="isLoading" />
  Save changes
</Button>

For early-stage products, prop-driven is usually better. It's explicit, easy to understand, and the API is self-documenting. Move to composition when the component needs to be genuinely open-ended.

Adopt a component library as a foundation

Building from scratch makes sense for a handful of truly custom components. For everything else, starting from an existing library saves weeks.

Good options for Vue/Nuxt projects:

  • shadcn/vue — unstyled, copy-paste, full control
  • Nuxt UI — styled, production-ready, built for Nuxt
  • Radix Vue — primitives for accessibility-heavy components

The strategy: use the library for primitives (modals, dropdowns, form elements where accessibility matters), customise with your tokens, build bespoke components for your differentiated UI.

Skip Storybook until you're ready

Storybook is a powerful tool for documenting components at scale. It's also real maintenance overhead for a startup moving fast.

Skip it for your first six months. Your "documentation" at this stage is the component usage itself — good naming, sensible props, and an example in a real product page is usually enough.

Introduce Storybook when:

  • You have multiple developers who need to discover what exists without reading code
  • You have a designer who needs to review components in isolation
  • Your component library is large enough that finding things becomes a problem

Versioning: don't bother early

Large organisations version their design system as a separate package. Startups shouldn't. It's extra overhead for zero benefit.

Keep your components in the same repo as the product. Refactor freely. Break things without ceremony. The cost of moving fast outweighs the benefit of stability when you're the only consumer.

The lean design system in practice

Here's what a lean design system looks like at a 6-month-old startup:

  • components/ui/ — 10-15 primitive components
  • assets/styles/tokens.css — design tokens
  • A shared Figma file with components matching the code
  • No Storybook, no versioning, no changelog
  • Conventions documented in a README or Notion page

That's enough to build consistent UI fast, onboard new contributors, and evolve as the product grows.

When you're ready to scale it, you'll know — because you'll feel the friction of the current approach and have concrete reasons to invest in more.

Building on Vue or Nuxt? See how we work →

Back to all articles