How to Shortcut Build Versus Buy Decisions for Tech Solutions

If you’ve got problems, vendors have solutions. They even have solutions to problems you didn’t know you had, and they will be happy to sell them to you at a very unreasonable price. But let’s forget those kinds of solutions; let's consider the situation where you have a real problem that you need to solve and decide the best path forward.

The classic dilemma when dealing with technology solutions is whether to build or buy. There are pros and cons to both — building gives you more control and can be completed incrementally, but it takes longer and requires maintenance. Purchasing a solution is an immediate cost and may not provide the returns or results you expected. And what if you get locked in on a vendor that starts raising prices? Worse, what if they go out of business or have a major outage or security breach that impacts your business?

When teams wrestle with this decision, they often get stuck analyzing the options and go in circles, searching for the best path forward. At the same time, vendors feel obligated to support your decision process in less than healthy ways — by providing buying guides, short-term discounts and incentives, and sometimes even bait-and-switch pricing with sticker shock at renewal when it's too late to switch easily.

Building a comparison spreadsheet is an act of futility as you and your team make wild assumptions about the cost of building features, return on investment, and maintenance costs. Your guesses about the future and estimates of effort will be wrong.

I propose a model to break through this analysis and greatly simplify these decisions. Some decisions are “one-way doors,” and there’s no going back. Sometimes you have a “two-way door,” and you can always backtrack out. The build versus buy decision and resulting negotiation should limit one-way doors and expand two-way doors.

In modern software, a few essential elements should be part of any solution you consider. Is it secure and meets privacy expectations? Does it provide a reasonably intuitive user experience? Do you trust the company to deliver based on reference checks? Does it actually solve your problem?

Some questions separate one-way and two-way doors. Does the solution let you take out your data? Does it conform to standards for interfaces and integrations? Are there other established alternatives in the market?

Other questions to ask are about your organization and a solution's potential impact (regardless of whether you build or buy). Is this problem pervasive across the entire company or localized to a single team or business unit? Is it likely that leaders will have different needs to solve the problem, maybe because of their technology stack or preferences? Or will this solution create consistency and improve collaboration across teams?

Based on your understanding of the available standard solutions and the potential cross-company impact of the problem, you can easily see the right path.

Credit: Kit Merker

If the potential cross-company impact is low, the likelihood that you should invest in building something will also be low. This is the classic “stick to your core” advice that helps organizations focus and deliver what they do best. If a particular team thinks a solution will help them through a two-way door, they should pick it up and use it and not waste precious energy debating or hacking together a homegrown tool.

If the cross-company impact is high and there aren’t many established, standardized solutions that help you outrun your competition, by all means, develop something internally. If you believe it will genuinely enhance collaboration between teams and act as a long-term differentiator, then you really have no choice. Relying on another organization won’t set you apart and is too risky for this type of problem.

On the other hand, if the cross-company Impact is high, and the available solutions provide you a two-way door (open standards, easy migration, take your data), it would be foolish not to purchase and standardize on a market-leading solution for your company. The risks associated with securely and reliably running your own solution may be too high. You will not be able to keep up with the pace of innovation, and your maintenance and opportunity costs will quickly overshadow your ability to deliver new capabilities.

The same technology at different times for different companies leads to different answers. For example, when Google needed to differentiate its service, it ran fiber under the ocean and even installed atomic clocks in its data centers. That was a wise investment at the time, but now you can rent the cloud.

I hope this matrix will help end the toil of build vs. buy analysis and provide a shortcut to making the right decision. But don’t throw away your spreadsheets and comparison charts just yet, as they will help negotiate and build consensus around a decision. And remember — save your money if the problem you’re trying to solve is a niche with limited standard offerings and no significant cross-company impact. Consider trying a free or open-source solution, but don’t mandate consistency across the organization. There are bigger problems to solve and many solutions to consider.