Skip to main content

Whether you’re leading a business unit or undertaking a home improvement project, we’re all familiar with the challenge of a “build vs. buy” decision. In general, it’s easier to buy a pre-built solution, but you can’t customize it. If you build your own, it can be exactly what you want, but it takes more time and effort. In the world of business software, it’s often more expensive up front to build a custom solution, but you won’t have ongoing licensing costs.

All that said, it’s nearly impossible to make an educated decision without fully understanding the problem at hand and knowing what your options truly are. Ultimately, the decision to buy or build comes down to three factors:

  • Cost (financial and opportunity)
  • Risk
  • Complexity

There are certainly build or buy decisions that are easy to make. Why would you build your own microwave, when you can purchase a microwave at a (relatively) nominal cost? As we move further down the complexity spectrum, however, the decision becomes much more challenging.

To illustrate this complexity, let’s consider an IT Director seeking to implement new functionality. Imagine you’re operating in an enterprise environment with defined Finance, HR, and Purchasing/Supply Chain departments. At this stage, you likely have an ERP system (or at least well-defined workflows and data exchange between departments). You will also have data dependencies and a number of downstream effects from implementing any new technology. You are tasked with implementing a new AP Automation tool to improve the speed of paying invoices from vendors. Moreover, your business requirements dictate that the tool needs to include Optical Character Recognition (OCR) functionality.  Should you build your new system from scratch or buy one “off-the-shelf” from someone else?

Assess the Cost

Now, let’s sketch out a grossly simplified build vs. buy decision tree. We probably don’t have an unlimited budget, so let’s consider cost first. Let’s begin by assessing the pre-packaged AP Automation tools — evaluating the potential buy options. We will need to calculate the monthly subscription or annual license cost for the lifecycle of the software. We’ll also have to map business requirements to the functionality that the software provides “out of the box.” Implementation will almost certainly not just be a flip of the switch, so let’s also include some labor costs. We may even need some customizations — or at least the business requirement mapping necessary for exception handling.

In contrast to buying an off-the-shelf application, the build scenario requires custom software development services. The benefit is that you will avoid pricey, on-going licensing costs. You’ve built the solution yourself, so you own it. At the same time, you have to consider the cost of custom development. This will either be the fee paid to a development company or the opportunity cost of using your own staff. If you do the work in-house, you will likely dedicate several months of your developers’ time to building the solution. This will shift their attention from supporting other components of your business.

Weigh the Risk

The next core consideration in your build vs. buy decision involves weighing both current and future risk. Again, the dependencies question rears its ugly head. If you are planning to change the rest of your application stack in the near future, what does that mean for your new AP Automation tool? Will you be on the hook for another year of licensing costs if you’re no longer using the software? Alternately, will your custom-built solution be able to integrate with a new set of financial applications?

The challenge is reaching a decision that considers both your present and future states. How critical is this functionality to the future of your business? If it’s a minor feature — or one that many companies need — there’s likely to be a “good-enough” off-the-shelf solution.

If, however, the needed functionality is unique or core to your operations, you will probably want to build custom software. For example, if you need to use proprietary calculations to make investment recommendations or manufacturing decisions, you’ll probably have to build something yourself. Likewise, if the functionality is part of your value proposition, you might not want to use a system that anyone else can just buy. In exploring your options, you’ll need to take an honest look at how much of this risk you’re willing to take on.

Manage Complexities

How complex will it be to implement a system that fulfills your business needs? Every business technology project includes some degree of complexity, from requirements documentation and design to testing, implementation, and ongoing maintenance. Buying a pre-built solution can reduce some of these complexities. After all, the work of designing, building, and testing the software has already been done. The challenge is that it was done without your specific needs in mind. That means you will need to adapt your business operations to fit the software as it was built. If you want to customize it to better meet your needs, you’ll have to add that work into your complexity calculation.

Conversely, building custom software involves a lot more up-front complexity — and active participation. Depending on your technology stack (and who you hire), it can take months or years to develop a custom solution. When followed successfully, however, the software development process balances structure with flexibility to create a solution to your business challenge. The end result is a system adapted to meet your needs and business processes, rather than one that you have to adapt to.

Note that if the business function is less complicated, that might still be a reason to build. If it’s simple to implement, why pay ongoing license costs when you can build something that easily pays for itself?

Are you experiencing a build vs. buy dilemma? Looking for a solution that gets you up and running in months, not years? We would love to start a conversation and help you explore your options.