Build Versus Buy: Make the Right Decision With 3 Simple Steps
A couple weeks ago I attended a Point Nine and Algolia happy hour in Dublin. The premise was on point with a recurring question we deal with on a daily basis when it comes to software: “Should you buy versus build internal solutions?”
Many at the event shared the story of an in-house solution turning into a big costly distraction for their team. The main culprit? The decision to build in house was taken lightly without the hypotheses behind this decision being written down and communicated.
I’d like to share here a simple framework I’ve used and that I’ve seen work in this form or another at some of the SaaS rising stars (Algolia, Intercom, Mention…).
This framework helps support data driven, thus dispassionate, decisions on the topic of building vs buying.
The high level structure is:
Step 1: Validate the business need
Step 2: Get a rough but realistic estimate of the cost for the “build” option
Step 3: Decide and review your hypothesis in a given timeframe.
Step 1: Validate the business need
Even Chris Doig in his analysis of the problem writes that everything starts with well-defined requirements. However, as most founders know only too well, every decision to even think about doing something starts with a hypothesis of much positive impact the company can get from a new set of functionality.
Make sure to always go through the exercise of determining how much value you will get from this feature/product you’re considering.
Let’s take the example of building a lead scoring mechanism to help the sales team know which leads they should de-prioritize. The assumption is that the sales team is wasting time on leads that are unlikely to purchase your product at a high-enough price point. Seems fair. But how much value can we expect from implementing such a solution? Keep it simple. Let’s assume you have 10 SDRs, each at a base salary of $50k. If 20% (1 out of 5) of the leads they are reaching out to are unqualified, you are essentially wasting ~$100k annually. And this is without considering the opportunity cost from not spending that time on higher value leads.
With this rough estimate in mind, let’s proceed with evaluating the cost.
Step 2: Define basic requirements and compute an estimate of the cost for the “build” option
Whenever we consider building a solution internally, I like to approach it as I would if I were to write a RFI. This is a great forcing function to decompose the problem and identify the different required functionalities along with their impact on the expected value (aka their criticality). The individual costs are always higher than you initially thought, and the estimates for each item add up quickly!
For example, using the example of lead scoring, decomposing the problem could bring us to the following set of critical features:
- Build a programmatic way to fetch information about new leads from LinkedIn
- Define a heuristic to score leads based on the data obtained
- Build a scoring mechanism
- Build a pipeline to feed this score back into your CRM
- Add the score in a workflow to route leads appropriately
- Set up reports to measure performance in order to make adjustments if necessary
Once you have those listed, get an estimate from the engineering team for building each feature. This will enable you to have an idea of the cost of the “build” option.
You can use a simple spreadsheet to estimate the annual cost of building and maintaining a solution based on your team’s size, current MRR…
Download this calculator here. For an early young company (6 engineers, $100k MRR), the cost of such a solution over the course of a year would be about $80,000.
This may seem high and the truth and that we all have a hard time estimating opportunity cost, maintenance cost (we are typically twice that of initial development)...
In parallel, look around to see what SaaS solutions are available to solve your problem and how much they would cost. A lot of them offer free-trials and/or demos. I recommend going through at least a demo as you will be able to get some valuable information about others who have worked on solving the problem you’re addressing. On the pricing aspect, if no pricing is shown and the product requires a demo, you can be fairly certain the cost will be at least $999/month.
Step 3: Decide and review your hypotheses in a given timeframe
You are now armed with all the data points to take a data driven decision! If you’ve decided to build in house, set a “gate” with your team to revisit the hypotheses you’ve made. For example, decide with your team to have a quick check-in in 90 days to discuss the learnings from building the solution in house and decide whether or not to continue or re-evaluate.
NotesI want to emphasize that no answer can be right without context. What is initially true might very well become wrong. Therefore we’ve built a lot of software to help us determine what are the critical components we would be looking for when shopping around. In these cases it was always essential to timebox the build phase and to constantly remind ourselves that the objective was to reduce uncertainty and unknowns.
Secondly, there is a hidden cost in buying that can come from the rigidity and inadequacy of the SaaS product you buy with your problem. This is why trials and POCs are so popular nowadays (which is why we offer one).
Lastly, the example picked seems like a no-brainer as the solution is for the “business” team. The level of rigour required to go through this exercise for tools used by dev teams is much greater. The main fallacy lying in the illusion that an internal tool will always be a better fit for all the company-specific requirements. This is not only a highly inaccurate; it also leads to ill-defined features. Going through step 1 can save hours of wasted time and headaches.