Design systems: why they save agencies (and clients) real money

Every design system conversation eventually hits the same objection: "we don't have time to build a design system, we need to ship features." This is true for exactly the first two or three screens. After that, it inverts: every screen built without a system is a screen that has to be individually maintained, individually made responsive, and individually fixed when the brand color changes.

The break-even point is earlier than people think

In practice, we've found the break-even for a small, focused design system lands around the fourth or fifth unique screen. Before that, hardcoding styles is genuinely faster. After that, every new screen assembled from existing tokens and components ships in a fraction of the time, and more importantly, stays consistent without anyone remembering to check.

• A token layer (color, spacing, type scale) takes a day to set up and eliminates almost all visual drift across a build
• A dozen well-built primitives, button, input, card, modal, table, cover the vast majority of any B2B or SaaS product
• Documentation matters less than component API consistency: a predictable prop pattern teaches itself

The version that actually gets used

The failure mode isn't skipping a design system, it's building one so heavy that it becomes its own project. A design system with 40 components, five variants each, and a separate Figma library that drifts from the code within two sprints is worse than no system at all, because it creates false confidence. The systems that survive are small, live in code (not just Figma), and grow only when a real second use case demands a new component.

A lean system, in practice

• Tokens for color, spacing, radius, and type live in one config file, not scattered across components
• Components are built with variants (size, tone, state), not duplicated for every context
• New components get added when a third screen needs the pattern, not speculatively
• Design and code stay in the same repo where possible, so drift is a merge conflict, not a silent divergence

What this actually saves a client

The visible saving is development speed on screen four onward. The invisible saving is bigger: when a client asks for a brand refresh six months post-launch, a token-based system means changing a handful of values, not touching every screen. We've done both. A rebrand on a token-based system took an afternoon; the same change on a hardcoded build took most of a sprint.