Build vs buy: How to decide if you should develop your own software

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). 

Learning from experience

Anecdote 1: Update service

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. 

Anecdote 2: Billing service

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.

The motivations for building instead of buying

In both cases, I favored building a solution internally because off-the-shelf products:

1. Would be inflexible, unreliable, and unscalable for our specific use cases and customer base
2. Have a high price tag. Rough math on an internal build suggested that it would be cheaper in the 3-5 year horizon.
3. Would have unexpected surprises and delays along the way, including unresponsive external vendors

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.

How it went

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.

Lessons and a framework for making the build vs buy decision

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.

Can you? Yes. But should you?

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.

Monetary costs

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:

1. Data ingestion. Does this project require data ingestion? How will this be done on an ongoing basis? Prototypes rely on occasional data dumps. However, a real solution requires ongoing data ingestion, on-call support, and maintenance to ensure data is flowing in reliably.
2. Integrations. Does this project require integrations with other tools? If so, who’s building those and how will this be done on an ongoing basis? 
3. Updating. As new capabilities are added around this project, integrations are changed, new data is collected, who will be responsible for updating the project to keep it relevant?
4. Maintenance. How much manual work is involved in keeping the project running and what’s the hourly cost of that?
5. Infrastructure. What infrastructure is required to run this project and what’s the cost of this? Who is maintaining this infrastructure and what’s the monetary cost of their time?
6. Adoption. What is the cost of onboarding and training people who will use this project? Who will be doing this and how much effort will it require? What’s the monetary cost of their time? Many projects die a slow death because there was never internal adoption.

Time cost

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:

• Do people need to be hired in order for the project to happen? 
• If so, with the great resignation impacting hiring, what assumptions are you making about time to hire people and onboard them? 
• Does headcount need to be approved? 
• Do various teams have to provide team members for the project to come together (e.g. engineering, data science, design, data engineering)? 

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. 

Opportunity cost

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:

1. If the people that are tasked with building this project were to work on something directly customer impacting, what would be the gains in engagement / conversion / growth? Are those gains worth losing in favor of this project? 
2. What business outcome are we postponing while the project is being built and what’s the cost of that wait? In our case, building a service for our security solution delayed the launch of the product by six months. This meant we missed holiday season sales and our competitors gained market share. Both can be approximated in terms of lost users and lost revenue. 

Future proofing

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. 

Intellectual honesty

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.