Build vs Buy – Not So Fast…

We’ve all been here before.

A new feature should be implemented in the system we’re working on, and the team is divided:

Some say – “well, that’s not so hard, let’s develop it!”

Some say – “guys, there is already a tool that does this, let’s use it!”

So we’ve all learned that in the build vs buy case, we should always prefer the Buy side, because it will save us development and maintenance time, and allow the developers to focus on what really matters.

But actually, there is another side to this dilemma.

Buy Is Not Always The Right Choice

There are cases where actually using an existing product can prove wrong.

Sometimes, the guys who shout “let’s develop it!” are correct, and their position actually saves time and money to the project.

I know it’s against the common wisdom, but we should really test our stance here on a case by case basis.

So let’s look at some factors that can make us decide to develop a feature instead of using an existing product.

1. Cost

“Elementary, my dear Watson”. If the tool we’re considering to buy costs 100K USD, and all the project’s budget is 50K USD, then we probably should not buy it.

But even in less extreme cases, just make a clear and concise calculation:

if ((Cost of development + cost of maintenance) < Cost of product)  {
   // Consider developing the feature

Now, this is of course not an exact science, and you should factor in future updates, support calls and so on, but before making a decision, you must have the numbers in front of you in order to make an informed one.

2. Licensing

You didn’t think you’ll see this factor here, right?

Licensing is one of the most overlooked factors in the software industry. Since developers, and not lawyers, are the ones making the technical decision, they often simply ignore the license and clicking “Agree”.

Come on, let’s be honest here. No one reads the license terms. But that’s a mistake that can come back and bite you in the a**.

For example, if you use a software module in your system, are you sure it’s a royalty free module? Or maybe you have to pay the author for every client of yours that uses the software?

Or – if the module is open source, do you have to make your software open source too? Not a bad idea, I know, but definitely something that should be decided by management, and not a developer who really wants to use this specific package.

3. Support

Yes, I know. Support is usually on the “Pro” side of the Buy, but there is another side for this equation.

When you decide on using a new, non-familiar product, someone has to support it in the organization.

Think about new database.

Say the development team really wants to use MongoDB for their new, shiny system. They download and install it, start using it, and everyone’s happy.

And then some obscure error occurs.

Who’s going to handle it?

The IT guys? They will immediately send you to the DBA team.

The DBA team has no idea how the handle Mongo’s problems. They are well versed in more traditional databases such as MS SQL or MySQL, but they were not part of the decision loop here, and were never asked about their opinion and support commitment on Mongo.

So what happens?

The development team becomes also the support team for the new product, and, instead of actually developing, they’re playing around with servers, indexes, and many other non-development activities.

Not good.

So if you consider using an existing tool – make sure there is someone to back you on this.


So To Summarize…

The “Build vs Buy” dilemma is alive and well. It’s not always easy to pick the right choice, and make sure you factor in all the relevant data so you can make an informed decision on that.

Any thoughts? Let me know in the comments!



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.