Build vs Buy: The never-ending decision

This article was written for and originally appeared on Blueprint by Tiny.

It always feels pretty awesome to buy something. Especially when the delivery guy arrives with your new package. On the other hand, building something can give an equally-as-awesome feeling - having created something yourself. But in the web world, how do you decide: build vs buy?

This question is often asked in web development projects: what components can we “buy” and what do we need to “build”?

But first, what do we mean by “buy” and what do we mean by “build”?

“Buy” can refer to buying a package to include in your project to meet certain requirements, or even using an open-source package. It could be a small component (such as something for date formatting) or a larger component (such as a WYSIWYG editor like TinyMCE) or even a complete system. For simplicity in this article, I’m using “buy” to reference the incorporation of any package into your project, whether it actually has a direct monetary cost or not.

“Build” is the process of scoping and building something that meets all of your requirements yourself.

There are times when building is not the best option - when it would have you reinventing the wheel unnecessarily. It can take your focus off of your project’s actual requirements, and also create additional coding work. In this instance, buying an off-the-shelf package can help keep you on track.

While using an existing package can make parts of your project easier, it is worth considering exactly what the package is going to give you - in terms of features, support, longevity, and even file size.

1. Size

If you’re making a web app and decide on a package that has 20 different features, and you only utilize one specific feature, then you may be adding unnecessary bloat to your project. If you’re using only a fraction of the package’s features, are you sure that package’s weight is worth it? Before deciding on a package, look it up on Bundle Phobia to find out the cost, in file size, for adding it to your project.

2. Cost

Existing packages can come with other costs too: some may have monthly or yearly licensing requirements, with on-going costs you need to pay to keep using it. Some features may be available at no cost, but others may require an on-going commercial agreement. When choosing a package that comes with costs, consider how these costs get incorporated into your project. You could even speak to the developer/provider to see if a plan can be tailored for your use case. Either way, it’s always good to support the developers of your favorite packages.

3. Licensing

Speaking of a package’s license, when incorporating any third-party package, make sure you read the license that comes with it - be that a commercial license, or even one of the many open source license variations. It is your responsibility to ensure you’re actually able to incorporate that package into your specific project.

4. Activity

If you’re using an off the shelf package, it is worth reviewing when it was last updated. Looking at a package’s history - such as the commit history or Issues list on GitHub - can be a great way to see how committed the contributors are to supporting the package. If the package was last updated a few days ago, and is in a mature state, you can feel more confident than if a package was last updated a few years ago.

5. Quality

One final consideration is the quality of the package, particularly around browser support. While behavior between different browsers is now far more consistent than it used to be, don’t forget to review any off-the-shelf packages in your client’s required browser list to ensure they are supported - especially if your clients are using less-than-current (yet still “officially” supported) browsers.

There are so many great reasons to buy into an existing package - but also some considerations to ponder before taking that leap. You’d hate to incorporate a package and have it become obsolete or no longer function with no clear support path.

If you’re a developer reading this, you’ll get it: building things is fun. When your needs don’t fall in the “buy” category, you can go down the “build” path, but there are some different considerations to keep in mind when you do.

1. Reinvention

When you have an incredibly unique or business-specific workflow or requirement, build may be the best choice. But when a particular requirement is rather common - maybe something like date manipulation in JavaScript - using an existing library such as day.js may be better so that you can keep yourself focused on the project requirements. There’s no point reinventing the wheel when these existing packages can already do it for you.

2. Resources

While a sales team or business lead may have brilliant ideas about what their dev team can build, the bigger question that you need to ask is: can the dev team actually build it? Does our team have the necessary resources and skills to dedicate to the build process? You need to look at so many aspects: actual human power and skill, budgetary and time constraints, and even physical resources like whether you have enough hardware for your team to use.

3. Support

But it is not only the building of it, but the support of the package too. Ensuring the package is documented, tested, and reliable requires commitment from your developers, and before making the build vs buy decision, it is important to know what your team has the capacity - skills-wise and financially - to deliver. You also need to consider the need for on-going internal support as the project evolves even if the original coders have left the team.

4. Hybrid

One variation here is that you could select an open source package that appears to be abandoned, with the plan of converting it from a “buy” choice to a “build” choice by continuing development internally. This can initially help your own project goals, and if you then release it back to open source, you can end up helping other developers too. Just don’t forget the cost to your team to maintain it moving forward. While this may not fit for all teams, it’s worth considering - even if just to see how a currently-active package could be supported by your team should it become abandoned - and could be a happy compromise of both “buy” for the initial start-up and “build” for the on-going use.

What is the cost difference for the business between building and buying? Not just the up-front cost, but the on-going cost? What problem are you trying to solve? Which path is able to solve your problem best without introducing additional risks?

When I need a WYSIWYG editor, I “buy” with TinyMCE - why reinvent the wheel when TinyMCE ticks all of the boxes (and is extensible when I need it to do more than what it provides out-of-the-box)?

But when I needed an Avatar component recently, some packages were adding unnecessary bloat: embedding styles (that you can’t easily change), adding extra dependencies, and not resulting in what I ultimately wanted. In other words, they were not ticking my requirements list. So while “buy” was an option, it added undesired compromises, so I decided to “build”.

The Build vs Buy debate isn’t just for your project as a whole, but also for the choices made during development for the individual components within the project. Ultimately there is no one-size-fits-all answer - it comes down to your project’s requirements - but if you can utilize a package to help make your development more efficient, don’t be afraid to “buy”. On the other hand, if a package forces you to adjust your requirements, “build” may be a better fit. The one exception is Lego: you always build Lego.