Primitives: Use the Experts
When starting a new application, you don't hand-roll your operating system or invent a new programming language. That effort is a distraction from what matters: your product's value. The same logic should apply to your UI's foundational components.
An accordion, tabs, or a combo box are not trivial to implement correctly, especially regarding accessibility. Mature libraries like ReachUI, MaterialUI, and Adobe's React Spectrum have been battle-tested. There are also paid, pre-built options like TailwindUI emerging, offering a strong middle ground between raw primitives and in-house work.
The Middle Ground: Business-Specific Abstractions
This doesn't mean you should never have a component library. Most companies should. However, building your own library for the sake of having a unique implementation of a standard component is rarely a good use of resources. It's often more about a fun technical challenge than business necessity. A button with thousands of lines of code is a symptom of over-engineering; mature, production-ready versions already exist.
Instead, your company's component library should consist of wrappers around those low-level, battle-tested primitives. The goal is to constrain the capabilities for your specific use cases to promote consistency across your codebase. If your entire application has only a few distinct button states, your wrapper should reflect that, not expose all the internal data-attribute logic of a fully-featured third-party button.
Focus your internal build effort on components that are compositions of several lower-level parts—the unique UI elements that actually represent your application's specific workflows. These are the widgets that benefit from internal investment.
Don't Let Ego Dictate the Build
It can be easy to feel like your use case is too unique for existing solutions. It often isn't. Resist the knee-jerk reaction to dislike an API because it's different from what you're used to. If a well-established library has a solid track record on accessibility and performance, working within its constraints is likely more sustainable than building your own from scratch.
The end-user isn't paying for your perfect abstraction of a divider component. Your team's time is precious. When considering a build vs. buy decision, ask if this is truly your core competency to develop and maintain, or if you can leverage existing expertise to deliver value faster and focus on what makes your product unique.
