8 Key Factors When Deciding Between Building In-House and Buying a UI Component Library

Whether your goal is to meet a web project's deadline or to standardize your development on a single UI library, you'll likely face the decision whether to build your UI internally or to buy a ready-made library of UI components. A lot can depend on this decision, so make sure you consider these eight key factors.

When should you invest in buying a third-party UI library? There isn’t a universal answer to this question, but there certainly are situations in which you would get huge value in return, likely a multiple of the license cost. This article will go over some of the main considerations to keep in mind when evaluating the alternatives for building user interfaces - building in-house, choosing an open source solution or opting for a commercial UI library.

We will consider eight factors, but first, I’ll give you a bit of background so you have some context.

• Deciding Between Shortlisted Options
• 1) Documentation and Learning Resources
• 6) Special Features: A11y, I18n, L10n
• 7) Cost, Licensing and Return on Investment
• 8) The Pleasure Factor

While this article will useKendoReact, a commercial React UI library, to illustrate some of the points, the criteria discussed here can be applied for evaluating any JavaScript UI library.

Quick note before we dive in – for the purpose of this article, what we refer to as “UI library” or “third-party library” is a toolkit of prebuilt, customizable and extendable UI components that developers can implement into their apps. UI libraries might also include additional tooling such as theme builders, design guidelines and sample applications.

How Did We Get Here

Let’s start with why: what is the reason you are looking at UI solutions? Typically, developers reach this point when they are pressed for time  to finish an application or, in a less stressful scenario, are aware they can save time by not building everything from scratch and are exploring options to increase their productivity.

A popular scenario is the need to standardize on a UI library , for example when a team is starting to work on a complex application and know they will need multiple UI components. Adopting a complete library in this situation reduces decision-making time from having to discover, learn how to use and customize multiple different solutions.

Other times, you may be looking to a solution for a difficult problem : adding a data grid, applying styling to multiple components, or achieving accessibility compliance.

When it comes to addressing any of these needs, whether you have a deadline to meet, or your main concern is to streamline your UI development, your options are:

• Build your UI internally 
• Find an open-source software (OSS) solution
• Buy a commercial library

Often, you’d adopt a mixed approach as each of these options has its pros and cons. To make an informed decision, then, make sure you consider what each of the individual options entails, and how it would affect your team and you in the short and long term.

As marketing manager for KendoReact, I’ve spent countless hours looking to answer this precise question – when does a developer or a company need a professional UI library? When is there a better alternative for them? You might expect me to say that everyone needs a professional UI library, but that would be naïve – and it’s simply not true. Come along with me on a journey exploring these questions based on the research my team and I have done!

I’ve summarized the main criteria that influence the question every developer faces at a certain point, even in the JavaScript world. This question, in simplest terms is: Should I build something myself or should I buy an off-the-shelf solution?

Your App in Context

It can be helpful to look at the big picture at the start. Your JavaScript project is built within your organization, which can be small or large, within your team, which likely consists of engineers at different experience levels, and for a certain client, internal or external. There may be other important elements for you to consider regarding your app’s context, for example, whether the industry you’re serving is highly regulated. All these factors have a bearing on the solution you will choose.

Here are some contexts that can play a large role in determining the UI solution you choose:

Company Size

In large companies, there often are other teams building UI for other apps. Are these teams already using a UI library? Are they looking for one to standardize on? Adopting the same tool across teams has multiple benefits, from knowledge sharing to an “automatically” consistent UI & User Experience (UX) across your organization. Achieving a consistent look and feel using different tooling can be challenging.

Team Experience

Are the different people on your team equally experienced? Do they have experience building their own UI components? How long would it take them to build a date picker, a chart or a form? If the team is just starting to use a framework or language, it may be helpful to standardize on common productivity tools to act as “equalizers” and reduce the amount of undocumented code your more experienced team members will have to review. Other factors may be at play, too – for example, what tools have you used before? If you can find a solution that serves your needs and is familiar to most of your team, you will shorten implementation time.

Additionally, with any specialized work, there’s a knack to building reusable UI components – well, there’s a knack to building usable UI components in the first place. Previous experience in building UI components builds a knowledge base and expertise that helps to avoid roadblocks and quickly troubleshoot common issues. There’s nothing to stop your team from acquiring this know-how, but consider whether you will benefit from investing this time and effort or whether you will be reinventing the wheel.

Who’s the Client

Is your client an internal team that has little to no UI requirements and is just looking for raw, simple functionality? Or is the technical specification of your app the size of a novel? The first scenario requires a much simpler solution, where in the second one, you can also anticipate multiple change requests that will beg for a solution that’s modular by design. Additionally, isaccessibilitya must for your end-user?  This would require familiarizing yourself with the respective accessibility guidelines and deciding on how to apply them in practice – not a straightforward process in most cases.

Project Lifespan

Does your project have a clear start and end date or is it a long-term initiative? Will you have to maintain it or once you’re done, you’re done? If it’s a one-off project, it may be worthwhile implementing ready-made UI components instead of taking the time to code something that’s already been built by someone else - and something that you will never need to use again.

At the same time for long-term projects, or if you regularly begin new React apps, and you don’t have full visibility on all the UI components and features you will have to implement in the future, you may be well served by a comprehensive solution that can be applied to multiple scenarios.

Maintaining multiple dependencies and undocumented code is a phrase that in and of itself sends shudders down the spine of most developers. This applies to any part of your project, including building the UI. Other than the mere unpleasantness of the task, code maintenance can come to occupy unanticipated swaths of time. Additionally, we’ve all encountered projects that cannot be updated to the latest version of the framework because of an outdated, but crucial, dependency.

The risks associated with long-term maintenance may be smaller if you go bigger – that is, if you go with an established company that has a roadmap for the foreseeable future and regularly releases updates.

But Wait, There’s More

Take some time to consider what other factors surrounding your application may be relevant to you. Perhaps your manager’s preferences, the economic outlook or a future merger or acquisition will play an important role in your choice of solution. Whatever it is, it’s worth considering before committing to a path forward rather than being surprised after.

8 Factors to Consider When Deciding

Taking your app’s context into account, you’ve compiled a shortlist of possible solutions for your app’s UI/UX. If the decision was simple or straightforward, you wouldn’t be reading this blog, so it’s likely that in your shortlist there’s a mix of alternatives – some commercial, other open-source or based on open-source software (OSS). All of them meet your requirements, as of today. What else should you consider in making a choice?

A note before we continue: I assume you are very familiar with the benefits of building your solution in-house, so I will focus less on this approach.

1. Documentation and Learning Resources

Let’s start simple. Even a button can be hard to implement if you don’t have technical documentation. Documentation will not only help you implement your solution, but if well-written and regularly updated, will help shorten development and maintenance time. For more complex solutions, having additional learning resources such as articles, videos or even an active Q&A forum (be it Stack Overflow or a product-specific forum) can be of immense help and utility. That’s why when calculating the internal dev/hour cost of your application, it can be a good idea to include additional dev hours in your estimate for documenting the code – unless you’re certain the developer(s) writing that code will remain in your company forever.

On the other hand, with third-party libraries, whether paid or OSS, you can expect some level of documentation and learning resources as part of the package. However, paid solutions have more at stake if developers cannot quickly learn how to use them, so the commitment to documentation by companies offering commercial solutions is usually quite high.

2. Support

Sometimes docs and blogs just won’t cut it and you need to go straight to the source with your question. What options do you have to get technical support regarding your solutions of choice? If it’s your internal team building most of the solution, you’re mostly on your own with troubleshooting and debugging. The plus here is that you have a team dedicated to moving your project forward and answering all questions.

With a paid solution, the situation is similar, except that you’re “hiring” an external team to handle support tickets so your own team can focus on meeting that deadline. Paid solutions are quite cost-efficient in this way – for example, KendoReact licenses include technical support, and the people answering your tickets are the developers on the KendoReact engineering team themselves, so you are sure to get a timely, guaranteed and very qualified response. We all have our share of comically terrible stories of contacting customer support, and it’s true that different companies handle it with a different degree of success. I can speak for my team only, and our dashboard shows that the satisfaction rate with the KendoReact technical support is consistently at 93% or higher. If support is important to you, make sure you test it before you make your choice.

The situation with technical support when using open-source solutions is heterogeneous. If the library you’re looking at has a big community using it, you get the benefit of many other developers contributing and collaborating. This may lead to your questions being answered very fast - or not at all, if no one else is interested in the solution you are looking for. It’s always worth looking at the main contributors of the library you’re evaluating. That's one way to find out if it’s truly cared for by a large community effort or it depends on the work of a handful of developers.

3. Dependencies

It’s important to consider what dependencies are you adding to your project with the solution you choose. If you go the OSS way, based on the number of components and features you need to implement, this number can become quite high. This increases the complexity of your solution, and you may have to deal with conflicts between libraries, or handling situation such as libraries that stop being maintained. A tricky moment here is that you may not even know a library is a dependency for you, as it may be a second- or third-level dependency of one of the tools in your stack.

The trade-off with a paid UI library is that you add a single dependency (or in any case, fewer), so the level of complexity you’re buying into is much smaller. However, you have a single point of failure. This sounds scarier than it often is, though, considering that many paid solutions are provided by large companies with a long track record of being in business, and successfully so. For example, KendoReact is part of the Progress portfolio of developer tools, some of which were launched almost 20 years ago.

4. Updates

On a related note, if your app will be in use for more than a season, consider what you’ll need to do when the next framework or browser version arrives – and if not the next one, the one after that. What will you have to do to make your code compatible in each of the shortlisted options you’re evaluating? Outsourcing new version support to an “external team” – be it by using a well-maintained open-source or paid solution – can enable you to be using the latest technology as soon as it’s released, without constantly having to reallocate people to this task.

5. Reusability

If this won’t be the last React app you are building, how much of the code will you be able to reuse in future projects? Building internally with reusability in mind increases the stakes on how well-documented your library will be. Most open-source and all paid UI libraries score high on this criterion as they are built to serve the many.

6. Special Features: A11y, I18n, L10n

Your app may need one or more of these features now, or it may be added as a requirement later: accessibility, internationalization, localization. While they are different, what’s common is they would need to be supported by all applicable components in your app. Would these features come out-of-the-box (or from the start, in case of building internally) or will such a requirement mean having to go on another solution hunt?

I’d like to pay special attention to accessibility. The importance of making the web accessible for all cannot be overstated, and governments are increasingly taking measures toward achieving this. To help developers understand the fundamentals of accessibility, we wrote several blogs on the topic. I recommend you start with the Accessibility Guidebook for Web Development .

7. Cost, Licensing and Return on Investment (ROI)

Тhe bottom line. The ROI. The price tag. Whether the money comes out of your pocket or your budget or not, you’re probably at least curious, if not keenly interested, in what each solution will cost you.

When Building In-House

Perhaps the hardest to measure is the cost of deciding to develop internally. It starts simply enough with your developer/hour cost multiplied by the project time estimate. We have mentioned earlier in this article a few additional tasks that you may have to include in your estimate. This includes, but is not limited to, writing documentation, support for new frameworks and browsers, bug fixing and maintenance.

An interesting scenario we’ve seen happen more than once is when other teams in your organization like what you’ve done and want to adopt your internally built UI library. This comes with its own pros and cons. On the plus side, your work’s utility increases, and the costs are spread across more projects, effectively increasing your ROI. Plus, it’s a great feeling to see your work being of use, I can vouch for that. The reverse side is that your team and you may inadvertently (or not) become the internal UI team, having to respond to everyone’s demands.

When Choosing OSS

Open source is often free, and you can find excellent tools out there. Putting together the skill and enthusiasm of an entire community can lead to creating powerful, rich software that solves problems creatively. It’s definitely worth looking for OSS that matches what you need – or to inspire your own problem-solving. Free – of price tag – however, doesn’t mean there isn’t an associated cost to going with a free option. You can look for it in the incrementally growing amount of time dedicated to maintenance, debugging and building missing features.

When Choosing a Commercial UI Component Library

Commercial UI libraries usually operate on a per-developer license basis and potentially a form of subscription that gives access to technical support and the latest features. If your team will be implementing the library, you can add to the cost of the implementation time for your team or you. It’s worth noting here that the difference in implementation time between building a component internally and buying a third-party one gets drastically bigger for more complex components, in favor of the ready-made tools.

To put this statement in context, consider that a single, perpetual and royalty-free license for KendoReact with Priority Support comes at $999, for all 70+ components. For this price, you get to use this version of KendoReact indefinitely and in unlimited projects. You have the option to renew your subscription in a year to get the latest version and continue your support privileges, with a big discount for early renewal. Now consider: What part of your app’s UI you or your team would build if you paid them $999… for the whole year .

For an interesting discussion of the economics of open-source software and ways to compensate the developers behind the tools we use for free on a daily basis, and get great utility out of, check out TJ VanToll’s article, Can We Make Open Source More Sustainable?

8. The Pleasure Factor

Finally, one topic that’s slightly fuzzier than those above – but a nice kind fuzzy: Especially if you’re choosing a library to standardize on, the solution you choose will be there for you to live with daily, for the duration of your project, and beyond. Are you going to enjoy working with this solution? Will the company/people behind it make your work easier or harder? What is the chance of pleasant and not so pleasant surprises? In short, will it be a pleasure to work with this vendor or creator? That’s hard to measure, but you can revisit your points of contact with this company and think about what your experience with them has been so far.

Conclusion

Deciding whether to build your UI in-house or implement an external solution can be a long and complicated process. More so if you are looking for a toolkit to standardize your development on and use throughout your current project and even in future ones. Considering the impact this decision will have on the quality of your application and possibly on your team’s motivation, it’s worth taking some time to go over the pros and cons of each option on your shortlist.

It’s interesting to note some of the themes that kept emerging in the criteria we’ve listed above:

• What risks are you comfortable with? Each solution comes with its own types of uncertainty. Consider also what ways to mitigate those risks are offered or available with each option.
• What kind of work do you want your team to focus on? Are feature implementation, maintenance and bug fixing things you find important for you or your team to do yourselves?
• How long will the outcome of my decision stay with me? In other words, will I have to maintain this app/develop this project for a long time?
• What do I want to optimize for? This is a somewhat reflective question because developers sometimes optimize for protecting the work that interests them the most over going for the most efficient solution or what’s best for the business. If you decide to keep the “sweet” work for yourself, that’s fine, of course – but it’s helpful to make this as a conscious choice.

My Take, or “The Pitch”

I know you’re been waiting for me to go here. I’d hate to disappoint.

Tell me this: Is building UI part of your company’s core business or core competence? If not, and you’re building business apps with complex UI, I’d argue that choosing a paid library is one of the most worthwhile investments you can make. It can not only save you money, but also a lot of valuable engineering time. And stress. And unpleasant work.

We literally had a client who told us in his support ticket that he couldn’t sleep because of a problem he was having with his UI. Once he received the solution from my teammate Stefan, he wrote back that his sleep returned to normal. So if the app you’re building is based on React, make use of the KendoReact free 30-day trial (giving you access to our technical support) and check out whether it can solve your problem and meet your criteria. It might just be the solution that will help you sleep better.