Build vs. buy in times of economic uncertainty
As we find ourselves in times of economic uncertainty, no one knows quite what to expect or how to prepare for the next couple of years. What we do know for certain is that with interest rates rising, the cost of capital is climbing much higher than we have gotten used to over the last several years, and does not appear to be slowing down anytime soon.
In today’s climate, pre-revenue and/or research-heavy companies find themselves urgently racing to production in order to bring in revenue and avoid costly capital raises. Often, it is these future-looking companies that rely rather heavily on advanced development toolsets and platforms to build their products/services.
The difficult decision many of these companies face now more than ever is whether they should build or buy these development tools. As we know, this decision was much easier just a year ago when the capital was practically free. Cheap capital allowed engineers to build almost anything in-house (even ubiquitous tools like Slack!). However, this decision bears much more weight now. In this article, we will explore the benefits and drawbacks of buying a platform versus building one internally and explore the scenarios in which each decision makes the most sense.
Reasons to buy
Depending on your situation, there may be very compelling reasons to buy a solution. Below are the factors that a decision-maker should consider when making this decision:
Cost of ownership: In most cases, it is significantly less costly to get to production when buying a solution as opposed to building one internally. The typical cost of buying is around 5–10% of the total cost of building and maintaining a platform.
Time to market: When buying a product/platform, the time of adoption can be a matter of days. Building internal toolsets and platforms, depending on the complexity, can take weeks or months. The high cost of delayed revenue is often the greatest reason to buy.
Dependency and Agility: Buying a product allows your team to remain agile and does not create dependence on employees to own internal products, keeping the team agile and the payroll leaner. When building, you have a dependency on employees to develop and maintain the product. These employees cannot usually move around internally with much agility if they are tied up managing a platform.
The cold hard truth is, if you are an owner or executive who plans to downsize your company, you will not be able to let these employees go without the product deteriorating. There is often a hard dependency on these specialized platform/toolset folks which could be incredibly expensive and add unnecessary overhead to your organization.
De-risking unknown unknowns: When buying a product, it is (hopefully) used by other customers similar to your organization, and a lot of unknown unknowns have already been solved during both development and use in production. When building a product, you know some of what you do not know — but it is the unknown unknowns that are usually the expensive, time-consuming obstacles. Unknown unknowns may even force you to wrap up a project before it ever gets to production. For this reason, it is usually much safer to rely on platforms with a proven track record that other teams already use in production.
Bring best practices with tools: All good platforms and products are usually built based on the feedback of their many users. Buying a product brings capabilities to your team, but products offer more than just that. Equally as important, products should also bring best practices to your organization that would be time-consuming, expensive, and challenging to establish through trial and experimentation. Buying reduces your R&D costs as you race to production. In today’s economic climate, why contemplate problems that have already been solved?
To summarize the argument for buying: from a business perspective, buying is easier, faster, less expensive, and less risky.
Reasons to build
There are many legitimate reasons to build platforms internally. Here are the factors that you need to consider if you decide to build:
Always build your core IP: If your org is working on an IP-heavy application and the platform IP is very much related to the end product, you bring defensibility to your IP if the solution is built rather than bought.
Bespoke-ness: If your team’s challenges or existing systems are so bespoke that the time of integration and adoption of an external product is comparable to the time of development, then there is a very strong case for building.
You hacked it and it worked: If you have built something that works well enough, and you only spend two (or fewer) engineering hours per week supporting it, then using a solution provider is not worth it.
Cost at scale: At times, the scale of operation (i.e., the amount of data) is so large that the cost of relying on external platforms is prohibitive. Having that said, vendors often provide deep discounts for large accounts.
Pride/fun: The decision to build is not always strictly a business decision. In an economic environment of prosperity, teams and individuals build a great deal for the simple pride and enjoyment of it. Teams at large tech companies have been known to develop solutions that are not necessary to build (i.e. Slack alternatives), but do so for the love of the work.
What if the off-the-shelf tool doesn’t have it all?
One last factor to consider when making the build vs. buy decision is a hybrid approach. Sometimes, an off-the-shelf (OTS) solution may only solve 90% of your challenges, and you might need to develop 10% yourself.
Now more than ever, you can ask the solution provider to build this last 10% for you. These vendors also want to generate revenue in uncertain times, so if a bit of bespoke-ness is required, you can negotiate this into most service agreements. Instead of having to build 100%, you can buy 90% and commission the last 10%. These days, you can make solution providers work a bit more for their contracts. This tactic might not have worked last Thanksgiving, but the game has changed. Use today’s economic conditions to your advantage.
Take home message: Should I build or buy?
It depends. Unless your required tools and/or current systems are bespoke by design, or part of your core IP, then buying is easier, faster, less expensive, and less risky. Buying will help you save costs, accelerate your time-to-market, and keep the team lean and agile. Even if a bit of custom tailoring is required, a lot of solution providers are willing to do this to ensure their product fits your requirements.
Lastly, buying is less risky from a budgeting perspective. Let’s say your team signs off on a product subscription, but your organization moves in a different direction. You can usually terminate the contract easily enough and avoid the long-term commitment of building/maintaining a solution.
In an environment of economic uncertainty, the urgency to press forward is stronger than ever, yet having the ability to pivot at a moment’s notice has never been more important.
