Does a Design System Pay for Itself at Your Size?

Design systems are sold as inevitable. Below a certain size they are a beautifully documented way to avoid shipping.

The case for a design system is compelling and mostly true at scale: consistent interface, faster delivery, fewer decisions relitigated. The question nobody asks is at what size the maintenance cost is smaller than the inconsistency it prevents.

The break-even signals

• More than one product surface. A single marketing site does not need a system; a site plus an app plus a client portal does.
• More than two people building interface. Below that, conventions live in their heads and stay consistent for free.
• Recurring arguments about the same component. If button variants get redesigned quarterly, the system pays for itself in avoided debate alone.
• Onboarding frequency. If new contributors join regularly, documented components are how they ship in week one instead of week four.

What to build first

1. Tokens: colour, spacing, type scale, radius. This is 80% of visual consistency for 10% of the work.
2. The five components that appear on every screen — button, input, card, modal, navigation. Not the exotic ones.
3. Usage rules, not just appearance. When to use each variant matters more than how it looks.
4. Accessibility built in at the component level, so it cannot be forgotten per-screen.

Avoiding the museum

The failure mode is a beautiful library nobody uses, because it lags the product. Keep the system in the same repository as the product, let it grow from real screens rather than ahead of them, and delete components nobody uses. A system with forty components and eight in use is not a system; it is a maintenance liability with good documentation.

• 2+ people building interface
• 5 components worth doing first
• 80% of consistency from tokens alone