Questions to ask when making Build versus Buy decision

Most software companies have to make decisions on whether to build a custom software or buy it from a vendor. Some of these decisions are mentioned below.

• Should we build the recruitment tracking system or buy it?
• Should we build a custom video KYC solution or buy an existing one?
• Should we build a custom CRM or buy it?
• Should we build a custom CMS or buy it?
• Should we run your own CI server or use a cloud service like CircleCI?
• Should we build our search engine using Solr or Elastic search  or use a service like Algolia?

Most tech companies have the desire to build their own special custom software. This is because they think:

1. They can build software that will cost us less (in the long run)
2. They have a special process that existing tools do not support or will have difficulty in supporting
3. They can bake special algorithms/components in the system
4. They can have tighter integration with their existing stack
5. They will avoid vendor lock-in

In the last year I read many good articles on the web(see References section) that helped shape my thoughts on how to approach these discussions. Below are the list of questions that I have started to use to understand and make these decisions.

1. Does the product fit into the core competency of organization? 
   1. If you are sure that the product fits the core competency then organization should build it. But rarely I have seen organizations have a clear understanding of their core competency. Most organizations struggle to define their circle of competence and try to grow in areas they don’t have much expertise in. This leads to disappointment in future. This is not an easy question to answer and you have to look it from multiple aspects.
2. Is it a commodity feature or strategic to the organization?
   1. It’s worth building when something is core to your business or provides a significant competitive advantage. If what you are building is what everyone else is doing then there is little value in building your own software. 
   2. Organizations should favor building software that is customer facing. You can’t buy differentiation, you build it.
   3. Another related question is – Do we plan to sell the software that we are building? If yes, then build might be a better choice.
3. Will the organization keep investing in the tool over time to make it more efficient and productive?
   1. Most successful products constantly evolve and require improvements and maintenance. This means you have to keep investing in the software to make it more efficient and productive. A software vendor can keep investing in their tool to make it better for all customers. This keeps them in the game for the long run. Your organization might not have the resources or the incentive to do it. 
4. What is special about your workflow that can’t be done with existing tools?
   1. This requires understanding the workflow and process used at the organization and mapping it to workflows and processes supported by tools. For a bigger organization it might make sense to build a tool to match their special workflow as they can justify it by efficiency gain they can achieve by building their custom tool. 
   2. After you reach a certain scale it might be better to build your own software. Uber built their own custom version of Greenhouse and Zendesk once they grew to 2,000 engineers as they were unable to customize it to their needs.
5. What is the total cost of running the vendor software? 
   1. There are multiple costs of running a vendor software. Running your own software has a significant operational cost and a large opportunity cost. To consider the total cost you need to include following costs:
      1. Integration cost is the cost of integrating software into your environment. If you already have a vendor then you have to consider the migration effort of moving data from existing system to the new system. Also, there are your upfront costs before the vendor can start creating value. 
      2. Financial costs are how much the contract costs, including projecting utilization over time to understand future costs. 
      3. Operating cost is the cost of running the software.If you use an on-premise solution then you need to consider the upgrade cost as well. So, you have to understand what is the upgrade path and who owns it.
      4. Opportunity cost is the cost you pay as you could have done something else with the same resources. Organization resources are finite and there is the opportunity cost of the other things that engineers could build.
6. Do you have the operational excellence to run the software at high availability?
   1. This requires understanding the technology stack and architecture of the vendor software and seeing if an organization has the right skills and expertise to keep the system running at some guaranteed SLA.
7. How will you extend the vendor software? What is possible in their architecture? Is it possible to replace one component of their architecture with something custom? How much customization is possible to make it work for your use case?
   1. Eventually, you will need to tweak the software to meet your specific needs. It could happen that 80% of your needs are met  by an off-the-shelf tool. But the remaining 20% of your needs that are specific.. So we must still be able to develop these specific features on top of the 3rd party tool.
8. Can you do a small timeboxed POC to test the solution?
   1. It is difficult to believe the picture that sales representatives paint when they sell their software. So, it is essential that you should be able to test the vendor software before buying it. You have to define a minimal scope and criterias to test the software. By testing the solution, you will quickly assess the quality of the technical documentation, knowledge of support staff, and the usability of the tool.
9. What else can your developers build in that time?
   1. This is related to the opportunity cost we discussed above.
10. How the cost of vendor software rises as usage of the tool increases? 
    1. This is especially true for log aggregation tools that charge by number of log lines.
11. What impact billing models have on the tool usage? 
    1. Below is the text that I read in an HN post. It drives this point home.
       1. One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day.  This can set up a weird incentive. If you are already close to the limit of your plan, you’ll find that engineers are discouraged from logging new things.  This can have a subtle effect on your culture. Engineers who don’t want to get into a budgeting conversation will end up avoiding using key tools, and this can cost you a lot of money in terms of invisible lost productivity.  Tools that charge per-head have a similar problem: if your analytics tool charges per head, your junior engineers won’t have access to this. This means you won’t build a culture where engineers use analytics to help make decisions.  This is a very tricky dynamic. On the one hand it’s clearly completely crazy to invest in building your own logging or analytics solutions – you should be spending engineering effort solving the problems that are unique to your company!

Build vs Buy is not an easy decision and it will always depend on the context. I hope the above questions help you understand the context better and make an informed decision.

The answers you get depend upon the questions you ask.

Thomas Kuhn

I also found a build vs buy cost calculator from the Baremetrics team that you can use to make the decision.

References

1. Build vs Buy – Link
2. ManoMano’s “make or buy” decision grid – Link
3. Video: Build vs Buy: Software Systems at Jurassic Park – Link
4. “Fake COTS” and the one-day rule – Link
5. Buy Don’t Build: Avoiding Ops For Fun and Profit – Link