Build vs. Buy Decision Making

In the tech world we’re often privileged to be able to create our own solutions to problems that we have. However this may not always be the right approach - often our problems are less unique than we think and could be solved with existing industry solutions. How do we know which approach is the right approach?

Whenever we are exploring a new problem we want to ask ourselves whether it’s a solution that we should build ourselves, or whether we should instead purchase something off the shelf from an existing provider.

To help guide us in the decision we look at several factors along a scale with building it in-house on one side, and purchasing a solution on the other. The scale purposefully does not have a “neither” or “average” option in order to better guide our decision making. Rarely will “neutral” be the correct evaluation when taking all the factors into account.

We have created a template and when using it, it is not unexpected that some factors fall on either side, however when taken as a whole it should hopefully become clear what is the right path.

Solution Purpose

We have a central purpose and central business goal, and applications that don’t differentiate us in our core business should be bought. A good rule of thumb is that if we cannot find a provider “off the shelf” in the space of what we want to do then we should probably build the capability in-house.

Cost

Cost is often the most visible driver in build vs buy decisions, however initial cost to build/buy is only a small part of the equation. Once deployed, application costs include maintenance and changes. We should take a look at the total amount of resources and people needed to maintain each solution. These extra costs often also include more time spent by the team as well as the knowledge burden of learning about more tools and systems.

Organisation Culture & Track record

Tech people want to innovate, create and “wow” the customer. But wanting and having the capabilities to do so are two different things. If we have a culture that does not foster innovation, speed, agility, and fast delivery, then “Buy” should be the first option. This can be true in general for the organisation, but if the team responsible is new (or even yet to be formed) then we should consider “Buy”. If we have a proven record, then all options should be on the table.

Package Fit

If we know what we need it is much easier to compare to existing solutions. In cases where requirements are not well understood or are evolving, building (at least to minimally viable product level) is often the best route. This will often be the fastest way to discover what it is that we actually need. However when looking at solutions the minimum-lovable-product (or MVP) should include both functionality and architecture.

Time To Value

If the package fits the business and technology needs and the software provider has a good track record, buying will almost always be faster than building. An exception is when the “critical few” requirements are much smaller than that. If the “critical few” are smaller enough subset, then building a MVP may be quicker, at least in the short term. This is all about how fast we can have a solution that brings value to the organisation.