Why I Stopped Reaching for Component Libraries First

I used to install a component library at the start of every project. Bootstrap, then Material UI, then Ant Design, then whatever was popular that month. It felt like the responsible thing — why build what already exists?

I stopped doing that. Not entirely, and not dogmatically — but my default changed. Here is why.

The deferred cost

Component libraries are not free. The cost is deferred — and it usually comes due at the worst time.

The immediate benefit is real. You get a button, a modal, a table, a date picker, all working on day one. You save days of initial implementation. The project starts fast.

The cost appears three weeks later, when the client asks for a button variant the library doesn't have, or when you need the dropdown to behave slightly differently, or when you're fighting the library's styling system to match a specific design. Now you're not using the library — you're working around it. Every customization is a negotiation between what you need and what the library allows.

The further you get from the library's defaults, the more you're paying in friction for the initial investment.

What "close enough" costs you

Design systems have opinions. Material UI has Google's opinions. Ant Design has Alibaba's opinions. Those opinions are baked into spacing, color treatment, interaction patterns, animation curves.

If your product needs to feel like your product, "close enough to Material" is not a neutral choice — it's a constraint. Users who've used Google's products will bring expectations. The seams will show.

For internal tools and admin dashboards where brand doesn't matter, this is fine. For anything customer-facing where the experience is part of the product, it's worth asking what you're giving up.

What I do instead

I maintain a small set of primitives I've built over time — a button, an input, a modal shell, a select. Unstyled or minimally styled, typed with TypeScript, tested. They do exactly what I need and nothing else.

For new projects, I start from those. I add what the project needs. I don't start with a library's full component set and try to constrain it down.

This takes more time upfront. Significantly more, on the first project where you're building the primitives from scratch. After that, you're amortizing. The fifth project is faster than it would have been with a library, because the primitives are already right.

When libraries are the right call

Projects where the team is small, the timeline is short, and the design is secondary to the function: internal tools, quick prototypes, admin interfaces. Libraries earn their keep here. The tradeoffs land in your favour.

Projects for a design-forward product with a specific brand identity, a custom design system, or high interaction requirements: build the pieces you need. The library will work against you before you're done.

The question I ask now: is the cost of the library's opinions lower than the cost of building without it? Most of the time in client-facing product work, the answer is no.