This essay is part of Zero to Live. It's a collection of essays for non-technical founders, walking you through taking your idea from nothing to working software product. Learn more

Build vs. Buy

When should you build custom software vs. buying off the shelf solutions?

A classic tradeoff faced in early stage companies is "build vs. buy": when should you build custom, bespoke software vs. buying off the shelf solutions from third party vendors?

This is important. Choosing incorrectly can lead to months of wasted runway, or backed into a corner where the next feature needed suddenly involves a massive rewrite.

If you're a non-technical founder, this can be especially difficult. If you have devs on the team, how do you know if they are making the right choice?

Be Aware of the Biases

First let's recognize the biases at play here - if you're a developer, these are the things to watch for in yourself. If not, these are things to look for in your team.

Biased towards Building: Not-Invented-Here (NIH) Syndrome

Developers - especially on the junior side, but even veterans fall prey here - often suffer from Not Invented Here syndrome. And it's understandable - I catch myself doing this all the time. When you look at third party solutions, it's easy to see the occasional flaw or shortcoming and get frustrated.

"Why did they add that feature here?"

"These docs makes no sense"

"This would be trivial to build ourselves - there's nothing complicated here"

These reactions all flow from the same underlying attitude that drives lots of developers: we want to be masters of our craft. To write elegant, efficient code that solves exactly the problem at hand.

Third party solutions will never be as good as the imagined solution in your own head. You'll conveniently gloss over the inevitable bugs you'd ship, features you'd never get to, etc.

This attitude is dangerous in startups. What matters more than writing perfect code is buildinga product that ships. A product you can learn from and iterate on. "Good enough" is the mantra here.

Biased towards Buying: Avoiding the Ugly Work

Just as developers want to write beautiful code that solves tough problems, often times I find myself wanting to avoid the plumbing. A UI developer might view infrastructure as a boring plumbing problem. A devops engineer might hate getting bogged down in the fiddely bits about button colors and shadow offsets.

This is probably less common than Not-Invented-Here Syndrome, but it's stealthier. While NIH manifests as loud complaints about buying XYZ software, this bias to avoid the ugly work often shows up as calm, mature acknowledgements:

"Well, \$VENDOR does this far better than we could, might as well leave it to them"

"\$TECHNICAL_SKILL isn't really in our team's wheelhouse, better to outsource that to a vendor"

While these can be valid, meaningful responses, it might also be masking core weaknesses in your dev team's competencies, or a hesitancy to put the business objectives ahead of working on the more interesting tech.

Decision Criteria

There's no quick and easy rule of thumb for these build vs. buy decisions. But there are a few contributing factors worth weighing as part of the decision making process:

Is your primary resource constraint time? Buy.

If you're a typical venture-backed startup that has raised an institutional round - you likely are cash-rich but time-poor. Your runway is your significant constraint, and if spending a bit of cash helps you get to product-market fit, revenue, and profit faster, it's well worth it. Consider buying.

But if your bootstrapped or early enough that you haven't raised a significant round, you're in the opposite situation: you're cash-poor but time-rich. You can afford to spend a bit more time if it means you don't have to spend the cash right now. Consider building.

Is this a core competency or unique value prop for you? Build.

If the functionality you are considering is core to the business, either as a core value proposition that differentiates you from the competition, or as a competitive advantage that helps build a moat, that should drive you towards building.

Often this is most relevant if you are pushing technical boundaries. Building a new facial recognition service that is better than anything before? Designing a self-driving car? You probably will need to develop these skills in-house rather than relying on third party vendors for your core competencies.

But if this functionality is tangential to your core business, and doesn't really set you apart from the competition or build a better moat around your business, then buying is the better option. Don't waste time and resources building something that doesn't meaningfully move the needle on your core business.

Do you need to be highly flexible and nimble? Build (maybe).

This one is highly dependent on the buy options in your space, but the fundamental concern is essentially vendor lock-in.

If you buy a third party solution, you lose control over the functionality and roadmap of that solution. If you need to rapidly iterate on that functionality and experiment to find product-market fit - you could find yourself backed into a corner where the vendor doesn't support your use case any further.

On the other hand, if this functionality is secondary to your core value proposition and you won't be iterating on it rapidly - that's a great argument in favor of buying.

Do you need this ASAP? Buy.

Buying is almost universally faster than building. If you need this functionality in your product yesterday, than buying is likely the fastest path to get there.

But weigh carefully what it means to need it faster. Path dependence is a big deal in engineering, and you can end up kicking yourself a year later that you went with the penny-wise but pound-foolish buy option to save a little bit of time.

Is there significant ongoing maintenance? Buy (probably).

One of the most commonly misunderstood ideas in tech startups (especially by non-technical founders) is that every line of code is a liability, not an asset.

Code must be maintained. Indefinitely. There is no "finished" point. It's never "done".

But some kinds of code introduce more or less maintenance liability than others.

Want to add commenting functionality to your app? Congrats, now you need to maintain a list of profanity that isn't allowed, along with potential machine learning algorithms to scan for malicious posts, spamming, etc. Or you could outsource this ongoing effort to a vendor and not worry about it again.

Example: adding community to Crash

At Crash, we wanted to introduce a community element to users of our platform. Building some kind of chat or discussion forum is one of those features that seems deceptively simple at first, but rapidly turns into a hairy mess. Cross device notifications, multi-language support, access roles, mobile apps, ... it could have easily become a multi-month effort (buy).

But we knew that community features, while a great addition, were not the core value of our app. It was the icing on the cake (buy). Furthermore, we knew that we were probably not going to try to innovate there. Standard community features would be more than enough, and we'd be fine with whatever a good vendor might provide (buy).

So we ended up using a couple different solutions (Mighty Networks, and then Slack), all without needing to spend a single engineer's day on it.

Copyright 2021
Written by Dave Wasmer with