Build Vs Buy - Lesser Known Factors to Consider

Build vs Buy decisions while evaluating a software (SaaS) purchase have some of the best arguments and a really tough verdict to arrive at. The cross-functional teams involved often fail to arrive at a logical conclusion, and one or two aspects of the entire argument get weighted down into the decision. It's fair, to be honest; after all, when was the last time a finance, marketing, sales, product, engineering, and quality team agreed on something and went away all happy?

With my background in building internal products from scratch, I have noticed myself ruling differently for different situations because like most things in life - this is also Grey.

There are many resources to help you evaluate this, I will outline some thoughts that are less popularly discussed here -

1. Is it a part of your core value offering? I maintain a strict stand that if this is what you promise as a value to your customer, then you should build it in-house. Even if it is a simple dashboard. The reason is more philosophical or cultural here than anything, a company should always strive to serve their customers better and outsourcing doesn't help you to control the improvement narrative. Example - Unacademy built out its live online classes infrastructure & application in-house and continued to innovate on it. A CRM company should build the 'Automation Workflow' module in-house. Both of these are also readily available as SaaS solutions.

2. Will this tool give you a competitive edge? It's a no-brainer to work on tools that can give you superiority over your competitors in value offering, pricing, speed of expansion etc. Example - Airbnb built out its payments system in 2015 because the existing solutions limited their way of business and international expansion.

3. Can you monetise it later? My favourite companies are the ones that build an internal tool for a use case and then make it a significant revenue stream later by selling to others. Just think about Amazon Web Services (AWS) contributing to >20% of Amazon Inc's revenue today.

4. Opportunity cost (Softer elements) - Apart from the upfront investment of time and money, it's important to look at the softer parts too - motivation and excitement of the team building it. Afterall, they didn't anticipate that they will be doing this when they joined your company. Does building a non core tool in-house bring the team's morale down? Does it lead to increased attrition?

5. Product advancements - This is tricky. With an in-house tool, you get control over the roadmap and build as you want. With a SaaS, you enjoy consistent improvements because the provider has to stay relevant. Spotify decided to buy cloud services from Google rather than continue building and maintaining their own infrastructure. The process took years but it was the right choice for them.

6.?Scope of innovation?- Just copying an existing solution won't be the best use of your talent; why reinvent the wheel? Going after unsolved problems takes care of the team motivation and provides a win-win scenario. This can also mean building partially or on top of an existing solution. Example - an AI intent mapper for your leads based on your unstructured data that enhances the lead scoring feature in a CRM.

7. Recurring cost is not ZERO - Follow a simple formula. If the total salary & admin cost of the team mandated to build and maintain the solution is more or even equal to the subscription cost, then outsource it. Building it in-house should mean significant cost savings, the kind that shows up in the balance sheet or annual investor update.

8. Ignore the implementation time - If all the above are analysed, I don't consider time a major factor. It took 2 years for Airbnb to build the payments system, but it was a good decision. Maybe implement a stop-gap solution in the interim, but it has to make sense in the long term.

9. No good software providers - Last but definitely the most important - if an off-the-shelf product doesn't satisfy your needs then you should build it. There is absolutely no merit in settling for less just because the SaaS world isn't ready with the solution you need.

Many teams favour the 'Build' decision because of the available engineering bandwidth and resources, and many favour the 'Buy' decision because they just want to implement it fast. Both thought processes are dangerous and detrimental to the overall business.

In my list, I have also ignored a few factors like the 'Ease of integration' or 'Risk of completion' because I believe that if you are seriously evaluating this decision, then you will be able to build this successfully OR be able to find a good software provider who fits your needs.