The Classic Dilemma of Buy versus Build
A simplified framework for deciding whether you should buy digital assets or build them in-house
Introduction
Many organizations wrestle with the question of whether to build or buy assets, especially in the digital domain. These assets can be broad-ranging: software solutions to run physical infrastructure, analytical dashboards to report business KPIs, AI/ML products for demand forecasting, cost modeling for financial analysis, to name just a few. In this article, we will walk through a cost-benefit analysis framework to help with this decision.
A Framework to Trade off Costs and Benefits
At a fundamental level, we want to pick the option that yields higher net benefits (benefits — costs). There may be other considerations of risk, timelines, management priorities to facilitate the choice between the two options, but in this post, we focus on a cost-benefit trade-off . We start by establishing a timeline over which the product is planned to be used. If we project the technology to become obsolete, or, the business to change during this period, the product costs and benefits would need to be adjusted accordingly. For consistency in comparison between the options, both the bought and built product versions need to support very similar number and type of decisions.
For estimating the net benefits, ideally, we can calculate the NPV by discounting all future costs and benefits in both the build and buy scenarios. However, to keep the framework simple, we can just linearly add and subtract the benefits and costs over the chosen time horizon. It is important to note that all benefits and costs may not have the same weightage. Furthermore, not all comparison attributes are financial, and for an apples-to-apples comparison, we may need to convert them to the same economic basis. For example, if we want to monetize the difference in time it takes to build vs buy, we may quantify the economic opportunity lost by not using a new product during this period. For this monetization, we may also translate the extra time spent by employees on a previously existing process into personnel related costs, when the new product is not available. We could also solve this issue in a semi-quantitative manner by assigning relative scores on a pre-selected scale to each benefit and cost for these two options.
What Criteria should We Use to Make an Informed Choice?
To evaluate the net benefits, we enumerate benefits derived from product functionality and performance, followed by expanding on costs (including upfront costs, recurring expenses, as well as tech support charges). A detailed list is provided in the table below. We should be cautious not to double-count any of the costs or benefits when considering multiple dimensions. One other thing to note is that for any product, we may have different recurring and tech support costs for different service levels.
Summary
Following the 80–20 rule, a simplified framework as discussed in this post should be sufficient for quick decision-making in 80% of business use cases. The power of this framework is that it allows comparison across different product maturities, multiple metrics, and varied service levels. For instance, we may compare a standard product available in the marketplace with a custom minimum viable product (MVP) built in-house. We may also compare separately several metrics such as initial investments, upgrading costs, overall net benefits for a period of interest, if one of these may be more important than others to the decision makers.
Thoughts? Feel free to send me your comments to rkumar5680@gmail.com. Let’s connect on LinkedIn
