When a Component Library Is the Wrong Choice (and When It Isn't)

A team building a point-of-sale product recently wrote up why they moved to Radix UI paired with Tailwind. Their stated motivation wasn't performance or bundle size. It was that their product needed to look like their own brand, not "a component library's default theme with our logo pasted on top."

A concrete example: rebuilding a POS app's UI

That's a real, specific problem, and it's more common than teams often admit. A lot of B2B products end up visually interchangeable because they're all built on the same handful of component libraries with the same default spacing, the same default button shapes, and the same default color application patterns, just re-skinned with a different logo. For an internal tool, that's a non-issue. For a customer-facing product where the interface itself is part of what you're selling, it's a real cost.

What you actually get from headless primitives

The architecture the team landed on has three layers: Radix UI provides unstyled, accessible behavior (focus management, keyboard navigation, ARIA attributes) with no visual opinion at all; an internal layer of styled primitives applies the team's actual visual language on top of that behavior; and feature-specific components sit above both. The result is that theming, including dark mode, becomes a matter of swapping CSS variables in a single Tailwind config rather than maintaining two parallel theme objects.

The accessibility piece deserves particular attention, because it's easy to underrate. Building correct focus traps, keyboard navigation, and ARIA attributes from scratch is real, unglamorous engineering work that's easy to get subtly wrong. Getting that largely for free from a headless primitives library, while still controlling every pixel of the visual layer, is a genuine advantage, not just a nice-to-have.

The cost nobody mentions in the pitch

Here's the part that doesn't show up in most "why we chose X" write-ups: a full component library enforces consistency automatically, because the components are the constraint. Headless primitives don't do that. Consistency has to be maintained actively, through conventions, code review, and periodically going back to consolidate drift.

They found duplicate toast implementations coexisting in production, built by different people who didn't realize an equivalent already existed.

That's not a hypothetical risk, it's a real failure mode of this approach, and it doesn't go away with better intentions. It goes away with deliberate maintenance work someone has to actually own.

How to actually decide

The decision isn't about which approach is trendier or which one feels inherently safer. It's about what you're actually optimizing for.

If your product's interface is a competitive differentiator, and you have the discipline (or the headcount) to maintain visual consistency without a library enforcing it for you, headless primitives let you make the fiftieth screen look as intentional as the first, without fighting a library's opinions on every custom element.

If your product is internal tooling, an admin panel, or anything where the UI is infrastructure rather than a selling point, a full component library will get you to a consistent, accessible interface faster, with less ongoing maintenance burden, and that's usually the right trade to make. The mistake is picking either approach because it's trendy rather than because it matches what your product actually needs the interface to do.