Custom component libraries vs. off-the-shelf solutions: which one is better?
Hot on the heels of rebranding the Gun.io website, I have a newfound appreciation for the amount of work it takes to create custom componentry for a product. That being said, it’s also easy to understand how it might not be the best choice for everyone.
The biggest advantage to using an off-the-shelf component library is convenience. Without asking for it, every button, headline, and form is accounted for, you just need to pick one and add it to the screen. The biggest advantage of a custom library is no doubt the tailored, branded experience only you can offer.
Off-the-shelf: less upfront work, less flexibility
Pre-built solutions come with a library of ready-made components which help you to quickly build and scale your product’s UI. This is especially helpful if you’re trying to develop an MVP or test project. Generally, all of the included components have been designed to meet accessibility standards and will give your product a finished look. You can tailor the components to fit your ensign scheme by adding styling and markup, rather than starting from scratch with a whole build.
On the other hand, the customization has its limits. Regardless of the number of component libraries that exist, only a few of them get used in heavy rotation. This means your site may have the look and feel of a competitor, no matter how much radius curve you add to your CTA buttons.
Custom components: tailored, but time intensive
With a custom component library, you will build (or have someone else build) components tailored to your product and brand needs. There are two main benefits to this, beyond just having tailored components: you have complete control over the UI experience, and you don’t have to load dozens of components that you will never use. You get to decide how each component functions and interacts with the rest of your product, and deliver a look and feel that is truly unique.
The downside of this is that it takes a substantial amount of time and resources to plan, design, build, and maintain a custom library. In practical terms, you have to have an idea of how every user flow in your product works before you can design the components that power those interactions. And once you’re done with the first iteration, there are bound to be future use cases for which you will need to have a new component built, since those components don’t already exist in a library.
Key considerations for “to buy or to build”
Core needs
The very first question to ask is: does an off-the-shelf solution support all the basic requirements my project needs? How much customization do you really need beyond the basic componentry?
Time constraints
What is the timeline your project is working against? Do you have the time to design and build a library, or are you in a crunch and needing to get something out of the door sooner rather than later?
Cost and effort
Do you have the resources to dedicate to building out a library, or could your team’s time be better spent on other areas of development if the components were already in place?
Ongoing support
Will you need help with updating the library, resolving issues, and maintaining best practices? This usually comes baked in with an existing library, but needs to be added to the cost and effort category if you’re going the custom route.
Visual differentiators
When it comes to your product, how important is the UI? Will a standard UI hold you back from creating a memorable experience with your product?
Options and compromises
There is no one right way to go here, it will genuinely depend on what your team and product are best suited for. There are a few ways you can combine the two approaches, if you want the custom look and feel with the ease-of-use that comes with something pre-built:
- Buy and off-the-shelf library and customize certain components
- Build a barebones version of a custom library and grow it over time
- Pair a packaged set of core components with custom peripheral ones
- Use pre-built components as the foundation for your customized library
Wrapping up
The major considerations when deciding which route to go are going to be the amount of resources you can dedicate to the library, the timeline in which you need to integrate the components into the product, and how flexible you can be within the constraints of either library type. In the end, the middle ground will likely be somewhere between the two, combining in-house design with off-the-shelf convenience.
Want to add someone to your team with the know-how to build a great component library?
