The component library trap: when design systems slow you down

Every growing team eventually adopts a component library, and for the first year it's unambiguously a win: consistent UI, faster builds, fewer one-off decisions. The trap appears later, when the library has grown enough variants and props that understanding an existing component takes longer than writing a new one from scratch.

The tell is a specific kind of Slack message: someone asking "does a component for this already exist" and getting three different, slightly wrong answers. At that point the system has stopped being a shared vocabulary and started being an archaeology project.

The fix isn't abandoning the system, it's pruning it on a schedule: treating unused component variants like dead code, deleting rather than accumulating, and keeping the library smaller and more opinionated than feels comfortable. A design system with forty button variants isn't more flexible than one with four; it's just less used correctly.

The goal was never to have every possible option available. It was to make the right option obvious. Past a certain size, more options is the opposite of that goal.