Build or Buy? A Decision-Making Framework for Software Development Investments

Build vs. buy?

The decision between using commercial off-the-shelf (COTS) software vs. a custom solution built from scratch is neither easy nor straightforward.

In this post, we’ll discuss the benefits and drawbacks of off-the-shelf software and custom builds, when it makes sense to choose one over the other, and what factors should inform your decision.

Before we dig in, it’s worth noting that the “build vs. buy” decision is independent of the decision between on-premise hosting versus cloud or SaaS.

COTS

COTS (commercial off-the-shelf) software—commercially-produced software sold as a ready-to-use solution without the need for any end-user (in this case, developer) intervention.

Within the COTS decision, there are two options: build from scratch (not the same as custom software, by the way) or rent.

As 3Pillar’s Henry Martinez puts it, “there are “configurable” platforms that don’t require everything to be coded from scratch.

For instance, if you’re looking for a solution to support your e-commerce store, there are lots of marketing fulfillment places where you can send your prices, photos, descriptions, etc. Then, that company sets everything up and deals with the financial transactions while you focus on the shelf-and-ship side of things. The same is true for media streaming and other business models.”

Custom

Custom software is made to order and defined by your business requirements, customer needs, internal workflows.

However, they can get expensive, and you do need to invest a significant amount of time defining requirements—and later, waiting for developers to actually build the software.

Henry Martinez also notes that “in certain sectors such as banking, COTS is the de-facto choice for most organizations, due to the extremely high costs associated with compliance testing and software certification—especially if we’re talking about multinational banks.”

He adds, “the same goes for certain hospitality applications—especially things like casino management—a very high percentage of organizations opt for COTS over custom builds.”

It Doesn’t Necessarily Need to Be COTS vs. Custom Development

While the COTS software vs. custom build debate might have you believing otherwise, it’s important to understand that the two solutions aren’t mutually exclusive.

The reality is, both possibilities can coexist within the same software ecosystem.

For example, you might go with an out-of-the-box solution for simple tasks that aren’t part of your core business.

Then, you might invest in custom software for key business activities.

For example, if you’re an online retailer, you might go with COTS for things like accounting or email marketing but invest in custom inventory planning software and business intelligence or analytics tools designed specifically to keep track of the information most important to your business model.

When You Should Use COTS

• If your workflows aren’t fixed. If there’s some flexibility re: workflows, it might not be such a big deal to adapt internal processes to the product design—you’ll save a lot of money and can immediately start using the solution. If your workflows are inefficient, ill-defined, or problematic in some other way, COTS might be a better solution—at least until you start to get a sense of business requirements.
• You’re trying to improve tasks that aren’t part of your core business. COTS software may be your best option in cases where you’re trying to improve internal processes that aren’t part of your core business offering/unique value proposition (i.e. forecasting, receiving inventory, streamlining customer communications).
• If your COTS supplier is likely to stick around for the long haul. If you’ve evaluated your COTS supplier and their roadmaps extend far enough into the future that you won’t have to experience a sudden, forced migration to something else, COTS may be a good option—particularly if you’re operating in a complex regulatory environment.

When Custom is Your Best Bet

• If you can’t find a COTS solution that meets your business need(s). The biggest selling point of custom builds—they’re, well, custom. If you can’t find what you’re looking for, you can build the solution of your dreams.
  Starting with a general-purpose, open-source language makes it easy to build any feature or experience from scratch—and scale/modify/modernize as business requirements evolve.
• If your business builds and/or sells software. If your core business model is selling software, creating custom-built solutions allows you to create more value for your customers than assembling a feature suite users can find elsewhere.
  According to 3Pillar’s Jorge Gaona, “If your business model is ‘build’ software, you can either create a product (that will become COTS) or create a customized application. Those are the main options. If your business model is ‘sell’ software, then you can provide a lot of value by customizing an COTS (like ERP implementations)”
• If your business value hinges on really specific workflows. If you’re using COTS solutions, you’ll need to adapt at least some of your processes/create some workarounds based on how the product is designed.

With custom builds, your internal workflow informs the product design—allowing you to not only keep your existing processes intact, but improve on them/create even more value—whether that means eliminating errors, helping your teams be more productive, or eliminating friction in the customer experience.
[adinserter name=”Software-Development-eBook-Offer”]

Build vs. Buy Decision Criteria

Consider the Big-Picture

You can’t make this decision without a plan—a plan that covers everything from costs and IP to a potential migration strategy.

Here are a few things you’ll need to figure out ASAP:

• Financials. The financial plan, of course, is critically important—you’ll need to consider the trade-off between ongoing licensing fees and the sum of the initial costs associated with custom development and the ongoing expenses involved with sustaining those efforts. Chances are, your finance department will want to see these numbers early in the game, so keep that in mind.
• IP. Before you start building, you’ll want to make sure that you’re not infringing on anyone else’s patents.
• Migration. As Henry Martinez puts it, “Migration costs are extremely high. Some say this is “where CTOs go to die.” He says that companies should expect to see a surge in QA costs during this phase—especially if you’re planning to migrate while active—meaning, without any downtime/service interruptions.
• According to 3Pillar’s Rodolfo Carmona, “the most common issue I’ve seen is, when many companies try to migrate to a new framework without a clear vision of the future. Later on, they need to do a second migration in a very short time to correct their path. On our end, it’s hard to envision what features to add next—just from the technical side.”
  He adds, “if the business team isn’t involved in defining a complete vision for the future of a product, how can it be modified in the next five years? The result is, organizations end up making decisions based just on what’s currently implemented—switching solutions when it’s time to find something with better performance that’s easier to maintain.”
• Size up your talent pool. You’ll also need to consider your team’s existing skills and what they need to be able to do their jobs better/faster or focus on more valuable tasks. According to Cesar Gutierrez, “Learning curve of language, case studies about performance and security of the framework, the timeframe to deliver a project and the experience of the developers that will be involved in that process. Choosing a technology should not rely on personal experience but having the whole context in the picture to make the best decision for the client and the commitment we are signing on it.“

Finally, you’ll want to determine whether you need to gather any unique data in order to capture relevant, actionable insights. If so, are there any COTS providers that can help you capture the right information? Or is this something that requires a custom build?

Voice of the Customer

Business requirements must start with the customer. Henry Martinez recommends that organizations “start with the customer and get the requirements right. Let customer needs drive the infrastructure options rather than building the DevOps framework first, then working backward after learning your infrastructure constrains the customer experience.”

Functionality

COTS is limited in terms of functionality—as no matter how robust the solution, you’ll still need to work within parameters of someone else’s design.

Custom software can be built according to your specifications/tailored to specific tasks.
It’s important to get clear on what you’re trying to do.

“If we’re building software, we need to understand why we’re doing it. Is it performance? Scalability? A robust framework could do the job but could be slower than others. There are many points to evaluate here and are different for each project.”

According to Jorge Gaona, “even though you’re building a custom app, having a product focus (and the right partner for it) will help to get better results.”

Implementation

With custom software, it’s typically easier to install new features/update existing ones without interrupting service/ processes or losing core data.

As your company scales, it will be much easier to scale this type of software and change functionality.

While COTS software is designed to work out-of-the-box, you won’t get much value from your solution unless it integrates with your existing tech stack/data sources.

Because it’s not tailored to your needs, you might run into some trouble configuring out of the box solutions with your current systems—i.e., legacy applications, IoT devices, custom software, etc.

One of the core responsibilities associated with building a custom design is developing a solid technology roadmap, to avoid ending up with technical debt. The underlying components will need to keep up as the programming languages, operating systems, and browsers surrounding the applications evolve over time.

For example, you don’t want to end up with a Visual Basic app that you’ll need to beg developers to maintain post-2021. Instead, find a partner that understands the critical importance of adaptability and delivers this as part of their solution.

Time

COTS software is pretty much plug-and-play. It means that it definitely makes sense if you need an immediate solution. However, it’s important to think about whether COTS makes sense in the long run.

Keep in mind, working with a development team that follows mature Agile and DevOps practices means that the development process can go pretty fast—though it’s important to be realistic—it’ll probably take at least a few months to deploy the final product.

Sometimes, if you’re trying to prove a market exists – you’ll need to use COTS to do a proof-of-concept (PoC). And perhaps, you might even use out-of-the-box solutions to implement some of the initial elements of your minimum viable product (MVP) to minimize your time-to-first-revenue. Then, once that initial market validation/feasibility testing is done, you can start building out the custom solution—assuming all other factors line up.

Costs

COTS will pretty much always have a lower sticker price than custom builds. However, it’s important to consider the following so that you get a better sense of what you’ll be paying in the long run—both directly and indirectly.

• The total cost of ownership. Look at operating and installation costs. Custom software may cost you more upfront but COTS solutions often have higher service expenses—licensing, price per user, custom plans, additional training or ongoing support.
• Opportunity costs. The opportunity cost of using off-the-shelf solutions—custom builds might yield greater returns/create better experience for your customer.
• How much time you’re working with. If the “time to first revenue” is an important consideration, look at opportunity loss cost from delays in going custom vs. off-the-shelf. If you have something that is disruptive to your business sector, you don’t want to slow that down.

Final Thoughts

In the end, it’s not really a matter of choosing COTS software vs. a custom build. It’s about selecting the right set of tools for the job—one use case at a time.

[adinserter name=”Software-Development-Closing”]