When a design system is worth it, and when it's overkill

Everyone builds a design system now, whether or not they actually need one. It's become a default step, like setting up a Figma file or picking a font pairing — done early, done automatically, rarely questioned.

When it earns its keep

The case for one is real: a growing team, a product that spans multiple platforms, a release cadence fast enough that inconsistency compounds into real cost. If three designers are shipping screens in parallel and nobody agrees on what a button looks like, a system stops being a nice-to-have.

“A system isn't a nice-to-have — it's the thing preventing the product from visibly falling apart.”

When it’s premature

The case against it is just as real, and gets ignored more often. A single-product landing page. A team of one. A product that's still finding its shape, where the interface is going to change shape twice before it's right. Building tokens and a component library before you know what the product actually is isn't rigor, it's premature abstraction — you're systematizing guesses.

The framework I actually use is simpler than most system audits: will this component be reused by someone other than me, within the next three months? If yes, formalize it. If no, ship it inline and move on. Everything else is a bet on a future that may not arrive.

The best design systems I've worked with didn't start as a component library. They started as a shared file and a handful of naming conventions everyone actually followed. The library came later, once there was enough real, repeated usage to document — not before.