Component libraries vs. building your own
·2 min read ·Frontend · Architecture · Design Systems
Every frontend project eventually faces this decision: use an existing component library or build your own. Both choices have real costs. Neither is universally correct.
The Case for Third-Party Libraries
Ant Design, Material-UI, Radix UI—these libraries represent thousands of hours of accessibility work, browser compatibility testing, and edge case handling. A properly built modal handles focus trapping, keyboard navigation, screen reader announcements, and scroll locking. Getting all of that right yourself is not trivial.
For internal tools where you're moving fast and polish is less important than functionality, a comprehensive library is often the right call.
The Hidden Costs
Bundle size. Ant Design fully imported adds significant kilobytes to your bundle. Tree-shaking helps but doesn't eliminate this.
Design constraints. Every component library makes design decisions. Overriding them with CSS specificity battles is one of the most frustrating experiences in frontend development.
Upgrade pain. Breaking changes between major versions can require significant migration work across your entire codebase.
Dependency risk. What happens when the library stops being maintained? You're either stuck on an old version or you do a big migration anyway.
The Case for Building
For consumer products where design is a differentiator, building a small, focused design system often makes more sense. You control everything. No override fights. No bundle bloat from components you don't use.
The trick is scope. Don't build a complete component library. Build the 10-15 components your product actually needs, built exactly the way your design requires.
The Practical Middle Ground
Use a headless library—Radix UI, Headless UI—for the accessibility-hard parts (dropdowns, dialogs, tooltips), and add your own styles on top. You get the accessibility work for free and full visual control.