Deciding When to Build or When to Buy
July 14, 2020As an engineer or engineering leader building new solutions – this happens very frequently at startups – you often have to answer whether is it better to build a solution from scratch or buy (or rent) an existing and off-the-shelf solution. You may want to build something new, but it may not be the best for your product, company, and customers. The true answer depends on many factors.
To make a good decision, I believe you need to answer three questions:
- Is the problem you’re solving a core competency of your product and/or company?
- Is the cost of building the solution much higher than the cost of buying something now?
- What’s the cost of switching away from the solution later?
Is the problem you’re solving a core competency of your product and/or company?
A core competency is a feature that your product and/or company does very well and differentiates you from your competitors. It provides value to your customers and gives you an advantage.
If the problem you’re solving is a core competency or very closely related to one, then you should build it yourself. This ensures that you deliver the best solution that meets your standards and satisfies your customers. You also avoid depending on third-party providers who likely do not share your vision or values.
If your solution is not a core competency, then you should buy an off-the-shelf solution. This allows you to focus on your core competencies and leverage the expertise of providers who have solved similar problems while also saving time and money by not creating something new.
For example, at a previous startup, we were faced with building a new messaging feature which was going to be integral to the product. After discussing with the team the user experiences we wanted and the costs of vendor solutions at scale (there were very few vendor solutions back then), I made the decision to build our own services. This decision allowed us to implement innovative features because we controlled the entire messaging stack. However, we used AWS’ S3 for media storage which was not a core feature of our product and was widely used and trusted by other businesses.
Is the cost of building the solution much higher than the cost buying something now?
The cost of building versus buying is another factor. This includes not only the direct monetary costs, but should account for also any opportunity costs, technical costs, and team costs.
The direct monetary cost is how much money you need to spend to build or buy something. This includes the initial cost and any ongoing maintenance costs. Building something often needs more upfront investment, but it may also reduce your expenses later. Buying something often has lower initial costs, but it may also have higher expenses later depending on your usage.
The opportunity cost is what you lose by choosing one option over the other; including any potential income made by the other option. Often, building something new will take longer to build, test, and launch than buying something immediately available.
The technical cost is a measure of the complexity and risk of adding something new. For example, this often includes compatibility, security, performance, and/or scalability issues. Building often gives you more control over how it works and integrates with your other systems. Buying often needs less development work but more integration work with your other systems.
The team cost is the cost of taking on a new project or responsibility. This includes the workload, expectations, and communications among other things. Building something new often needs more skills, knowledge, and creativity from your team. Buying something often needs less technical skills but more communication and coordination skills from your team.
If, after totaling these costs, the cost of building is much higher than the cost of buying (now or within the next 6 months), then you may buy an off-the-shelf solution. But if the cost of building is similar or lower than the cost of buying now (or if you expect it to be significantly lower later), then you should consider building a custom solution.
What’s the cost of switching away from the solution, in either case, later?
The last factor is the cost of switching away from whatever you chose, later. This is a measure of the money, time, and effort necessary to change your system. This may happen for different reasons, such as changing customer needs or market trends, new regulations, better alternatives, etc.
Building something gives you more relative flexibility and freedom to change or update as necessary. But you often have more technical debt. If you buy something, you have less control and influence over how it changes or improves over time. But you also have less attachment and commitment to it.
You should estimate the probability of switching and how large its impact will be in the future. If the cost of switching from the solution is high, then you should consider options that are more reliable, stable, and closest to being future-proof. If the cost of switching away from the solution is low, then you should consider options that are more flexible, adaptable, and easy to change in the future.
Summary
To build or to buy is a challenging question that requires thoughtful analysis and consideration. One answer is not going to work for every situation. You should think about your product and/or company’s core competency, the cost of building versus buying now, and the cost of switching away in the future. By asking these three questions each time you are faced with this question, you can make a better and smarter decision that helps drive value for your team, product, company, and customers.
Finally, your costs and priorities will change over time depending on the growth or changing needs of your product. So, it is important to revisit your decisions every few quarters. For example, at a previous startup, we switched away from a vendor’s peer-to-peer messaging solution after seeing it became increasingly expensive, unreliable, and slow at scale. We built and invested in our messaging stack which became useful when implementing new features in the future.
Tags: startup, engineering, leadership, budgeting, resource planning, resource management