Why Your First Version Doesn't Need a Design System

Somewhere around a founder's third conversation with a designer, the phrase "we need a design system" shows up, usually before there's a second screen in the product to be consistent with. A design system is a real, valuable thing — for a product with enough surface area that inconsistency has actually become a visible problem. Building one before that point is solving a problem you don't have yet, at the expense of one you do.

What a design system is actually for

It's a shared vocabulary — components, spacing rules, color tokens — that keeps a growing product consistent across a growing team. The value scales with the number of screens and the number of people touching them. A five-screen MVP built by two people doesn't have that problem yet.

What actually happens when you build one too early

• Time spent documenting components that get redesigned twice before the product even launches, because early products change shape fast.
• A false sense of structure that makes the team slower to make the pragmatic, ugly-but-fast decisions an early product actually needs.
• Design decisions frozen into a "system" before you've learned enough from real users to know which ones were right.

What to do instead in version one

A simple, consistent set of styles — one type scale, one color palette, a handful of reusable components — is enough. Treat it as a starting point you'll formalize later, once patterns repeat enough times to be worth naming and standardizing, the same discipline we apply to scoping an MVP generally.

A design system codifies patterns that already proved themselves. Building one before you have proven patterns just codifies your guesses.

The right moment to invest in one is usually obvious in hindsight — it's when a third designer joins, or a fifth new screen makes an old inconsistency painfully visible. Wait for that moment instead of assuming it up front.