A developer’s job isn’t exclusively writing code. The job is to build systems that bring value to the business. Often times that means choosing to use software written by third parties instead of writing the code from scratch. Whether the option is to purchase a proprietary solution or using an open source one, the situation is the same: the software you are building is now reliant on a third party. For this reason, building your own software has a number of advantages. The first of which is that you get exactly what you need. Off the shelf software has to be built with lots of different types of users in mind. Your software only needs to be built with you in mind. And if you discover that you need something, you can choose to build it yourself instead of waiting for a third party to do so.

All software can fail as well, including third party software. If you find a critical issue with your own software, you can schedule it to be fixed immediately. With third party software, you usually have to convince someone else to do it. You can do it yourself with open source software, but it takes time to learn how a software system works and critical issues tend to be time sensitive. Worst case, the third party may refuse to fix something for whatever reason. That results in you having to build awkward work arounds that add bad technical debt to your code base.

That also leads to the fact that most third parties won’t advertise the downsides with their software. Users have to find those out on their own. While there can be hidden surprises when you write code yourself, there is less you can do when those surprises come from a third party.

All that being said, there are some big, BIG, disadvantages with building software yourself. The most important one is:

Building software is extremely expensive.

Third parties that are dedicated to providing one piece of software are more focused. They have thought of things that you won’t because they have more resources to spend on thinking of those things. That means you’ll have to deal with fewer bugs/issues with a credible third party than you would by building the software yourself. You’re trading the fact that having critical issues with third parties is extremely painful with having a smaller quantity of critical issues.

So how can the decision to build or buy software be made?

We’ll start with one of the earlier statements: “That means you’ll have to deal with fewer bugs/issues with a credible third party”

ElasticSearch is a great search database because it was started by a bunch of developers who had spent years working on search. They already knew a lot of the gotchas that would come up with building that kind of product. The fact that they would build search software with fewer issues than you or I is not questioned, assuming you had no experience building search anyway.

If a team has never before tried to build the type of software they are selling: don’t be their guinea pig. Everyone needs to start somewhere, but developers have a responsibility to do what is best for their projects. That means using third parties that are reliable and can be trusted.

Another factor is the switching cost of software. While there’s always going to be some cost to switch from software provided by one third party to another, some will make it easier than others. One big hurdle here is access to your data. If a third party does not make it easy for you to retrieve all of your data: watch out. That makes switching to something else untenable in most cases because you potentially lose years of valuable data. Databases make it easier to switch because the whole point of a database is to make it easy to store and retrieve data. I’m not saying database migrations are easy, but databases don’t go out of their way to make it difficult.

That leads to the next point: how critical to your business is the software system? If it is a core part of your product, using a third party becomes extremely risky. When you rely on a third party for a core part of your product, you give that third party a lot of power over you.

An example would be Zynga. While they had lots of success using Facebook, things did get dicey at times. At one point Facebook required all apps to use Facebook credits, which gave Facebook 30%.

Can you imagine being told one day that you would be losing 30% of the income you had been making?

Amazon Web Services’ EC2 would not count here. While your software needs computers to run, they can run on any computer. If AWS disappeared or stopped providing services, you could move your software to run somewhere else. It wouldn’t be easy and your software would be unavailable for a time. But we’re talking days, maybe weeks, to move to a different provider as opposed to months or years to rebuild your product.

Some of AWS’ other offerings do tie you to using Amazon exclusively though. That means if you rely on those services for your system, you would have to rebuild a lot of your application’s code to switch to something else.

The last point I’ll discuss is: what is the actual time savings from buying a software system instead of building it? In some cases it is obvious: AWS will save you lots of time over having your own data center. Mysql/ElasticSearch/Cassandra will save you lots of time over building your own database. Most obvious of all: using an existing programming language is going to be much easier than building your own!

But in many cases this will be notoriously difficult to calculate. No third party will ever advertise their limitations. They want you to buy. They will advertise their strengths. You have to discover those limitations for yourself, which can take time. Even then, you will always discover more after 2 years than 2 weeks, so you won’t even know about a number of those limitations until after you have integrated the third party system.

Developers are also often optimistic about how quickly they can build things. That can improperly change the ROI calculations in favor of building over buying.

There’s no magic bullet for getting the time savings calculation right. It really depends on the type of software being evaluated. But being aware of the two main pitfalls listed above should help.

There may also be many important factors specific to your business that I’m skipping here. Regardless of how you decide to handle things though, do not take shortcuts with this decision. The effects of this decision are long lasting. That makes mistakes extremely expensive.

Buying when you should have built incurs the cost of learning how to use the third party system, and potentially paying that third party, before throwing it out and building it yourself anyway.

Building when you should have bought incurs the cost of wasting countless hours of development time on something that brings no value to your business.

Take great care when making this choice.