Build vs. Buy Your Technology: A Guide for Finance and Procurement Teams

Every company is now a software company. This may in the year 2023 sound like a cliché, but when you have legacy automotive companies attempting to reinvent themselves as software platforms on wheels, the tired turn of phrase carries some weight.

Yet while every company is now a software company, exactly what kind of software each company should build varies significantly based on its industry, size, history, geography, economic constraints, and a host of other factors. Which brings us to our own question in the finance and procurement world: when, if ever, should we build our technology vs. buy it from commercial off the shelf (COTS) vendors?

With the Cambrian explosion of fintech and procuretech vendors over the past several decades, it might seem obvious that the answer is usually, “Just buy it.” But with a recession now all but inevitable and tech stack fragmentation making companies wary of adding “yet another tool” to their software belts, the build vs. buy question is worth thoroughly evaluating.

So what are the factors you need to consider to make a successful build vs. buy decision for software? How do you reconcile the needs of your function with your company’s strategic plans and your IT group’s available resources? We break it down into a simple framework of five costs:

1. Economic Costs
2. Resource Costs
3. Opportunity Costs
4. Knowledge Costs
5. Innovation Costs

Why Build Tempts IT

Before getting into the decision itself, it’s worth asking why anyone is having this discussion in the first place.

Candidly, as a researcher who has observed the finance and procurement tech markets for a bit now, I was initially surprised to see how many companies consider building solutions when COTS alternatives abound. But the more I got into these discussions with not only finance and procurement leaders but also their IT colleagues, I started to understand at least where the temptation begins. It’s kind of like in Star Wars where they say that one negative emotion leads to the next, and eventually you lose it and become a Very Evil Bad Guy. Which in the corporate world looks approximately like this:

In all seriousness, build can seem to make sense on paper. The major temptations are:

• Avoid upfront costs. SaaS licenses and implementation fees frontload costs. When the economy (and thus cash) is tight, letting go of capital feels dangerous, especially when you have IT resources you’re already paying.
• Get a unique solution. Instead of having to configure or customize a COTS solution, you can eventually get exactly what you want, specific to your industry and company.
• Integrate all of your data. It’s no secret that some vendors don’t play nicely with others. If you have a highly fragmented tech stack (e.g., multiple ERP systems from acquisitions) and need to integrate disparate data sources, taking responsibility for the data internally can feel more coherent.
• Control security. If you’re in a business with proprietary or sensitive information, putting your data in a public cloud or in a cloud service operated by a competitor (<cough>AWS for any retail business</cough>) does not make sense.
• Competitive advantage. Sometimes building allows IT to create a product that aligns with other products being sold or to build a new business. This is rare but worth considering.

It’s important, however, to interrogate each of these temptations. While they make sense on the surface, these urges don’t always satisfy when a company fully embraces the Build Side.

5 Factors to Consider in a Build vs. Buy Software Decision

As a finance or procurement leader, you’re not striving to save the galaxy. You’re working to help your business succeed, and the most potent force you can manipulate is spend.

When evaluating a build vs buy decision for software, you need to approach the problem in terms of costs. There are, of course, real hard costs that you can measure, but there are also costs on strategic, operational, and tactical levels that you must weigh with your fellow executives, especially IT leaders.

1. Economic Costs

SaaS solutions include license fees, implementation fees, and support/maintenance fees. Building software costs money, too, but in a less transparent way. Custom builds are not free; rather, their cost comes from the diversion of IT resources away from other potential builds.

To make the assessment correctly, everyone needs to get on the same page by performing a total cost of ownership (TCO) or total cost of acquisition (TCA) analysis. And when most companies do this, they come to a stark conclusion: builds almost always cost more than expected.

Remember that a software life cycle can last as long as 7 to 8 years. During that time, there are both upfront implementation costs and ongoing maintenance costs. While the sticker price of a COTS solution can cause heartburn, this pain subsides over time, given that 70% of software costs occur after implementation, according to Mark Lutchen, former CIO of PwC. Because of this, “A rigorous lifecycle analysis that realistically estimates ongoing maintenance by in-house developers often tips the balance in favor of buying."

Software projects are also notoriously difficult to project and budget correctly. This is true inside the COTS vendor and it is true for your IT group. Longer internal design phases, opportunity costs from diverting developers, and additional hosting and maintenance costs add up over time.

Internal teams, though, are slower to deliver and harder to hold responsible for implementation hurdles. This all adds up: According to an analysis by the Standish Group, as the complexity of an internal IT project increases to a very large (“Grand”) build, the odds of success — that is, on time and on budget — dwindle to just 2%.

2. Resource Costs

Your business only has so many IT resources, and there are plenty of other things those people could be doing instead of building a finance/procurement system. So in your TCO/TCA analysis you also need to factor in the time costs associated with these resources and potential for churn. You also need to be honest about the scale of what exactly you’re trying to build and what it will take to maintain it, because if your company can’t find the IT talent it might need or loses key resources to the hyper-competitive software developer labor market, your model is going to break.

To be sure, these resource factors need to be considered with COTS solutions, too. No COTS solution is perfect for every business, and you will need to configure or adapt the baseline version of the software to your unique requirements. So consider this in your model, too. The amount of IT resources needed to help with setting up and maintaining integrations, for example, can vary depending on how much you’ve customized others systems (e.g., custom fields in ERP).

When you do a simple breakdown of the resource burden between build vs. buy, though, the advantages for buy are pretty obvious:

And by the way, unless you’re Google or Amazon or equivalent, you need to be honest about what you’re paying for IT talent. More likely than not, you are already overpaying. Google and Amazon are, too, but they are getting the best possible talent. If you’re not able to attract tier 1 software engineers to your company, you are both competing with the flood of other companies for rare tier 2 talent and trying to prevent them from leaving if they get bored.

3. Opportunity Costs

Not only do you need to assess what you need to pay to literally build the software, but you also need to assess the value of what else you could have built instead.

This is the heart of most arguments against building where COTS solutions exist. The idea is that you should only build software that delivers your business a unique competitive advantage; if not, you’re wasting time duplicating something that could be up and running faster than you’ll ever be able to build it.

Another way to think about this is whether the build effort will affect the top line or the bottom line more. If the build boosts revenue potentially, that’s something worth exploring, but only if you can’t partner to get there quickly. If the build mostly creates operational efficiencies or cost savings, the draw is weaker, unless there is truly no COTS alternative for the specific process or operational problem that has become too big to ignore.

The opportunity to build something unique can be tempting, but as Matt McLarty, Global Field CTO, MuleSoft, put it in an interview with VentureBeat:

“If you’re a bank, should you spend time trying to build better software hosting infrastructure than major cloud providers? Focus your build efforts on the core capabilities in your organization that create, deliver, and capture the value that drives your business, especially those that give you a competitive advantage.”

4. Knowledge Costs

In addition to the planning and building time your IT resources need for an internal project, there’s also the reality that your internal staff will not be experts on the problem they are trying to solve. They will have to conduct numerous interviews with people in your function and, if the solution in question touches many stakeholders, people in other functions or outside the company, as well.

This is an area where COTS vendors can differentiate themselves effectively if they are smart. The best vendors are not merely apps but true solutions, in that they provide a perspective on what the root causes of a business problem are and what the best way to solve that problem is. Either implementation partners or internal vendor advisors are great ways to access such expertise, with people who have seen the problem in multiple companies and know the history of how it is solved. Your own IT resources, in contrast, will more likely than not be learning about a business process for the first time and only getting the perspective of internal stakeholders on how the problem arose or the best way to solve it.

What’s more, implementation and internal advisory are not the only form of knowledge a COTS solution will provide. The vendor will also have other customers, and if the firm is mature enough it will even have a customer community for knowledge sharing and troubleshooting. This is its own opportunity-knowledge cost for a build effort, since internal developers will not have access to other IT teams who have contributed to a solution recently without additional effort.

5. Innovation Costs

If your internal IT team has delivered a build solution, they have only fought half the battle. Now they need to maintain or improve the solution over time.

If you’re in finance or procurement, there are likely plenty of other efforts attracting IT’s attention. So even if you manage to get your function’s desired technology built — which, to be clear, procurement specifically only gets the technology it desires 17% of the time, according to Gartner research — there will probably not be much appetite for adding new features frequently.

COTS solutions win out here because they need to innovate to retain customers and fend off competitors. Your vendor has a vested interest in continuous improvement, whereas the internal solution will age quickly. The major exception to this is if there is no equivalent COTS solution on the market. In this scenario, pursuing a build may be necessary as a bridge until a viable replacement comes around.

Speaking anecdotally, Zip not infrequently encounters intake management workarounds built by large enterprise organizations with the specific goal of unifying fragmented IT landscapes for purchase requests, cross-functional approvals, and streamlining vendor onboarding. Given that intake management was only added to the Gartner Hype Cycle for Sourcing and Procurement Solutions in August 2022, this makes sense — the market is still young compared with something like P2P.

The trouble with building in a market void is that it’s very hard to predict what future scalability requirements and use cases will be. As discussed with knowledge costs, your IT resources will have to become fast students of business processes they don’t know. And without the skills to build, maintain, and improve the newly built product, you are less likely to succeed the way a successful COTS deployment can.

Bring Balance to Your IT Planning

No one goes to the Build Side planning to become Darth Vader. But much like how the Star Wars movies were released — we all knew what was going to happen while watching the prequels — most businesses know what can happen when they build technology that they could also have bought. Costs and delivery timelines get blown, resources are strained and pulled off other projects, and potential insights and innovations are forgone in search of more internal control. Darth Vader didn’t care that he didn’t have the high ground, and yet he ended up incurring significant medical costs anyway. (I can’t imagine that personal Bacta tank he has to sit in periodically is covered by the Galactic Empire health plan.)

The answer here isn’t just to shut up and accept what COTS solutions offer. Instead, it’s to find balance by looking for flexibility, configurability, and empathy in a solution partner that gets your unique business and can demonstrate an aptitude for solving problems in the finance and procurement domain — ideally with reference-able customers to back it up.

In sum, look at a build vs. buy scenario for a finance or procurement solution with great caution. If the problem in question is related to your business model enough to create a unique and sustainable competitive advantage, or if the problem is so painful that you can’t wait for someone to develop a new solution, put in the work to determine the realistic costs from all five angles. Otherwise, prepare for another kind of trial — selecting the right vendor for your specific use case — so you can resolve your business problem in a reasonable trilogy vs. a rambling nine-film effort.

Enjoy this newsletter?

Sign up yourself if this was forwarded from a friend or colleague.

Need help with something? Hit reply to send us research questions or to say hello. We love to trade notes!

Interested in hearing more from Zip? Visit our website or sign up for company updates.

Note: By clicking subscribe you confirm that you have read and understood the Zip Privacy Notice that explains how we collect and use your personal information, and includes directions on opting out from our newsletter. If you have any questions, please reach out to privacy@ziphq.com.