The great software debate: Buying vs building solutions

Build or buy?

In the world of software development, the "build or buy" question is one that companies must frequently face. When it comes to deciding whether to build a software solution in-house or purchase an existing tool, there are many factors to consider.

In this week's episode, we're joined by Kyle Rockman, Platform Engineering Lead at OpsLevel, to discuss how companies can develop a framework to approach the build vs. buy decision.

The decision to build or buy a software solution depends on a variety of factors, including the specific needs of the company, the available resources, and the ROI of each option. By taking a thoughtful and thorough approach to the build vs. buy decision, companies can make informed decisions that will set them up for success in the long run. 

Join as we discuss: 

• Forming a centralized location of all options
• The pros and cons of each open source and vendor solution 
• The ROI of buying vendor solutions compared to open source

Forming a centralized location of all options

The decision to build vs buy is not a light one — the wrong decision can land you with misaligned products, wasted resource investment and ultimately cost you more in the long run. That said, Kyle suggests that the best way to start on the path toward a good decision is to create a centralized location where all options exist for assessment.

“Just having a centralized location is the best because you can link it out to someone,” Kyle says. “Then inside of that document, you want a list of requirements, generally in importance order.”

This living location will provide you with a clear avenue for determining your requirements, which are bound to evolve as you assess additional tools. For example, while you may begin your search for a solution with a basic set of requirements, more features that you have to consider reveal themselves throughout the hunt for the perfect solution.

Some of these project features may be important enough that they become part of your requirements. Ensuring you have a singular location for all options creates the opportunity for stakeholders across departments to communicate in the same language, and on the same page.

In addition, Kyle emphasizes the importance of determining important stakeholders early in the process.

“Identify who needs to give approvals and who should weigh in. Do they have any requirements? Understand the problem you're trying to solve before deciding to buy or build.”

The pros and cons of each open source and vendor solution 

Before deciding to jump into a purchase agreement or build your own tool, you should explore your options. Kyle and his team test several tools before committing to one. Within each tool, there will be several pros and cons to weigh and decide which works best for the specific solution you’re seeking.

These pros and cons can typically be broken down into two categories: impact and investment.

You have to weigh the cost and benefits of implementing or building a tool. When assessing a vendor, ensure that the cost of implementation makes sense on both a monetary scale and a resource investment scale. While some solutions may appear to be more affordable than others, they can often come with a long-tail cost of maintenance and management.

Likewise, building a tailored tool may be ideal, but the resource investment of time from your engineering and development teams may be too great. 

Determine which options fulfill your needs while also offering the greatest ROI in the specific context of your existing problem. 

The ROI of buying vendor solutions compared to open source

Calculating ROI can be more complicated than assessing pricing. In addition, you have to account for ease of use and implementation, longevity, potential integrations and misalignments, adaptability and longevity. 

Another huge factor to look for when assessing vendor solutions: support.

When you choose to partner with a vendor by implementing their tools and solutions, you are ultimately at their mercy when it comes to functionality. If they are down, your integrated tool is down. When the product is a vital piece of your company, like documentation, downtime spells disaster.

And worse than downtime — downtime with zero support.

When partnering for a solution, consider the possibility of downtime, errors and maintenance issues that require human support. If the vendor doesn’t offer real-time support, the cost saving associated with their solution may not be worth it. 

Another factor of ROI that’s often overlooked is urgency. While building your own solution may offer a tool tailored to your specific needs, it also takes time and resources. If a quick or immediate solution is needed, building is often not the best way to go. While implementing a vendor solution still requires time, attention and team resources, the lift is often much less.

The solution required to solve your organization’s specific problem is unique to your situation. Only after properly weighing the pros and cons of buying and building can you make a decision that’s optimal for your team. But once a decision is made, Kyle says it’s important to reevaluate intermittently, especially as businesses grow and develop.

“Requirements change over time,” he says. “You might have to pull back and say, ‘I don't need this tool anymore,’ and reevaluate.” 

‍

Need more insight into deciding whether to build or buy? Listen to the full episode to learn more about how OpsLevel has made those decisions over time and what you can take from our lessons learned.

‍