Why I stopped using design systems I didn't build

There’s a particular kind of friction that comes from inheriting a system you didn’t make decisions for. It looks clean on the surface, but every edge case reveals assumptions you weren’t part of.

I’ve worked with Material Design, Ant Design, and a handful of internal systems that came pre-loaded with opinions. The experience is always the same: fast at first, then increasingly slow as the real product requirements diverge from what the system was designed for.

The hidden cost of borrowed decisions

Every design system is a set of frozen decisions. When those decisions were made by someone else, you’re not just using components — you’re inheriting their constraints, their tradeoffs, their mental model of what a good interface looks like.

This isn’t inherently bad. Sometimes those constraints are exactly what you need. But when you’re building something with a specific character, a specific user, a specific set of contexts, the borrowed system starts to feel like a rented apartment — livable, but not yours.

What I do instead

I build small. A set of tokens (colour, spacing, typography), a handful of base components, clear naming conventions. This takes maybe a day to set up properly, and from that point forward every decision I make is one I understand.

The components are fewer, simpler, and more deliberately chosen. When something breaks or needs to change, I know exactly why it is the way it is — because I made that call.

The caveat

This doesn’t scale the same way. On a large team, a shared system is a coordination tool as much as a design tool. But for solo work or small teams moving fast, the overhead of learning someone else’s system often outweighs the time saved.

The better framing, maybe, is: use a system when you can adopt its opinions wholesale. Build your own when the product has opinions that conflict.