Why your design system keeps stalling
If you are on your second or third attempt at a design system, you are not alone. Design systems stall for organizational reasons far more often than technical ones, and the technical fixes never address the real problem.
The three failure modes
The library that nobody adopts. Built by a platform team in isolation, shipped as a polished package, and then ignored because the surrounding product code already works and rewriting it has no business justification.
The library that everybody bends. Adopted enthusiastically, then forked component-by-component by product teams under deadline pressure. Six months later it is a folder of unmaintained primitives.
The library that ships great primitives nobody can compose. Buttons, inputs, and tokens are beautiful. The page-level patterns — forms, tables, empty states — are absent, so every team rebuilds them differently anyway.
What actually works
The successful design systems we have helped ship share three properties.
First, they are introduced alongside a real product project, not as a standalone initiative. The first consumer is also the first contributor.
Second, they ship at the right altitude. Tokens and primitives matter, but the system has to ship enough page-level patterns that a product engineer can build a feature without leaving the system. That usually means ten to twenty composite patterns at launch, not two hundred low-level primitives.
Third, governance is light and explicit. A single tech lead owns merges. Contributions are encouraged but reviewed against a written rubric. There is a documented escape hatch for product teams that genuinely need to deviate, and the escape hatch is audited monthly so it does not become the default.
The cost question
Design systems are easy to under-resource. Treat the team that owns yours as a permanent platform team, sized to roughly one engineer per ten product engineers it serves. Less than that and the system will lag the product; more and it will out-build its consumers and lose touch with their needs.
Get those three things right and the technical choices — React, Web Components, Tailwind, CSS-in-JS — become the easy part.