Web Architecture

Component Library Decisions: Build, Buy, or Borrow

The choice between a custom component library, a headless system, or a full-stack UI kit shapes everything downstream. Here's the framework.

January 15, 20255 min read
componentsdesign systemsarchitecture

Every project above a certain complexity eventually asks the same question: where do the components come from?

The answer shapes velocity, design coherence, and long-term maintenance burden for the entire project. Getting it wrong early is expensive.

Three Models

1. Full-stack UI kit (Shadcn, Chakra, MUI)

Best for: teams that need to move fast and don't have a designer, or projects where design differentiation isn't important.

The catch: You're inheriting someone else's decisions. Customization is possible but often fights the grain of the library. And the bundle weight compounds.

Shadcn is interesting because it's a copy-paste model — you own the code — which removes the dependency problem while keeping the velocity benefit.

2. Headless + custom styling (Radix, Headless UI)

Best for: teams with design resources who want full visual control without rebuilding accessibility primitives.

Radix UI is the current standard. Unstyled components with full ARIA support, WAI-ARIA patterns baked in. You bring the CSS. The split is clean: Radix owns behavior, you own appearance.

3. Build from scratch

Best for: design-led teams building truly novel interfaces, or projects where the component footprint is small and specific.

The temptation to reach for this is almost always wrong. Accessible interactive components — comboboxes, dialogs, date pickers — are genuinely hard to build correctly. The edge cases in keyboard navigation and screen reader support alone take weeks to discover.

The Decision Framework

I apply two filters:

Filter 1: Is this interface primarily content or primarily interactive?

Content sites (portfolios, marketing, documentation) need minimal interactive complexity. Even the "build from scratch" option is reasonable here — you're talking about a few buttons, maybe a modal.

Application UIs (dashboards, editors, SaaS products) need a headless system at minimum. The interaction complexity is real.

Filter 2: What's the design constraint?

If you have a specific design system and brand, a full-stack kit creates friction. If you're starting from scratch with no designer, a full-stack kit is an accelerant.

What I Default To

For content-driven projects: bespoke, with Radix only where needed (modals, dialogs, dropdowns).

For application projects: Radix UI primitives + custom design tokens. The CSS custom property model makes theming clean, and you're not fighting the library when the design wants something different.

The goal is to own the decisions that matter and borrow the ones that don't.

Apply

If this maps to a problem you're working on.

I work with $1M–$20M ARR founders whose digital investment isn't producing the return it should. Applications reviewed personally within 48 hours.

2 Diagnostic slots / month · 2–3 full engagements / quarter · 48h review