Most teams think a design system is a Figma file and a component library. Those are artifacts of a design system, not the system itself. The actual system is the set of decisions — spacing scale, color logic, motion rules, when to use which pattern — that let a product stay coherent as more people, on more teams, touch more of it.
The failure mode we see most often isn't a missing component library. It's components that exist but whose underlying decisions were never written down, so every new contributor reinvents the reasoning from scratch, and the system drifts a little with every addition.
What we build for clients instead is a small set of primitives with explicit rules attached — not just what the button looks like, but when you'd reach for a button versus a text link versus a magnetized CTA, and why. The components matter less than the rules that generated them, because rules generalize to cases nobody designed for yet.
The test of a good design system isn't whether it looks polished in the file. It's whether a new engineer, six months from now, can build a screen nobody has designed yet and have it feel like it belongs.