Build or buy?
This decision gets made dozens of times every year by engineering teams, small and large. It's an important decision, affecting roadmaps, productivity, team composition, and customer happiness. (You know, little things like that.) Making the right build vs. buy decisions can literally make or break a company.
So when should you build and when should you buy?
The answer is: it depends. But not entirely. There are repeatable patterns that teams should use when deciding whether to buy or build.
Wrong reasons to build or buy
Let's start with some antipatterns.
Antipattern: Build if it's mission-critical.
Building your own mission-critical systems sounds like a good idea, but it's self-evidently wrong. I consider a reliable CPU to be mission-critical for most software I build, but I don't build my own CPUs. Partly because I couldn't build a CPU if I tried, but that's not the only reason. Think about all of the mission-critical things we COULD build, but choose not to: servers, datacenters, databases, open-source frameworks, PCI compliance, etc.
In reality, we buy mission-critical things all the time, and for good reasons. The question is not about whether something is mission-critical or not; it's whether an in-house team can deliver higher quality and lower risk than an external system.
Antipattern: Build if you can't afford to buy.
A decade ago I did some side work for a startup that wanted to build a better YouTube via HD video (long before YouTube added HD). The problem was: CDN bandwidth was too expensive and ad CPMs were too low to build a profitable business. Their solution? Build their own CDN to save money. With a single "IT" person who had never done it before. Needless to say, it didn't go well.
Building has significant costs: labor for the initial build, labor for ongoing maintenance and improvements, and underlying infrastructure costs. Opportunity cost is a significant cost too, which we'll address below. Think in terms of total cost of ownership - what am I giving up, now and in the future, by building (or buying)?
Antipattern: Always build.
The third wrong answer is to always build and never buy. This answer is so widespread that it has its own-three letter acronym: NIH ("Not Invented Here").
The biggest problem with NIH syndrome is that it forces teams to do low-value work. The wheel has already been invented, and so inventing it again isn't particularly valuable. NIH work puts you at a disadvantage relative to teams that are willing to embrace outside technologies and products.
In the always-understated words of Linus Torvalds:
The NIH syndrome (Not Invented Here) is a disease.
When to build and when to buy
Here are five patterns to help make this critically important decision.
Pattern: Build if you can't buy.
Sometimes you have to build because the product you want just doesn't exist. We built our own just-in-time transcoder for Mux Video because another just-in-time transcoder didn't exist. At my last company, Zencoder, we built our own optimized TS segmenter for HLS because an open-source one didn't exist.
Before you use this as a reason to build, however, ask yourself: instead of building, could I compromise and use something that already exists? Sometimes it's a good idea to embrace constraints and live with the best available option.
Pattern: Build when you can get a unique competitive advantage.
If something is unique, and important to your vision, it's a good candidate for building. For example, if your vision is to build a fundamentally better CDN, you probably don't want to just resell Akamai. If you want to start a 5-star restaurant, you probably don't want to hire the restaurant next door to cater for you.
Ask yourself: how do I want to differentiate from the competition? Differentiation requires you to do things differently - profound, I know. This might require building.
Pattern: Buy if it's undifferentiated
Jeff Bezos called this "undifferentiated heavy lifting" in the early days of AWS. From an ancient (2006) blog post:
Undifferentiated heavy lifting includes "server hosting, bandwidth management, contract negotiation, scaling and managing physical growth, dealing with the accumulated complexity of heterogeneous hardware, and coordinating the large teams needed to take care of each of these areas. Each area is a career unto itself, doing poorly in an area will cause the entrepreneur to fail, and yet doing a competent job at each one is simply the price of admission. Jeff noted that developers routinely spend 70% of their time doing this backend work. At Amazon we call this ensemble of challenges “muck.” Imagine some software developers forcing their way through waist-deep mud, and you’ll have a good idea of what he’s talking about."
Doing a bad job at undifferentiated work can kill you, but doing a great job at undifferentiated work doesn't really help. If you lose electricity, it's hard to run a server, but having the best darn electricity in the world doesn't make your servers faster.
Pattern: Buy if it gives you a better time-to-market.
My team could build the most amazing custom docs site. We could do amazing things with code samples, interactive examples, and auto-generated specs. And maybe someday we will. But for now, our Mux Video docs run on a third-party docs system - Readme.io - that is much better than what we could build ourselves in a short amount of time. Given the choice between spending weeks (or months) building a perfect, custom docs system, and spending a few hours integrating with a good third-party, we chose the latter.
Pattern: Buy if it's too much for your team.
No insult meant against your team - even the best teams in the world can't do everything.
Sometimes this is a matter of priorities. Chances are your badass engineering team doesn't want to build and maintain a CRM for your sales team. Not because they can't, but because you can't afford to allocate a team of engineers to the project in perpetuity.
But sometimes this is a matter of expertise. Delivering software over the internet is complex, and even the best engineers aren't experts at everything. Expertise isn't always needed; you don't need to be a specialist to build 80% of most applications. But sometimes, when facing a hard problem (like machine learning, security, data processing, or video), a specialist is needed.
The common thread
What ties these patterns together?
The answer is simple: differentiation. To succeed, you need to make something people want, and the things people want are usually things they don't already have. This means we all need to focus our limited energy on areas we can differentiate, and we need to conserve energy in other areas.
If you have to err, don't err on the side of building or buying. Err on the side of making customers happy, and make customers happy by giving them something unique.
