Design systems get recommended reflexively now, the same way microservices do on the engineering side, and for similar reasons: they're genuinely valuable at the right scale, and genuinely overkill below it. We build them for a meaningful share of our projects and deliberately skip them for others, and the deciding factor is rarely the client's budget — it's how much the product is actually going to grow and change.
What a design system is actually buying you
The real value of a design system shows up when multiple designers and developers are working on the same product over an extended period, and when the product is expected to keep growing new screens and features for years, not months. A documented, reusable component library keeps a growing product visually consistent without every new screen requiring a fresh design decision about button styles or spacing — and it keeps new team members productive faster, because the rules are written down instead of living in one designer's head.
It also pays off directly in development speed once it exists — a developer building a new screen from an established component library moves noticeably faster than one designing each element from scratch, because most of the decisions are already made and just need to be assembled. That compounding speed benefit is the whole case for building one in the first place.
Where it's just overhead
For a smaller build — a single marketing site, a straightforward MVP meant to validate an idea before further investment, a one-off project with no planned follow-up phases — a full design system is often more process than the project needs. Building comprehensive documentation and a reusable component library for a product that might get five screens total and never expand past its first version is time spent on infrastructure the project will never fully use.
We've seen this go wrong in both directions. A client who insisted on a full design system for a simple three-page site paid for weeks of documentation work that added no visible value to the final product. A client on the other end who scaled a growing product for two years with no consistent component structure ended up with a UI that looked like it was designed by five different people — which, by that point, it effectively had been, one ad hoc screen at a time.
The middle ground we usually land on
What we default to for most mid-sized projects is a lightweight version — a documented set of core components (buttons, forms, cards, typography scale, color tokens) without the full governance process a large enterprise design system would need. It's enough to keep a product consistent as it grows, without the overhead of a process built for a team five times the size actually working on it. We can always formalize it further later if the product's growth genuinely calls for it — that path stays open either way.
Who actually owns a design system once it exists
A design system that ships without a clear owner tends to drift out of sync with the product within a few months — someone adds a one-off button style for a specific screen under deadline pressure, nobody updates the documented component to match, and within a year the “system” is more aspirational than actual. We assign a specific owner, usually a senior designer or a designer-developer pair, whose job includes reviewing proposed additions and keeping the documented components honest about what's actually in use across the product.
That ownership role also means saying no sometimes — turning down a one-off style that only serves a single screen in favor of extending an existing component, even when the one-off would be faster in the moment. It's a small, repeated discipline that's easy to skip under a deadline and expensive to unwind later, once five different one-off variations of what should have been the same button exist scattered across the product.
How we introduce a design system to an existing product
Retrofitting a design system onto a product that's already live is a different problem from building one alongside a new product from scratch, and it's the more common situation we actually encounter. We don't try to convert every existing screen at once — that's a multi-month project with no visible payoff until it's nearly done, which is a hard sell to a client watching the clock. Instead we extract components incrementally, starting with whichever pattern appears most often across the product, and apply the documented version forward on new work while leaving older screens alone until they're touched for some other reason.
That approach means the product looks inconsistent for a while — new screens using the system, old screens still using the previous ad hoc styling — but it keeps the investment proportional to value delivered at every stage, rather than asking a client to fund a large invisible refactor before seeing any benefit. Full consistency arrives gradually as the product evolves, which in our experience is a far more realistic path than a wholesale rebuild most teams can't actually justify budgeting for.
The underlying question is always the same regardless of project size: does this investment pay for itself in consistency and speed over the product's realistic lifespan, or is it solving a problem the project doesn't actually have yet. Answered honestly, that question does most of the work of deciding how much design system a given project actually needs.
