When It Comes to Software, Should You Build or Buy?

There’s no right answer, but plenty of risks in both directions

Illustration by Stephen Carlson

When your company needs software to solve a problem — whether it’s a full-featured product, an API, or a low-level library — should you build it in-house or buy it off the shelf?

This is one of the first questions Postlight helps our clients answer when we discuss their business needs. These days, the software ecosystem is mature enough that there are almost always off-the-shelf options available that could accelerate (or hamstring) any project. As much as we all want to believe our business is special and has unique needs, the reality is that everyone is looking for that perfect CRM, CMS, API, project management tool, email and calendaring system, chat product, or library that their users, engineers, and key personnel will depend on day-to-day.

Over and over again, we see leaders fall prey to certain misconceptions. As you evaluate whether to build custom or go off-the-shelf, be aware of some of the common fallacies decision-makers lean into at first — and come to regret later.

The Fallacies of Building

Especially in engineering-driven organizations, the instinct is to build. Software engineers want to build software. They know they are going to maintain that software, which means they have an advantage when they created the entire system top to bottom, with no surprises or black boxes. They want to control their destiny (thus the entire stack), and building everything from the ground up seems like the way to do that.

However, starting from scratch is costly. It means basic functionality anyone would assume is there to start isn’t — it has to be built. Building software is hard, slow, rife with unexpected detours and use cases, and building custom runs the risk of users comparing off-the-shelf products to your in-house effort and seeing it as inferior.

When you’re thinking about building a custom system from the ground up, watch out for potentially misguided thinking, like:

• “The product we need doesn’t already exist. This is completely new and never been done before.” Are you absolutely sure? Do more research. If you’re unable to find a product whose core feature-set fulfills your needs, it’s possible a plugin or add-on to an existing system will.
• “We’re a special snowflake with unique needs.” Unless this software is at the very of core of what differentiates your business from everything else on the market, chances are your needs are not as unusual as you think.
• “Our team can do a better job at building this than anyone building off-the-shelf equivalents.” Perhaps, but probably not. If another product team has a major head start thinking about, building, and serving customers with an off-the-shelf solution, they have already solved problems that your team hasn’t even thought of yet.
• “We want to Build It Right front-to-back and we don’t want to take on someone else’s tech debt or bad product decisions.” This is a noble instinct, but avoid misallocating in-house resources to stuff that could be turnkey.
• “Building this simple thing will be easy and not take long.” Software is hard. Building software takes longer than you think. Sometimes the easier software looks from the outside, the more complex it is on the inside. And once it’s built, it needs maintenance and upgrades.

When you build custom software, you reinvent the wheel and you control and own it all. You get too much freedom to blue-sky every feature and bit of functionality, rather than leveraging what others have already learned and solved in the problem space. You’ll spend too much of your org’s time and budget building groundwork and basic functionality. You risk burning runway on parts of your system that don’t provide your business’s core value.

The Fallacies of Buying

In leaner organizations, where money, time, and resources are extra-tight, off-the-shelf tools are accelerators, and leveraging as many accelerators as possible is paramount. Whether the product is free and open source to be installed and run on your own stack, or commercial software as a service, off-the-shelf solutions will get you a lot of functionality fast and upfront. The key question is if it will support your business the way that you need it to for as long as you need it.

When you go off-the-shelf, make sure you know what you’re getting into, and beware of thinking things like:

• “We’ll set this up and forget it.” You’ll forget it until the product you chose sunsets features you depended on, your license expires or the subscription model changes, the API updates or goes down, the company pivots, the business model shifts, or the creators decide to focus their energies elsewhere and the software stops getting attention (including security updates or bugfixes).
• “Implementing this will require very little development effort.” Third-party integrations involve product and engineering work. It’s different work than building a greenfield product, but it is work.
• “We won’t need to allocate resources to maintain this because the software/subscription will do it for us.” Up to a point, this will be true. Your internal team won’t want anything to do with the off-the-shelf product’s upgrades and maintenance. But things will break, eventually. It will happen very infrequently, so when they do no one will remember how they troubleshot it the last time. Add-ons and plugins also add vendors and complexities and another layer of maintenance burden as well.
• “This will seamlessly fit into our stack.” Will it though? Forever? How about till the end of the year? When your stack changes, how much of a consideration will running the third-party software be?
• “It will be easy and obvious to see how and why this black box functions because there’s documentation or open source community or we’re paying for customer service.” Sometimes this will be true! And those times will be magical. But once in awhile, if you have a support contract, someone on your team is going to have to call customer service to report a complicated issue, and they’ll get escalated through a few levels of tech support. They’ll get different stories, need to try several workarounds, and until they get it resolved, they’ll sit on the phone listening to bad hold music desperately wishing they’d just built this thing themselves.

When you buy, you jumpstart your work by using what everyone else is using. But when you get software out of the box, you necessarily start thinking inside the box. Instead of starting with solving the business problem, your team starts solving for the system that’s in place. And that system can’t be changed easily because you don’t own it. Its future is at the mercy of its creators and owners, outside your organization.

Pick Your Poison

Ultimately, whether your org should build or buy depends on a constellation of factors: how integral the solution is to your businesses’ core value, how much or little you will need to control and innovate, what your talent picture, timeline, and budget looks like, and what your post-launch maintenance plan is.

There are gotchas on both sides— just make sure you plan for them.

Need help working through your org’s build versus buy exercise? We love this stuff. Get in touch: hello@postlight.com