Buy vs build
It’s a spectrum, and there is no free lunch
A while ago, I was presenting to the Chief Revenue Officer about the progress we had made with the infrastructure to personalize a surface of our product that featured a display banner (a kind of “what’s new” section to highlight new features). Previously, this display banner was static and very cumbersome to change, requiring a full deployment every time the marketing team wanted to update it. After investing in the backend architecture, it became possible to display content dynamically, based on the user landing on that surface.
This new capability opened the door to personalizing the banner, making it more relevant for users and more effective for the business. My team was tasked with building a recommender system to determine which banner to display based on user attributes, with the goal of driving revenue and increasing product adoption. Towards the end of my presentation, the Head of IT commented, “This is a very common use case. There are many solutions we can buy to do this.” I replied that I would love to discuss alternatives offline, mainly to avoid derailing the presentation. I already knew this was the classic reaction of a rather clueless IT person, biased toward vendors and tools.
"Buy vs. build" is one of the most common decisions executives face: should we buy or build a tool or system to solve a business problem or meet a business need? The dilemma is often framed as a binary choice between two extremes, but the reality is far more fuzzy.
The “build” option usually involves many smaller “buy vs. build” decisions along the way. For example, even if you decide to build a billing system instead of buying Stripe, you’ll still need an event streaming platform and an OLTP database. Unless you want to create those from scratch, you’ll purchase existing solutions like Kafka and Postgres (open-source solutions, though free, still fall under the “buy” umbrella).
On the other hand, the “buy” option is often portrayed as the easy but expensive route. You pay more money but do no work, like a Renaissance patron commissioning a marble statue: “Call me when it’s ready.” This is only true if the problem is very standard and business-agnostic.
For example, if you need an internal messaging app, just buy Slack, don’t build one. In other cases, however, the need for integration with the business’s operations becomes more complex, and the “buy” option starts to require elements of “build” in terms of customization. If you buy Salesforce instead of building a CRM from scratch, you’ll need people (Salesforce engineers) to maintain it and expand its functionality, whether in-house or through contractors.
In the world of data, the level of integration with the business is even higher. While the classes of problems are relatively standard across companies, the specific instances are often unique. For example, a media mix model to optimize budget allocation is too underspecified and dependent on the available data to be solved with an off-the-shelf tool. The same applies to most data problems, such as churn prevention, product recommendations, and revenue forecasting.
At the start of a data project, you may not even know if the problem is solvable with the available data. Maybe you don’t have enough history, or not enough variability, or the correct granularity. You may need to acquire external data or instrument your product to collect the necessary data and try again six months later.
This is why even building through an external vendor might not be an option. The great John K. Thompson in Building Analytics Teams explains it well:
One of the problems of outsourcing anything — not only analytics but any project — is that you need to know what you want to have in the end before you start. How can you expect an external vendor to deliver exactly what you want, when you want it, at the expected cost when you don't know what you want or how to achieve it? Sounds straightforward, right? You would be surprised how many executives, firms, and teams have little to no idea of what they want to do.