build vs buy custom software
Authored by John Mezger

One of our most common tasks is helping clients decide whether to build vs. buy (custom software or COTS). When discussing application development, the first question we ask has nothing to do with budget, time frame, scope, or any number of qualifications. The first question is always, “How close will the product be to your core business output?”

Why is this so important? Core business value always has software requirements, either in terms of direct output or making that output more efficient. This is a departure from the traditional view that software is a cost of doing business.

The idea that software is key not only to business functions but to the business itself, is at the core of the build vs. buy deliberation. In this three-part series, we’ll help you break down this important decision by covering three main topics:

  • Why software is not a cost of doing business
  • The proximity of the software to your core business function
  • The real costs of custom software systems vs. COTS software

Build vs Buy – Custom software systems are not a business cost

This statement seems paradoxical, as it obviously costs money to create custom software. But more important than cost is the value that software adds to your enterprise. To better understand that, we have to take a step back and see how software has traditionally been brought to market and the impact of those decisions on how modern enterprises do business.

When software came to the enterprise, it was part of large, expensive mainframe deployments focused on back-office tasks tied to functions like MRP (Material Requirements Planning) and ledger activities. The efficiencies gained justified massive short-term costs, and the newness of the software itself masked the long-term ramifications of housing vertically built, highly complex systems.

Why were they constructed this way? Traditionally, to solve sweeping business problems—like making materials available for production and products are available for delivery, all with one system. These monolithic systems worked on the assumption of needs, rather than focusing on how singular business problems should be solved. Assumptions lead to contingencies lead to complexity. Complexity without context is the root cause of tightly coupled systems.

Largely, these delivered systems took years to plan for and deploy, and in the end, solved only part of a larger problem. However, this process set the standard for how business and IT interacted within the enterprise, one that’s still largely in play today.

How custom software can be your differentiator

The rise of the internet changed things: Core business functions got closer to external customers, and the software requirements for internal customers (i.e., employees using the technology) began to broaden at a rapid pace. Monolithic, waterfall-based methodologies could not keep pace with the rate and volume of expansion. Not only was go-to-market incredibly slow, but it was also incredibly expensive and did not deliver proportionate value. Enterprises turned increasingly to COTS software to quickly fill the gaps, viewing their software-based systems as non-customer-facing and therefore non-revenue-generating. Which is increasingly untrue.

The paradigm for business has shifted. Today, both customers and employees expect more from the technologies they interact with, and business units are demanding more value from their products. They are using technology to generate new products and business models and to completely disrupt industries. Companies that are able to drive value and disrupt markets are leveraging software to do so. How?

  • By understanding that customers—both internal and external—will increasingly interact with their products via software
  • By pursuing a minimal viable product: solving a small business problem first, then using agile methodologies to evolve iteratively
  • By recognizing that software derives its value from its ability to capture new customers and build efficiencies into the enterprise, not from its initial cost

When considering buying vs building custom software, forward-thinking businesses realize that a vendor-based solution leads not just to lock-in but to additional long-run costs (which we’ll cover in part 3). Does that mean that you should never choose COTS applications? Absolutely not. In the build vs buy debate, custom software is not ALWAYS the winner. And there are best-in-class COTS applications for many traditional business functions in areas such as ERP and CRM. However, modern businesses can separate themselves from the pack by looking at any core business activity as an opportunity to drive additional revenue and insights and choose custom software solutions that achieve that.
So with this understanding, we return to that all-important first question: How close is your software to the business? Stay tuned for Part II, in which we’ll unpack the answer.

Looking for more reasons to build rather than buy? Read our Top 5 reasons to go custom for enterprise applications

Contact an expert