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

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.

  • “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.

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.

  • “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.

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.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Gina Trapani

Technology, culture, representation, and self-improvement. Once upon a time I started Lifehacker.