Buy vs build: It’s not that complicated

It's impossible to be responsible for every single line of code running inside your software. There are so many different layers and concerns involved that you will need to rely on third-party code if you want to ship something any time in the next decade. Everyone understands this to be the case -- after all, you've probably never heard a software engineer suggest that the company rolls their own operating system instead of using Linux -- but just because we know that some of our software needs to use external code doesn't mean that we know where those parts actually are.

There are a lot of articles on the Internet which aim to inform your decision making for when to buy an off-the-shelf solution versus building a solution in-house, but I think the vast majority of them overcomplicate the issue. Software engineering is not the only field in the world for which this question comes up.

Nobody has ever started a coffee shop and seriously considered the possibility of building their own espresso machines instead of just purchasing them. Frankly the idea of doing so is absurd, and anybody asking for a loan in order to fund R&D for their bespoke espresso machine so that they can start up a café would get laughed out of the building. And to be clear here, that's not because there aren't legitimate reasons why you might want a bespoke espresso machine -- after all, Starbucks has an exclusive deal with Thermoplan AG which produces exclusive espresso machines for them. You just don't need an arrangement like this when you're operating a single storefront that sells 250 cups of coffee a day.

There's a dizzying array of examples like this. The vast majority of clothing stores aren't building all of their racks and mannequins themselves, your accountant probably uses Xero instead of some custom piece of software they commissioned, and Spotify uses GitHub Enterprise. Real world businesses use external tools, services, and products every day without ever needing to think twice about it.

So why do software engineers have difficulty making "buy vs build" decisions? I think there are two main reasons.

1. Software engineers are creative and driven individuals who want to solve problems themselves
2. It's really hard to accurately calculate the total cost of ownership of software projects

The software engineers

Intercom is a SaaS app which allows you to add livechat functionality to your website. How hard could it be to roll your own version? At a basic level, all you need is a text field and two API endpoints which will allow users to post messages and fetch a list of messages. Joe can have a proof of concept written by the end of tomorrow, and we can go live in 2-3 weeks.

We software engineers tend to underestimate the difficulty of a project and overestimate our technical capabilities. Intercom seems like a simple product at first blush, but like always the devil is in the details. Joe isn't going to be able to build a user interface as slick as Intercom's in the next few weeks, and Joe's home-brew solution isn't going to integrate with all of the other SaaS apps you're using out of the box. Outside of product features, you're also taking on all responsibility for the security, scaling, and operational concerns of your livechat by building your own solution instead of just using Intercom. These things are all really complicated, and take time to get right. Anybody can build a barebones livechat system over the span of a week, but building a product that's complete and handles all of the edge cases is going to take a lot longer.

And at the end of all that, you've managed to save a few hundred dollars per month (assuming Intercom's "Grow" plan is suitable for you -- which it likely is if you're an early stage startup).

As a project manager you need to be aware of engineers' tendency to want to do things themselves. Why do people become engineers? Broadly speaking, to solve problems and have variety in their work. Adding on more scope to a project is a fantastic way to find more challenges to solve and a terrible way to get something shipped on time.

Total cost of ownership

And on the business side we have the same problem manifested slightly differently. Engineers underestimate the complexity of building due to optimism and enthusiasm, but decision makers can find themselves doing the same thing when they don't have an understanding of the technical details involved in the "build vs buy" decision.

There's no substitute here for having development experience on projects which went poorly. But some questions you should be asking yourself are:

1. What are your scalability requirements? How confident are you with your numbers?
2. What will be required operationally in order to keep this system running without errors?
3. How much ongoing maintenance will be required in order to fix bugs and add features?
4. How long will it take to get this system finished? Will it block other items on your roadmap?
5. If development of this system goes over schedule, do you have a contingency plan?

The stats for software projects are not good. 66% of software projects run over budget, and 33% of software projects are delivered late. If getting to market in a timely fashion is important to your business -- and it likely is -- then you need to be able to jealously protect the scope of your project. Every time you add more work for your development team without removing something else, you are pushing your business closer towards the 'overrun' group.

You will be uncertain about at least some of the questions above. HEY initially launched their product using Amazon Web Services for their cloud infrastructure despite the fact that they knew they eventually wanted to move everything on-premises. Using AWS paid off massively for them when their launch exceeded everybody's expectations, including the founder's. Using robust off-the-shelf solutions improves your organization's resilience and enables you to absorb traffic spikes and keep those parts of your product working around the clock.

Is $119/month a steep price to pay for livechat functionality from Intercom? It does seem a bit high at first blush. Another way to look at it is that you're hiring Intercom's developers, QA staff, and operations team for $119/month -- and that is a steal. If you did decide to build the software inhouse and you managed to find a contractor who would do it for $119/month then there is no universe where you wouldn't take them in on the spot. $119 might be two hours of your developer's time, and there's no way you're getting livechat implemented by yourself in less than two hours.

Conclusion & guidelines

So how do you decide what to buy vs build? In my opinion there are three key questions you need to answer:

1. Is this component of our software part of our core value proposition?
2. Are there no off-the-shelf solutions 'near enough' to what we're looking for?
3. Will removing this feature from your software hurt your ability to acquire customers?

If you answered "no" to any of those questions, then you should buy something. If you answered "yes" to all three, then there is a strong likelihood that you should build a solution inhouse. It's honestly as simple as that. If you're starting a business then you need to solve one problem really well, and you're simply not going to be able to do that if you fragment your attention and bolster your scope.

Huge companies are an exception to this, and you should not be looking to them for inspiration. Google has their own code review tool called Gerrit. That's because Google has thousands of software engineers and at that scale marginal improvements in productivity result in large gains for the company. It's common sense that an HR department responsible for 30 employees will operate differently from an HR department responsible for 100,000 employees but the tech equivalent of that scenario seems less obvious to people.

Unless it's core to your business or you have a really good reason, you should buy. Building is hard, and you shouldn't take on the pain and complexity inherent to that decision unless you have no other option.