Build vs. Buy – A Product Manager’s Guide to Not Building Things

As product leaders, it’s our job to know; you can’t build it all. You can’t say yes to every stakeholder or user request. Buying an off-the-shelf solution and integrating it can be a significant time and energy saver. “Build vs. buy” is deciding whether that’s a good idea.

Moving fast and staying lean are guiding principles for startups but building things takes time and resources. What you decide not to build can be as important as what you do build.

Sometimes you’ve got to find another way.

As a startup product leader, you’ll be making a lot of these decisions. You’ll consider features, security, compatibility, licensing, and plenty more. While plenty has been said about procurement, I’m focusing on the product-centric aspects and whether to build it or buy it.

Build for your core competency and consider buying the rest

The first point to consider is how the capability slots into your business strategy. Figuring this out will get you most of the way to a good outcome.

If it’s integral to your product’s core competency, you should likely be building the feature yourself. For anything tied to your core competency, you should feel confident that you’ll build a much better solution than you can buy. 

On the flip side, if the capability you’re looking for is a solved problem or a commodity, err on the side of buying. If you’re dealing with a solved problem, your resources are much better invested in solving novel problems – just ensure buying will save you time and money.

What if it’s not a core competency or a commodity? You’ll fall somewhere in the middle in many cases, but unless you’re building a core competency, try to buy the solution to your problems.

Building everything is rarely a good strategy

In product trade-offs, it’s rarely a question of if you can build it. Instead, it comes down to if you should. Here’s an approach to finding that answer.

Before any build vs buy decision, you need to be certain you’ve identified a problem worth solving. Since that’s core to every product decision, let’s take that as a given here.

Once you know the problem is worth solving, you have to figure out if your solution is better built or bought. 

1. Determine whether the value is worth the cost.

Start by estimating the cost to build it yourself and compare that against the cost of buying it. Is it cheaper to buy it than build it? Keep in mind, buying isn’t effortless. It takes time to assess, integrate, and support anything you buy off-the-shelf.

Always account for maintenance costs

The most common reason to look back on the decision to buy as a mistake is failing to account for the very real costs (and ongoing opportunity cost) of maintaining the software you’ve built. 

While we refer to it as build vs, buy, it’s more like build vs. buy and maintain.

Every feature or capability has a maintenance cost and that maintenance has an opportunity cost. It’s all too easy to leave those costs out of the decision-making process. Sometimes the maintenance cost alone makes buying a more appealing option.

2. Consider your opportunity cost

What else could you achieve by investing those same resources differently?

Say you had $10 and spent it on candy. The opportunity cost accounts for all the things you could have bought instead. Applying that to your product decisions, by building feature X this quarter, you’re deciding you won’t build features Y and Z. That makes features Y and Z  the opportunity cost of building feature X.

Building everything is rarely a good strategy. Many companies will take the route of building everything. The opportunity cost of building and maintaining all that software you could instead pull off the shelf is massive. When you look at the numbers objectively in a resource-constrained startup, it’s a tough strategy to justify.

Done sooner pays dividends

All else being equal, there’s tangible value in getting things done sooner. Holding all else equal, any value-add (or cost-reduction) is better to have sooner. If you have a feature that makes or saves you $10,000 a month, having it 3 months sooner will leave you $30,000 ahead.

Keep in mind this principle applies to any feature you’re building too. By rearranging your milestones to front-load value, you can leverage the same mechanics. That’s an article for another time, though.

You’ll often find that buying gets you up and running faster, but that’s not always the case. Sometimes you’ll find you can pull together a super lean MVP that quickly gets you up and running.

Consider all your options, and remember, you can iterate your way through the process. Sometimes it makes sense to buy first and build later. Other times, build a simplistic solution and buy something more sophisticated later.

Take the time to quantify and factor time-to-value into your decision-making process.

You’re often buying more than software

When your non-core need is someone else’s core business, you can capitalize on all their hard-earned lessons. Product discovery, incorporating customer feedback, and iterating takes a lot of time and effort. When buying someone else’s product, you get all that included on day one. They’ve made the missteps, gone down the dead-end streets, and tripped over the hidden obstacles.

Instead of relearning someone else’s lessons, build the things that are core to your business, and learn the lessons other people can’t and won’t.

Buying isn’t a silver bullet – proceed with caution

It might sound like I’m painting buying features as the panacea – that’s not the case. Buying has its downsides and pitfalls. Sometimes non-core capabilities built in-house even end up overshadowing the original product. That’s how we ended up with Flickr and Slack, which both started as video games.

Here are two key pitfalls to look out for:

1. Half-baked procurement

Doing a half-baked job when integrating a capability you’ve bought is an easy way to mess up a build vs. buy decision. If you’re buying, be sure to invest in integration, roll-out, and proper training. Generally, software won’t use itself, and if nobody’s using it, you’re probably not getting much value out of it.

2. Fitting a square peg in a round hole

You might find a solution that’s close to what you need but not quite the right fit. Sometimes it’s smart to find something that patches the need and allows you to focus on more important work. Other times, the mismatch can cost more than doing it “right” the first time. Get into the habit of taking the time to play out the second and third-order effects of your decisions.