Determining Whether You Should Buy or Build A Software Solution

More than a decade after Marc Andreesen talked about software eating the world, we continue to see digital natives — and even mature companies who have moved to a digital-first strategy — consume more and more market share at an unimaginable pace. The companies that are winning today recognize that their best competitive advantage lies within technology and how quickly they can get it to market. 

As you struggle to move fast while balancing competing priorities and stakeholder opinions, we know that buying a solution can hold promise of one less thing to worry about. Before you go through months of negotiations and sign a multi-year contract, though, let’s get clear on the trade-offs to buying versus building software. 

The State of Software Development Today

Historically, building your own software required starting from scratch — a timely and costly investment — which meant it often made sense to look for out-of-the-box alternatives.

But software development isn’t what it used to be — and that’s a good thing. 

Software development has evolved in really interesting ways that have led to countless frameworks, libraries and services that can be easily integrated into a fully custom solution unique to your business.

Today, software development is more about putting the right blocks together rather than creating something completely new. (Think legos, not clay.) 

Of course, there are still times when buying a piece of software still might make the most business sense. So, how do you decide? 

Begin with Purpose-Based Alignment

Not to sound too nerdy over here, but we typically start with the Purpose-Based Alignment Model by Nick Nickolaisen. In this model, you chart a possible solution’s opportunity for market differentiation against how mission critical it is for your organization. 

If a solution is falling into the top right quadrant (differentiating), it has the possibility of creating a competitive advantage for your organization — and you should really build this internally. 

Looking at the top left quadrant where something is highly differentiating but not mission critical, that’s when you might consider partnering with an outside company (we might know some people who can help.) 

Alternatively, if something is highly critical but not a market differentiator and there are already solutions in the marketplace that’d do the job, this is when we’d suggest looking to purchase a solution. 

And finally, if it’s not mission critical or a differentiator… well, those are just best left to die alone or get knocked out for the lowest cost. 

Determine If Customizations Are Needed

Another way to think about it is related to the level of customization you would need to make a pre-built solution work. 

If you can use an existing piece of software straight out-of-the-box without forsaking any of your business or customers’ needs, that’s great and buying a solution makes a lot of sense. These tend to be the solutions that help an organization run smoothly — accounting software, CRMs, marketing automation and the like.

When you’re needing a solution to facilitate unique business workflows, that’s when building tends to make more sense. You’ll be able to control the feature set, influence priorities and have the power to determine how you scale for future needs and growth opportunities. Building your own solution is what enables you to create a competitive advantage through technology.

One of the worst case scenarios that we can possibly imagine is buying a solution and then trying to customize it by forking it — taking the original source code and creating an entirely new piece of software. You’ll be stuck with whatever version of the software you purchased — with no updates or new features ever again unless you build them yourself.

Consider These Factors Before You Decide

• Accurately estimate your time to first use. A reason that organizations often want to buy is because of a perception that it will be quicker to get up and running. While this might be true sometimes, it’s not always the case. Companies typically have to tread through a months-long (and sometimes even a year or more) effort to mediate multiple stakeholders’ opinions on requirements, assess vendors, onboard and customize a solution in order to get things up and running.
• Don’t fall into the feature trap. Enterprise software has a tendency to try and be all things to all people. Software companies add as many features as they can to increase their value proposition, but most of these features aren’t going to be its core competency and will fall short or be too much for what you really need — leaving you feeling like you’re paying for more than it’s worth. 
• Avoid accidental architecture. When you buy a lot of products, you will start to get overlap of all of the features you don’t actually need. This creates accidental architecture that is difficult to manage and complicates your entire technology ecosystem.
• Think About Your Team. If you have a team of engineers and you choose to buy software, you’re removing the need for what they’re really good at: solving problems. If team members are stuck simply maintaining purchased solutions, you run the risk of higher employee discontentment, or at worst, even losing your most highly skilled software engineers.

Making the decision to buy or build can be a tricky one with lots of opinions and preferences. If you can approach the decision with some of these factors in mind, though, you’ll be much less likely to find yourself in a situation you wish you could get out of. And, if you ever want an outside perspective as you leverage the purpose-based alignment framework, we’re here to help.