Component libraries: buy, build, or borrow

Every project's frontend needs a foundation of reusable UI components, and there are genuinely three viable paths to get there: buy a commercial component library, build entirely custom components, or borrow from a solid open-source library and customize it. Each is the right answer for different project constraints, and defaulting to the same choice on every project regardless of context is a mistake we try not to make.

Commercial component libraries and UI kits get you to a professionally designed, accessible baseline fastest, which suits internal tools, admin dashboards, and MVPs where visual distinctiveness matters far less than speed and reliability. The trade-off is a look that can feel generic or recognizably "off the shelf" to a design-conscious audience, and less flexibility when a genuinely custom interaction pattern is needed.

Fully custom components give complete control over visual identity and interaction design, which matters most for consumer-facing products where the interface itself is part of the brand differentiation. It's also the slowest and most expensive path, since every component, including the boring, unglamorous ones like form validation states and loading skeletons, needs to be designed and built from scratch.

Starting from a solid open-source library (unstyled or lightly styled component primitives) and applying full custom visual design on top gives most of custom design's visual control while skipping the significant, unglamorous engineering work of building accessible, robust component behavior (focus management, keyboard navigation, ARIA attributes) from scratch. This is our default recommendation for most client marketing sites and products.

Properly accessible component behavior, correct focus trapping in a modal, correct keyboard navigation in a dropdown, correct screen reader announcements, is genuinely hard to get right from scratch and easy to get subtly wrong in ways that don't show up in casual visual QA. Mature open-source component primitives have usually already solved these problems through years of real-world usage and bug fixes we'd otherwise be re-discovering ourselves.

We weigh timeline, budget, and how central the interface itself is to the brand's differentiation. An internal tool leans toward buying. A funded consumer product where the interface is a competitive advantage leans toward building custom. Most client marketing sites and standard products land in the middle: borrowed primitives, fully custom visual design layered on top.

Whichever path a project takes, the ongoing maintenance burden differs meaningfully and is worth weighing alongside the upfront build cost: a commercial library gets updates and bug fixes from its vendor with minimal ongoing effort, a borrowed open-source foundation needs periodic dependency updates and occasional breaking-change migrations, and a fully custom component library requires the team to maintain and extend everything itself indefinitely, including fixing bugs that a mature open-source project would likely have already caught and resolved for free. We factor this multi-year maintenance cost into the initial recommendation, not just the launch-day build estimate, since a cheaper-looking custom build can end up costing more over several years of ongoing upkeep.

These three paths aren't mutually exclusive within one project: it's common, and often the right call, to borrow open-source primitives for complex, accessibility-sensitive components like date pickers and multi-select dropdowns while building simpler, more visually distinctive elements like buttons and cards fully custom. We make this decision component by component rather than picking a single approach for the entire project, since the right trade-off genuinely differs depending on how complex the underlying interaction is and how much visual distinctiveness actually matters for that specific piece.

Commercial component libraries vary meaningfully in licensing terms, some charge per developer seat, some restrict redistribution or require attribution, and some have separate, more expensive tiers for commercial versus personal use, and open-source libraries carry their own range of license types with different implications for commercial products. We check licensing terms explicitly as part of any buy-or-borrow recommendation, since discovering a licensing conflict, a per-seat cost that scales awkwardly with a growing team, or a copyleft license incompatible with a client's proprietary codebase, after a library is already deeply integrated is a far more expensive problem to unwind than checking the license terms for ten minutes before adopting it.

Everything above assumes a single product's component needs, but the calculation shifts for a client building a shared design system meant to serve multiple products or teams over time, where the upfront investment in custom-built components amortizes across many future uses rather than a single project. In that scenario, we lean more toward custom building even when a comparable single-project decision would favor borrowing, since the extra initial cost of full ownership and control pays off differently once it's serving several products rather than justifying itself against a single project's budget and timeline alone.

It's not unusual for a project that started with a bought or borrowed component library to eventually migrate toward more custom-built components as the product matures and its specific design needs diverge further from what a general-purpose library was designed to support. We plan for this possibility from the start where possible, favoring foundations that allow incremental component-by-component replacement over a monolithic library that would require an all-or-nothing swap later, since a foundation that supports gradual migration lets a growing product evolve its component strategy over time without ever needing the disruptive, all-at-once rebuild that a more rigid initial choice would eventually force.

Beyond timeline, budget, and brand differentiation, we ask one more direct question before finalizing a recommendation: who on the team will actually be maintaining this in a year, and what's their comfort level with the option under consideration? A technically ideal choice that the team maintaining it afterward isn't equipped to support well tends to underperform a slightly less ideal option the team can genuinely own going forward.