Argument for the off-the-shelf components

Have you ever run into a problem that could be solved by using an off‑the‑shelf solution? You probably asked yourself: is it a good idea? Maybe the problem is simple enough that you could build a simple one in a week. Let’s take a look at when we should consider an off‑the‑shelf component instead of a custom‑made solution.

When not to use public components

Public components are not a solution to everything. Let’s start by clarifying when we should even begin to consider a general‑purpose solution. The main downside of choosing a public library/framework/service is the loss of control. Usually, we don’t have much say in where the tool is going or what the next feature should be. Yes, we can raise a PR, but it could be rejected—and yes, we can fork the project—but usually we pick a public tool to take the burden of maintenance off our plate, so forking is the opposite of our goal. Another downside is that public tools are built for general purpose, so they might not be a perfect fit for our specific needs.

Keeping both in mind—the lack of control and the general‑purpose nature of the tools—where can’t we afford those compromises?

In the core domain of our project. The core domain is the main selling point of the system—it’s one of the primary reasons why customers will choose us. The core domain is a business driver, not a technical one. We need to keep full control of that aspect of the project; it’s the place in code where developers will spend the most time. It also should be the part of your system with the highest quality standards.

Let’s take a look at an example: We are building a system for the car rental business. We have to track the fleet: who rents which car, for how long, and what’s the charge for the service.

The core domain in this example is the whole renting logic—calculating fees, tracking cars. This is the part that has to be developed completely in‑house.

So where are the side domains? Everything else, stuff like:

charging customer credit cards
reports—e.g., most popular car, average rental time, etc.
GPS to monitor the location of our cars in real time
and more

I hope that example makes it clearer when we can pursue outsourcing and when part of the software has to be custom.

With that aside, let’s get back to the main topic of this post: why it’s worth considering off‑the‑shelf components in the supporting domains:

Arguments for off‑the‑shelf components

Documentation

No one likes to write documentation and even fewer like to maintain it. Public components usually come with some kind of documentation. Larger projects are typically better documented. But even smaller projects with aspirations to make a splash usually know that good documentation is a must.

If you are a senior developer, you might think you don’t need documentation—you can read everything from the code! Although that may work for you, you might have less‑experienced devs on your team, and documentation for them could be the only way to learn how the tool works. So as a senior, picking a public tool is an excellent way to spare yourself questions like: “Hey, could you explain this part of the code you wrote 3 years ago?”

Community

If you decide to use a public library, you hop on a boat with some other devs. You are not alone anymore. You can start googling for answers, and if the library is popular there is a chance that someone has had the same problem before. You can open an issue on GitHub and read other issues. Other devs could help you solve your problems or show you solutions you hadn’t considered.

Maintenance

By choosing an actively maintained library, you get its benefits over time. Free improvements, new features and bug fixes to name a few, with minimal effort—just keep the dependency up to date. It saves time you can spend bringing real value to your customers.

Tip

If there isn’t a perfect fit, pick the next‑best tool and make the trade‑offs explicit. Show what changes to requirements would unlock a faster, cheaper solution.

What if there isn’t a tool on the market that perfectly fits the business requirements? Then find the next best fit, list the differences, and present them to the business. Businesses usually don’t know what’s possible in the tech space. If you present your argument as: we might save time by getting this tool, but we will need to adjust our requirements—they might agree to a compromise. If they do, it’s a huge win for the company. A lot of time and money could be saved this way.

If the requirements are strict and we can’t change anything about them, we still have some options:

build the tool they want from the ground up
fork one of the public libraries and adjust the code to the specific needs of the business (check if the license allows you to do so, and try to contribute back 🙏)

The latter still saves time. We are missing some of the benefits of just taking the code as‑is, but at least we can benefit from the collective brain power of previous contributors. I see implementing something from scratch as a last resort—only if you exhaust other possibilities.

Conclusion

Use off‑the‑shelf components in supporting domains to move faster and lean on community and maintenance. Keep the core domain in‑house where you need control, fit, and higher quality standards. When there’s no perfect tool, propose a next‑best fit with clear trade‑offs; go custom only when the business truly can’t compromise.