How to Reduce Arguments in the Build-Vs-Buy Debate

Along the path to building software, lies a question frequently asked: build or buy? The answer to this query is the subject of a heated debate. The battle is frequently contentious. Yet, its intensity can be ramped down. To cool tempers in the build-buy clash, a development team should use a multi-factor approach to guide its decision-making.

Centrality to a System’s Architecture

The more influential a technology/element is on a system the less attractive the purchase/acquire option becomes. The decision to procure a solution has a risk that the choice to build does not. A purchased part contains the threat that a team misjudges the impact that a piece’s assumptions have on a product’s design. A team understands its software better than any third party could. An external group is likely to make assumptions that are untrue for a team’s system. These assumptions could negatively affect a product’s design to the point that it must be scrapped. Software’s architecture is most affected by its most central technologies. If those implementations make woefully incorrect assumptions about a system, then those elements could lead to a product that must be thrown out. If that software’s core technologies were built rather than bought, then the system might not have been scrapped. The product’s team has knowledge that third parties do not, making the unit less likely to make woefully inadequate assumptions about its own software, leading the group to abandon its system. Products whose central parts are built rather than bought are more likely to survive, making the build option more attractive than the buy option, for influential technologies or elements.

Magnitude of Effort

An inverse relationship exists between the effort required to build a part/solution and the allure of the build-option. Its appeal decreases as its work requirements increase. Each additional unit of exertion raises the risk associated with the decision to build. As the blocks of required energy build up, the choice to construct must deliver a larger benefit. More effort means a higher cost. The higher the price is, the higher the build-option’s reward must be. As that required payoff increases, the risk that it is unmet rises. As that threat grows, the attractiveness of the build-option shrinks. The allure of the decision to assemble an element/technology is inverse to the effort required to construct it.

Amount of Specialized Knowledge

An inverse relationship exists between the specialized knowledge required to build a piece/implementation and the appeal of the build decision. Each block of specialized information decreases the allure of the choice to build, because each piece of specialized info increases the risk associated with the build-decision. The danger is that a team will not have, or be able to acquire, the specialized knowledge to construct the solution in question. Without that info, any implementation that is build may be inferior to existing ones or even wholly inadequate. That part might expose a product to significant potential risk. That risk becomes larger as the amount of specialized knowledge increases. The more unique information an implementation requires, the less likely a team is to have it. Without that particular set of info, a unit is more likely to build an inferior or inadequate solution, potentially exposing a system to significant risk. That danger makes the appeal of building any part/technology decrease, as the amount of specialized knowledge increases.


As the size of a part/solution decreases, the appeal of the build-option increases. The decision to build provides less benefit, when an element is small. Tiny implementations are less attractive, because they save little time over the build-option, and they do pose some risk. Acquiring a miniscule piece of code through repository such as NPM has the danger of exposing a project to the threat that the solution will disappear, a problem that does not exist, if a team chooses the build-option. That choice becomes more appealing as a part/solution becomes smaller, because the decision to build costs less in terms of effort as an implementation becomes smaller, and the option poses fewer risks.


As stability decreases, the pull of the buy-option shrinks. The choice to buy becomes less beneficial as stability declines. As fluctuations rise, the amount of work saved by a solution/element lessens. If an implementation does not save much work, then the method does not provide much benefit. 
 A piece without much benefit is not a particularly attractive option to buy.


As maturity declines, the allure of the buy-option drops. The choice to buy becomes less beneficial as maturity falls. As a product/element’s track record lessens, the amount of work that it saves decreases. If a solution does not save much work, then the implementation does not provide much benefit. A part that does not provide much aid is not an attractive purchase.


As support falls, the appeal of the buy-option deteriorates. The decision to buy becomes riskier, if support is in question. For example, support for a solution/element can be depreciated, after a few years, while the product that uses has it to last for a longer period, before the system can be retooled. That software takes a risk, when it decides to acquire an implementation that will not be supported over the product’s required duration. As a part’s support lessens, it opens a system up to risk, decreasing the appeal of purchasing that piece.


The aspects listed above will resolve many arguments but not all of them. These components may be in conflict with one another, in certain cases. These conflicts are bound to lead to their own arguments. Such disputes are not easy to solve, but they only occur in particular edge cases. Those scenarios can be handled as they come along.