Cover image for Build Vs Buy Decisions In Software Development

Build Vs Buy Decisions In Software Development

pbeekums profile image Beekey Cheung Originally published at blog.professorbeekums.com on ・1 min read

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.

This post was originally published on blog.professorbeekums.com


Editor guide
jillesvangurp profile image
Jilles van Gurp

When it comes to using third party software you need to balance risk, cost, and potential benefits. Just like with everything else in a software project, doing that is actually surprisingly hard.

A few guidelines:

  • Stick with what you know because by definition the risk is lower and cost + benefits are sort of predictable if you have prior experience. If what you know is proven third party stuff, you need a really good argument to take the risk to not use that.

  • Minimise risk in your projects. Anything new is a risk, especially third party stuff you haven't used before. Risk multiplies instead of adding. So doing three risky things is way more risky than doing two risky things. So switching to a new nosql DB, while adopting some cutting edge cloud platform stuff, while also trying to bring in some unproven enterprise software that promises to solve all the problems you have is going to be very risky. The chance that all three work out as expected is pretty slim. So, maybe not worth doing all three at the same time.

  • When choosing between building new and reusing something you haven't used before, be biased to the latter unless the benefits justify taking a calculated risk by doing the former. Both are by definition risky because of unknown factors but at least the third party stuff usually has some form of track record. .

  • Instead of long term benefits, focus on short term time to market in your tradeoffs. The software you ship next month will have a 12 months head start on providing you ROI compared to the stuff that you will ship a full year later. If that means not reinventing a bunch of wheels and taking a few short cuts, that may be better than taking a lot of risks for 12 months and hoping it comes out nice and shiny on schedule (hint , waterfall is impopular for good reasons). Remove excuses for shipping later rather than sooner. If third party stuff helps you ship faster, by all means go for it. But if it sets you back short term (e.g. because of training), maybe reconsider your options before committing to extended training and integration pain.

  • Look at added value when taking decisions. The reality is that unless it is actively adding value to your product, it is not what you should be spending your time on. Added value is anything your customer would pay for that they can only get from you. Third party commodity stuff is supposed to give you more budget to spend on the stuff that actually creates value. Almost by definition any third party stuff is in the category of commodity stuff that any competitor also has access too. If most of the value of your product is actually you reselling third party stuff, what are you selling really? Also consider that any non value adding stuff you execute poorly, actively removes value from your product. That argues against reinventing wheels poorly.

dennyferra profile image
Denny Ferrassoli

A few other things to consider when building your own (from my experience):

Documentation - What happens when a new hire is added to the project? Can they get up to speed quickly? If a developer runs into an issue where can they find answers or technical details about the software? If you don't have documentation what will happen when a key developer leaves taking all the knowledge of the system with them?

Maintenance - Do you have the resources to support the software and maintain it?

mortoray profile image
edA‑qa mort‑ora‑y

Buying when you should be building is something I've labellbed invented here syndome.