Curious Product #13 - Should I build or should I buy?
We love building software, but buying is often the best decision
Every post I add a character that inspires me. Today, Chico Mendes. Any pushback against the Amazon deforestation comes from the fight of many environmentalists and natives. It is an unfair battle against economic interests that enrich a few in detriment of the environment. Some, like Chico, sacrificed their own lives to keep the forest alive.
If you work building software you have probably found yourself thinking whether you should build a custom-made solution for the problem at hand. Nowadays there are tons of providers that might address your problem, but you are not sure if they will work in practice. Here are some problems when using a third-party solution:
The demo and proof-of-concept worked fine, but getting to production is a total nightmare because it doesn't scale or don't address an edge case you haven't tested
Your company is not ready for the integration, don't have the necessary APIs / organized data
You aren't sure the solution is going to be maintained or whether this provider will survive in time
Keeping the integration alive will cost a lot of engineering time
We cannot customize it for some of the needs
Then, if you have enough engineers, you decide to build it. The team feels great, we love to build technology. Then you can adapt the solution to you, not the other way around. Sounds great! Until you encounter some problems:
Building what seemed simple features takes longer than predicted
Prioritization changes and the team loses engineers to teams that drive more business impact
You need to release a lot of code to actually add value to the business, and stakeholders cannot wait another month
You decide to cut corners to deliver in the promised timescale, compromising security and the flexibility for the future
Some of your needs are not well addressed and some users look at third-party solutions to showcase ways to better address their problems
So, how can you decide whether to build or buy? It depends on:
the stage of your company
the nature of the problem
the time you have to solve the problem
the stage of the solutions available in the market
Startups default to buying…
In small companies engineering is definitely a bottleneck and you want to buy (at a reasonable price) any solution that solves a problem that is nowadays a commodity: authentication / identity management, CRM, analytics, and so on.
We often see stories of companies (usually in later stages) that built an awesome internal solution for problem X. Don't fall in this trap. As Erik Bernhardsson (Erik for short, I will cite him again) posted:
opportunity cost is a likely cause at startups, but maybe less often at big companies. Why? Because a startup is often playing catch up building things that are mostly “obvious”. When you get to a very late stage, and you have a lot of money and a lot of developers, things get a lot more tricky.
Remember that at early stages (or whenever engineering is a bottleneck) the opportunity cost of building is high and it is usually worth working on integrating and building from a provider.
…unless building will give them competitive advantage
But sometimes you still want to build it because that can give you a competitive advantage. Because any off-the-shelf solution will address your need exactly, there will always be a compromise. You have to constantly evaluate these compromises to see whether that is not hurting the core of your business - if so you are probably better off building it.
Citing Erik in another post (which I recommend everyone to read):
A lack of engineers means a temptation to adopt tools to build technology without using engineers, with associated costs that are much larger.
So if a software gives you competitive advantage and your necessities are particular compared to what you find the market, then you should consider building it.
Sometimes (often) you need it sooner than you can build…
There is a common mistake to underestimate the problem at hand and defaulting to an optimistic view of the capability within the team.
Your stakeholders probably need the solution way sooner than you can build it. And even if they accept a smaller version of the final solution, committing to build becomes an ongoing endeavor that may cost a lot in time.
Many managers make the mistake of treating a new initiative as a one-off business process project when it’s most certainly destined to be an ongoing initiative. Departments typically identify a specific problem in isolation and engage internal IT resources to address it. At first glance, this approach appears to make sense, as internal IT projects are suited to address projects with a limited, well-defined scope. However, complex business processes often span multiple departments and include collaboration with external suppliers.
An organization’s expertise is generally not developing B2B software solutions. Why spend countless hours having your best people -- or hiring new people -- architect a solution that already exists and is proven in the market? Generally, a vendor has already solved the same problem hundreds of times, therefore bringing clients the benefits of best practices based on others’ experiences. - link
…but you need to accept the constraints
As I said before, you won't find something that fits your needs 100%. Off-the-shelf solutions are generic, so if you have particular use cases that you need solved you will probably need a lot of workarounds that might not be feasible in practice. Maintaining those workarounds may delay the setup and cost you a lot in time, so building may be a best option.
Moreover, if you think the demand is not stable in time it means that an off-the-shelf solution that works today may not work tomorrow.
Before making the decision, it is important to identify if the problem you are trying to solve is a tech commodity and what's the ecosystem of providers trying to solve it. If there are several competitors and the technology / problem space is pretty standard (like logging or SMS), probably you will find a provider that will meet most (if not all) of what you need.
Conclusion
We all love building technology, but more and more buying it is probably the best answer. In fact, I believe that most tech companies built in the past 10 years would not be possible without the ecosystem of solutions that are now available.
Decades ago, software engineering was hard because you had to build everything from scratch and solve all these foundational problems. You need storage to build something to serve 1M concurrent users? Wade through papers about consistent hashing, CAP theorem, CRDTs and what not, roll up your sleeves, and prepare yourself for 100,000 lines of hard core C++.
Today, these problems are “mostly” solved, and you can use off-the-shelf tools for most of it. It's not easy though! Like I mentioned earlier, there is no silver bullet, and there's a million tools out there, and you need to know based on best practices how to stitch it all together. But knowing this is a different type of hard. - Erik
Before making your decision, you should answer some key questions:
Is engineering a big bottleneck at my company? Yes - buy
How much time do I have to solve the problem? Little - buy
Does building a customized solution give me a competitive advantage? Yes - build
Are my needs generic and quite stable in time? Yes - buy
Is this technology a commodity and there are many providers available? Yes - buy
Is the cost of implementation and integration with a third-party too high? Yes - build
You should then weight over the answers considering your specific context. For some, speed is the most important factor. For others, customization is way more important. There is no right answer, as I said earlier, it depends.
Thanks for reading!
Always be curious.