Parita Parmar
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.
