To build or buy software: Ask these 5 questions first

fingers keyboard code hands programming
Credit: Thinkstock

Whether to build versus buy software is a common question, especially for CTOs, CIOs and technical leads working on high-tech products and services.

In a world of plentiful open source software, easily-accessible cloud computing resources, and high-productivity programming languages, the temptation to build is strong. Today’s colorful SaaS ecosystem is equally as enticing. But I’ve found that there are a handful questions to ask in every build-versus-buy scenario:

1. Who will be using the product the most?

Are they somewhat novice or highly technical? How easy will it be for them to use the product?

2. Is building this product the most unique thing your organization could be doing?

If it’s not, should you be spending your time doing the thing that is?

3. Are you committed to building it without cutting corners?

If that’s not your stance, you may want to reconsider.

4. Is there already a tool that does exactly what you need?

If the tool you’re considering purchasing doesn’t cover all of your bases, does it check enough boxes to make it worth the spend?

5. Can you afford to spare the resources?

Are you considering time spent on both building and maintenance, as well as the opportunity cost of not pursuing other projects?

Let’s take a simple example: server monitoring. There is certainly no shortage of open source monitoring tools on the market, ranging from Graphite (a great architecture) to Prometheus (an option from Google’s SRE book) to InfluxDB (a new contender in time series). An engineer could easily spend days or weeks evaluating these options, creating a big matrix of relative trade-offs, and eventually settling on one.

But, then—as every experienced tech lead knows—the real work begins. Merely selecting an open source server monitoring tool is only the tip of the iceberg. Now you need to configure its agents and dashboards; think through the project’s long-term viability; deal with its beta-level stability issues; and learn its quirky query language.

And the list goes on. This can be fun, but it can also be quite frustrating. Projects can drag on for weeks and months. That’s why I think the core questions above can help you determine whether you are up for the feat or better served by handing over the reins.

Within my small engineering organization, there were clear answers to the questions above when we were considering buying or building a server monitoring system.

1. Who will be using the product the most?

My DevOps and backend engineers would be the primary users for server monitoring tools.

2. Is building this product the most unique thing my organization could be doing?

No. Simply put, my engineers have other, more impactful things they could be doing. We do not need to be in the business of building a system for server monitoring…

3. Are we committed to building this without cutting corners?

We know that when it comes to maintaining reliable systems for our more than 700+ customers (who run some of the biggest sites on the internet), we can’t cut corners.

4. Are there already tools that do what we need?

In this instance, we looked at Datadog and New Relic for our primary monitoring needs. These tools were built for exactly the audience whose problems we were trying to solve.

5. Can we afford to divert staff attention to an internal build?

These tools work today, not in six months or one year. Yes, they cost us a few thousand dollars per month, but it means that my team can go back to focusing on the areas where they add the most unique value.

In the end, buying has its own unique advantages, as does building, and you have to make the call based on a number of factors. Building the thing you so direly need isn’t always an easy feat, but it can have a big payoff.

Just make sure that if you commit to doing it all on your own, you do not cut corners. If you do, you just may come to regret it later.

This article is published as part of the IDG Contributor Network. Want to Join?

The march toward exascale computers
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies