The decision to build vs buy software is something that comes up often at high-growth companies. I don’t hear many people talking about how to make this decision, and it’s something that deserves some rigor around it. So, let’s talk about it.
I’ll start with two anecdotes of build vs buy decisions from the time I was an engineer at OneCare, a consumer PC health/safety subscription service (firewall, antivirus, PC backup etc).
Being a security service, it was critical for us to publish patches and new anti-virus signatures to millions of devices. A service that could publish these patches reliably on a daily basis was a big undertaking. My team and I were opposed to using an external solution but our business team was keen on choosing an existing product because it meant we’d be able to launch the service quickly. Competitors were already gaining market share so the urgency was warranted. The engineering team prevailed and we built this service internally.
Being a subscription service, it was important for us to be able to charge users on a monthly basis. This was another battle of build vs buy. The same lines were drawn. The eng team wanted to build this internally and the business team wanted to use an external vendor. The engineering team prevailed and we built this service internally.
In both cases, I favored building a solution internally because off-the-shelf products:
In hindsight, another important factor was that, as a creative person, I was quite interested in building a billing service and a publishing service, and equally excited to get some headcount and build a team that could do this. It would simply be more fun than integrating with a vendor.
Headcount was approved for both projects. Hiring took longer than expected and we had to pull people from the existing team to start these projects. This resulted in fewer user features that would differentiate the core product. There were many edge cases that we didn’t consider. This complicated the design and implementation phases. Building a service that did a thing was not challenging. Running the service reliably and scalably was the 20% long tail of work that took 80% of our time. This 80% was not accounted for in any planning or costing.
Both services launched within a year. The patch update service continued to gain momentum and usage and was actually a key differentiator for us. As a security service, we were able to highlight that we were more secure because security updates were delivered within minutes of vulnerabilities being detected.
The billing service was decommissioned a year after launch because it had too many gaps, keeping up with new payment systems was a lot of work, and it wasn’t a key differentiator for us.
With these two examples, it’s clear to me that we made a good decision in building our own patch update service and we made a bad decision in building our own billing service. There is no absolute wrong/right when it comes to building vs buying a solution. So, here are some simple but powerful ways to think through this debate.
Companies with engineering horsepower can build anything they want. That’s not the right question. It’s all about whether they should build everything.
Ask yourself if the thing you’re building is directly differentiating your product offering and how you make money. If it’s not core to your business, buying is generally a better option. In our case, as a security service, the ability to publish security patches quickly was core to the product offering of keeping people’s devices safe. Charging their credit cards on a monthly basis was NOT core to our product offering.
If you’re a developer platform that lets engineers build websites or offers a data pipeline or database, should you build your own marketing attribution model? Probably not.
Calculate all costs associated with a build. Often the cost of building a prototype is low. The cost of productization and maintenance is high.
Hidden monetary cost drivers to consider:
Money isn’t the only cost to consider. If the project in consideration is tied to a direct business goal or outcome, what’s the cost of waiting for the internally built solution to the business? The first step in understanding that is building an accurate timeline of the project. This starts with an actual start date. We can have a timeline that suggests it’ll take 3 months but if those 3 months can’t start for 3 months, then the real project timeline is 6 months.
Start dates can be assessed more accurately by asking the following questions:
These questions will help you identify more accurate start dates for the project and “dead zones” within the project timeline where approvals/cross-team scheduling minimizes productivity.
Then there’s the actual timeline to build the project. While I’m a big fan of iterative development, a strawman plan (from people who have a track record of being accurate) is extremely powerful before embarking on a large project.
With time and money costs figured out, it’s time to identify the opportunity cost of building. This is especially important now given moats in businesses are low, technical IP is easy to replicate, and blitzscaling is critical to durable success. Just because our company is doing well doesn’t mean we shouldn’t operate from a place of extreme urgency about customer and revenue growth.
Opportunity cost can be measured in two ways:
Another key element to consider is whether future innovations on the build would be helpful to the business or not. For instance, I recommend buying a marketing attribution solution over building one because companies that think about this problem 24/7 will continue to innovate in the space to be competitive. A homegrown solution will not get the same kind of rigor if it’s not core to the business.
This is by far the most important and difficult part of a true build vs buy exercise because it requires detachment and self reflection. We must ask ourselves about our personal motivations for building vs buying. Is it in the best interest of our customers and our company? Or is it in service of our personal interests and ambitions? I would posit that the former takes priority.
Want more articles like this? Follow Falkon on LinkedIn.