If your company is frequently building software projects, you will run across the ever-present “build vs. buy” decision time and again. Should you create a feature yourself or use a third-party tool that accomplishes the same goal without investing your own time and resources?

Let’s say you need to alert your sysadmin when errors occur in your application: Is it better to build a custom logging framework that’s specific to your organization, or should you use error-tracking software like Sentry?

The answer in almost all cases is that it depends. If there’s truly a unique functionality that you can’t get with any of the off-the-shelf solutions, then it may make sense to build it yourself. However, you might not be willing to take on the build, maintenance, and support costs of running yet another piece of software, especially one that’s not core to the application you’re building. In that case, getting the job done with a third-party tool will probably suit you better.

This article explores some of the factors that are important in the buy vs. build decision. It also walks through the example of making this decision for data grid components.

Buying a custom solution: Pros

When it comes to finding a solution for a particular need, the option of purchasing a pre-build component is often recommended.

✅ Saves developer time

Because you can integrate this component into your codebase straightaway, your developers save time and can get back to working on the core logic that powers your application or service. You can focus on letting the maintainers of the component handle the complexities of that particular piece of your application. At the same time, your organization’s developers can continue to work on the types of problems they solve best.

✅ Low maintenance costs

With a component that you buy, the maintenance cost is low (if any at all) simply because you’re not the one responsible for keeping the code up to scratch. The maintenance cost that you pay is the monthly/yearly fee to license the component while the developers in charge take care of the rest. Because of this, buying components instead of building them can make parts of the development process easier to budget for, with fixed instead of variable costs, which is always a plus.

Buying a component means that you don’t have to shoulder its non-recurring engineering cost yourself, i.e., the once-off cost of researching, designing, developing, and testing a product. Although it’s built into the license fee, you’re only covering a fraction of it.

✅ Accelerated product development

Employing pre-built software components can drastically hasten the product development process, enabling your product to reach the market in a shorter amount of time. This can provide a decisive edge when it comes to meeting demanding deadlines or launching a new product or feature ahead of competitors.

✅ Better quality

Commercially available components are usually developed by experienced specialists who have spent time optimizing and testing their code. As a result, these components are generally of higher quality than those developed in-house.

✅ Improved support

With a ready-made solution, you usually get access to support from the vendor. This can be invaluable if you encounter problems with the component, as you can get assistance from experienced support teams. By contrast, if you build your own components, you’re responsible for providing support to yourself, which can be time-consuming and costly.

✅ Access to specialized expertise

When you buy pre-built software components, you also gain access to the vendor’s expertise. This can be particularly beneficial if you need to use specialized components that require specific technical knowledge. By buying components from a vendor specializing in that area, you can take advantage of their expertise and avoid developing it internally.

Buying components can also have a few downsides that are important to watch out for when you’re considering going down this path.

Buying a custom solution: Cons

❎ Limited control over the direction of development

If you choose to buy a component rather than build it, you have little to no control over the direction of development because it’s not your product.

This is why it’s important to look at the customization options that already exist within the product you’re considering buying. Products with more customization options, like Handsontable, are more likely to be a good fit for your organization, even if your needs change or evolve. You want to make sure you can use the product to fit your use case, no matter which direction development on the product itself takes.

❎ Potentially timely bug fixes

If you encounter a bug with the implementation, it’s impossible to know whether a fix will be prioritized or what the timeline to address the issue will look like. It’s similar to the drawback of not controlling the direction of development. It’s likely that your bug will go into the queue with all the other feature requests, improvements, and bug fixes that the dev team is working on, and that can make it difficult to estimate when you could expect a fix.

Building your own component: Pros

If none of the benefits of buying a component are jumping out as must-haves for your organization, there are some cases where it makes more sense to custom-build something that fits your needs.

✅ Ownership of the code

If it’s truly imperative that you own the code for a particular component, there’s no better way to achieve this than by building it yourself. If you build it, you own it.

While some third-party solutions allow you to self-host their solution, in the end, the only true way for you to have ownership over a particular component is to create it in-house. Even if you self-host, you’ll still have difficulty customizing and adding integrations to the application and potentially have to reapply your changes after each update; when you own the code, that’s no longer an issue.

✅ Ability to add unique features

Most third-party solutions aren’t really extensible by the end user, meaning if you want to add features that are specific to you, you’ll have to submit a support ticket or chat with your vendor’s team. Even then, if the feature you’re looking to add really is specific to your organization, the likelihood that the vendor is planning on building it is low. It means that you will either have to build an in-house solution anyway or look for a different vendor that offers that feature.

As you’ve seen, there are certainly benefits to building your own solution, but we shouldn’t underestimate the drawbacks that need to be carefully considered.

Building your own component: Cons

❎ Time to market

Building software components in-house can take a long time, delaying the launch of new products or services. This delay can be especially costly in highly competitive markets where speed to market is critical.

❎ Ongoing developer and maintenance costs

While building your own solution might be viewed as a way to save on the cost of licensing other software, there can be a significant cost to making sure all the necessary updates are performed, and code is kept secure, performant, and just generally in good working order.

Depending on how complex the component is and how many developers are required to maintain it, these resources are directly weighed against the financial investment of licensing a similar component or service.

In addition to the direct financial cost of paying developers to maintain your custom-built component, it also takes them away from working on code that’s more core to your application.

❎ Risk of failure

There’s always a risk that your custom software component won’t work as expected or that it will fail altogether. This can be a significant setback for your project and could result in lost time, money, and resources.

❎ Lack of expertise

Not all organizations have the expertise required to develop complex components. It may be more efficient and effective to outsource the development to a vendor who specializes in that particular area. If your team lacks the necessary expertise, it can lead to poor-quality code, security vulnerabilities, and other issues that could negatively impact your project.

Now that you’ve learned more about the various factors that are part of a buy vs. build decision, let’s look at a specific example by trying to evaluate whether you should buy or build a data grid component.

Buying vs building your data grid component

If your application deals with data, especially data that a user can input, you might run across the need to build a data grid component.

Sometimes referred to as a spreadsheet, a data grid is a component of your application that can display data in rows and columns, sometimes enabling this data to be generated by or related to other pieces of data in the grid through the use of formulas.

Below is an example of the Handsontable data grid in action.

The basic version of this component may seem relatively simple and easily accomplished by adding some interactive functionality to an HTML <table> element. However, there are a few cases you’ll need to consider that might take much longer to build than you’d expect.

• Individually selecting a couple of rows: When you want to select more than one row of data, especially if you’re copying and pasting this data into or from another application, the order and formatting of the data have to be maintained so that the data can be moved seamlessly. Supporting all the various data types and possible permutations of formatting and how the data was entered is a challenge you’ll quickly run into when trying to build your own solution.
• Performance: It is crucial to keep a web application performant, especially when it’s a data grid that’s likely to grow larger and larger. Performance may not initially matter as you get an early version working. However, it’s one of those areas where you’ll continually have to invest more development hours to ensure real-world data doesn’t adversely affect the performance of the data grid and, by extension, your application as a whole. While it’s important for the developer to dedicate the time required for maintenance, this detracts from other aspects of the role, like adding new features or upgrading other aspects of the application, something that can be challenging to justify to nontechnical stakeholders.

Does code ownership trump the resource burden?

As mentioned above, having ownership over a complex component—in this case, building your own data grid—comes with many maintenance and upkeep requirements, especially for applications with large data sets. Between performance, making sure you’re able to maintain formatting and data fidelity, as well as offering all the import and export options your stakeholders need, maintaining a component like this could really start to add up in terms of developer hours.

Developing a data grid: The buy vs. build question

So with all that in mind, the ultimate question is, should you build a component like this or use one that’s pre-built? Sometimes it can be helpful to put rough estimates of actual costs on a question like this.

Let’s say developer time in your organization costs the equivalent of $150/hour, as it is in Silicon Valley. Developing software like a data grid to the minimum standard of robustness and functionality that a company like Handsontable provides would take a team of three developers at least six months of development time.

And that’s just for the initial build. It doesn’t take into account any future feature requests, bug fixes that arise as a result of data grids not being a core competency of your organization’s developers, etc.

When dealing with such a complex component, it’s easy to see how quickly the costs can add up and why it’s a good idea to license the work of a dedicated team for your data grid component.

Wrapping up

Deciding whether to buy or license a component you need or build it internally is often tricky. It involves weighing such factors as direct financial cost, cost of maintenance and upkeep, ability and need for customization and integration with other systems, and many more.

In this article, you learned that building a component internally gives you more control over the direction of future development and a greater ability to customize it to your needs. However, buying a component rather than building it allows you to keep your costs relatively fixed and to focus more closely on the core problem that your product or service is solving. If you’re buying a product like Handsontable that comes with many hooks and methods to fit your exact needs, you have a flexible component available to help you get the job done, no matter the needs of your product.

Whichever way you decide to go, make sure you consider as many of these factors as possible, get feedback from stakeholders, and be aware of the possible trade-offs of each approach.