Balancing build vs buy decisions in a post-boom world

The question of whether to build software in-house or rely on third-party vendors is more fraught than ever, as budgets come under scrutiny and internal teams get stretched after waves of layoffs.

Powering every corporation is a suite of enterprise software applications, from off-the-shelf staples like Microsoft Office and Adobe Photoshop, to highly specialized homegrown solutions.

As the software industry has grown to “eat the world”, more and more vendors aim to offer solutions to a wide variety of business requirements, reducing the need for cumbersome bespoke software, but that doesn’t mean the world’s biggest companies don’t still run on their own applications.

The resulting dilemma is the domain of engineering leaders everywhere: what to build and maintain, and what to buy and integrate?

What do we mean by build vs buy?

“The build vs buy question is one many companies find themselves debating,” says Jake Thiede, cofounder of the SaaS AI company InFLOWS AI. “Should we create or redirect internal IT resources to fully design, develop, integrate, and maintain software from the ground up? Or should we find a vendor who has something available today, either fully out-of-the-box or with some customization to fit the business objective?”

This seemingly simple decision is fraught with tradeoffs. “To me, build vs. buy is a reflection of a company’s DNA,” says Michał Kierul, CEO of Polish technology service provider INTechHouse. 

“Do you want to craft something tailored, or are you content with what’s readily available?”

Realistically, any project where you might consider building software in-house is going to be complex and specific enough that anything you might alternatively buy will require some customization. 

Ori Levi, the cofounder of Estimation Support, says “buy” doesn’t always do justice to the decision engineering leaders are actually having to make. “Buying does not always involve paying money in this context: generally, it is more about bringing in a product that is ready for use and building on top of it as required,” he says.

Particularly in a Software-as-a-Service (SaaS) scenario, buying may involve an ongoing relationship with a vendor, more than a one-and-done transaction. On the flip side, open-source software packages can provide a cost-free starting point for customization that can be either conducted in-house or developed by consultants.

What to consider when making a build vs buy decisions

There is a long list of considerations to factor in when making a build vs buy decision: Cost, quality, timeline, internal capacity and expertise, external dependencies, and long-term strategy considerations.

All of these are secondary to your overall business goals though. “If your focus is speed, you should buy everything that is not the core of your product, everything not containing your intellectual property. If your focus is cost saving and operational efficiency, you should build within your financial ability,” says Dmitry Graf, a software consultant and experienced engineering manager.

If you choose the build route, you’ll be dedicating a significant amount of company resources to writing software. That leads to some obvious questions, such as is this worth the investment? Are we a software company? Is this absolutely core to our business strategy? 

The fact is, it is often riskier to build something yourself than buy software from a specialist. The statistics on internal software projects aren’t definitive by any means, but most reports show a failure rate of about two in every three projects.

“Our practice shows time and time again that a great deal of money and effort can be saved by buying off-the-shelf, yet many leaders have not ever considered it,” Levi said “Looking at the available options in good faith goes a long way, costs comparatively little, and will likely provide you with valuable insight, even in case you do decide to build something in-house.”

Build vs. buy decision frameworks

When it comes to making that assessment, there are two well-established decision frameworks that can help guide your process.

Evgeny Sorokin, Chief Product Officer at the fintech firm Devexperts, recommends using Gartner’s Pace-Layered Application Strategy. Under this framework, organizations classify their software needs into three categories: 

• Systems of record, which manage critical data and process core transactions.
• Systems of differentiation, which are used in workflows that help companies set themselves apart from their competition.
• Systems of innovation, which represent customer-facing business models, systems, or apps.

Each of these layers may call for a different build vs buy strategy. For instance, a corporate database is a system of record that nearly every company would simply license from a vendor, rather than building in-house. A new customer-facing app, on the other hand, needs to have unique features to the company building it.

Then there is the MoSCoW framework, which divides features into “must have”, “should have”, “could have”, and “will not have (for now)” categories. For features and functionality that fall into the latter categories, organizations must choose whether to do without, or to settle for an off-the-shelf product that may not be their first choice.

The pros and cons of building in-house

There are two big advantages to building custom software in-house:

• Control. If you’re building something new, you get the final say on what the end product looks like. 
• Differentiation. If everyone in your industry is using the same off-the-shelf products, you’re all just keeping pace with one another, whereas successfully building custom software could give you a competitive edge.

The overwhelming disadvantage to building your own software is that it risks eating up resources, whether that is time, money, or institutional energy. 

“It diverts resources from your main business, takes time and money, and months or years later you will likely end up with something that is on all accounts worse than a comparable third-party solution,” says Levi. “I am being intentionally blunt because most people wave away the complexities of building and overemphasize the flaws in buying, when it would be a lot healthier for the business to be biased in the other direction.”

“You are fighting the odds, and if you don’t build fast enough, you will miss out on the benefits you could have gotten right away from buying something from a good partner,” Thiede says.

The pros and cons of buying software

As you might expect, the advantages and disadvantages of buying software in many ways mirror those of building. The pros of buying can be boiled down to two main advantages:

• Speed. Building a software tool from scratch will always be slower than buying one. While enterprise software rollouts aren’t as simple as downloading and installing Microsoft Word on your PC, they still tend to be much faster than a development process.
• Support. In-house software requires a team to support its users. All software must be maintained to keep it patched and fit for purpose, and this too would fall on your team’s shoulders for in-house software. By buying software, you shift this burden onto a partner who can focus on that full-time.

On the other hand, choosing to buy software has two primary disadvantages:

• Lack of flexibility. Off-the-shelf software by definition has not been designed with your specific business needs in mind. While most enterprise software can be customized to an extent, there are limits, and you may end up needing to sacrifice desired features or change your business processes or even goals to accommodate the software.
• Cost. In a world of software subscriptions, buying software can represent a growing slice of your budget as you come to rely on someone else’s products.

Vendors that work with you to meet your specific software goals can help balance the build vs. buy equation. “A good partnership can combine the best of both worlds,” says Kierul. “You get the efficiency of a ready-made solution, but with the right collaboration, it can be tailored to align with your vision.”

How tightening budgets affect the build vs. buy equation

As budgets tighten and layoffs mount at tech companies, the factors that go into buy vs. build decisions shift as organizations seek to focus their resources on their core competencies.

While the overall structure of decision-making has remained the same at most organizations, “what shifted during the last year were the thresholds,” Graf says. “When central banks increased base interest rates and VC funding got scarcer, startups tended to prioritize short-term gains and buy more than build, because it is usually faster and cheaper in the short term.”

Now there is a hybrid model emerging, blending the best of build and buy. “The rise of SaaS and the API economy offer highly customizable building blocks,” Sorokin says. “Companies are increasingly looking to buy and then customize software to meet their specific needs, rather than starting from scratch.” 

Even in the current climate, companies will continue to scramble for whatever advantage they can, even when that means bucking current trends. “I’ve seen companies pivot in ways I never imagined,” says Kierul. “Some are buying because they need quick solutions. Others are building because they believe in the long game. In my opinion, there’s no one-size-fits-all answer.”