Demystifying Technical Debt for Deals

Technical debt, or ‘tech debt’, represents the cost of accumulated development effort (or rework) that’s been deferred over time. The build-up of tech debt can pose a significant risk in a deal scenario, impacting scalability, performance, security, developer throughput and innovation. In a merger or acquisition, it’s important to understand the potential impact of tech debt on the value of a deal.

By Andrew Turner, Richard Douglas, Kevin Nguyen (US), Sian Matthews

Introduction: What is tech debt?

In any software or technology deal, there’s an enormous amount of value at stake

Due diligence processes exist so that investors can fully understand the deal they’re entering into, and the other party can receive a fair valuation for the assets that are changing hands. In a technology-based business, it’s important to evaluate software tech debt as part of this equation.

Tech debt represents the accumulated, often compounded cost of development work that’s been put off over time

This debt can build up for several reasons. For example, a business might expedite the process to deploy a new solution as fast as possible, or they might unconsciously rely on a niche or ageing programming language without a proper talent succession plan. We’ll explore more reasons in this article, but the point is that tech debt can present significant risks that can affect the valuation of a deal. It can also raise security and regulatory issues, affect scalability, and lead to significant unforeseen costs if not evaluated properly.

Here's an example to bring the idea to life

Imagine you’re in the market to buy a second-hand sports car. You’ve picked your favourite brand and decided on a model they released 10 years ago. You’re in touch with two private sellers.

The first seller can prove they’ve had the car serviced in line with the manufacturer’s recommendations, including annual oil changes and two dealer recalls to fix known issues. They’ve rotated and replaced the tyres, kept the car clean and dry in the garage, and even upgraded the electronics for better performance and fuel efficiency.

The second seller has done a couple of oil changes in their 10 years of ownership, but besides fuelling up, they didn’t do much else. They also had a couple of minor accidents—nothing major, they say—but they didn’t bother getting them repaired.

Which car would you spend your money on?

Clearly, car number two is likely to need extensive investment after you take it home. This is an example of tech debt. These hidden liabilities built up over years, as the original owner decided at various points not to invest in maintenance and repairs. The car might still be a great deal at the right price—just so long as you properly understand what you’re buying in advance.

Tech debt in software and technology businesses

Let’s go back to the subject at hand: technology businesses, and what buyers and sellers should think about during a deal. There’s a long list of what counts as tech debt, but here are 12 key items we start by looking at.

To some extent, beauty is in the eye of the beholder when it comes to coding. Scanning the source code will tell you how many thousands of lines of code (‘kLoC’) there are. You can check the percentage of bespoke vs ‘off the shelf’ code to get an idea of software quality. But you’ll still need to interpret the findings to find the ‘So what?’ from a deals perspective. For example, what’s actually being used and what’s defunct?

Well-written code is easy to read and straightforward to follow, which makes it easier to build on and adapt. Difficult code is harder to work with and follow, and therefore more expensive to maintain. This can be caused by poor code hygiene (such as leaving dead pieces of commented code around), unstructured code (or ‘spaghetti code’) and a lack of code documentation.

A blast from the vernacular past, but still relevant. Bloat can happen when progressive versions of software simply pile functionality and code on top of what’s already there, leading to loss of performance through higher consumption of resources for limited benefit. Or when the source code is unnecessarily long or complex for what’s needed, making it slow to execute and/or wasteful of resources.

Many platforms have been built and ‘tweaked’ over years or decades with a mix of coding languages and different versions of the same language. Over time, this becomes more and more difficult to manage. Which bits of the codebase do you need to update, when, and why? What’s the impact on new functionality?

Sometimes, we see archaic languages like COBOL, JSP or PROGRESS being used. Unfortunately, there’s a limited pool of people who know how to use these languages. They’re difficult to learn, expensive and can’t be adapted for modern deployment models.

We usually see this problem with older platforms that haven’t been properly maintained, or in businesses that have grown through bolt-on acquisitions. In both cases, the solution is to go back and upgrade or standardise the language mix.

Open source components are convenient, but they need to be monitored, tracked and updated to patch security flaws, just like any other programming language. As an aside, you also need to understand the IP licencing, given the possibility that you might not own all of your source code or might be required to contribute to the open source community.

20 or 30 years ago, what we now call ‘legacy’ applications were installed on a server in a chilled room somewhere in the office. Despite the prevalence of modern, microservices-based architecture, these monolithic apps are still commonly used. While it is possible to adapt them for today’s cloud infrastructure, it’s expensive and impractical to do so, particularly when it comes to scaling them up.

We looked at an education software business that was rolling out customer deployments using a cloud platform, but hadn’t re-engineered the source code. This meant that while the plan could be delivered, the infrastructure cost heavily impacted the margin because the business had to buy capacity in ‘blocks’ ahead of receiving revenue.

This is how usable your product is from the customer point of view. For a B2C product, we might ask: Is it intuitive to use? Are you asking more or less questions than your peers? Are you losing customers at crucial points, like in a software demo or at checkout?

While this is an area that’s somewhat subjective, there’s a usability component to any software build—both for customers and operators. Issues with UI and UX will slow you down and contribute to tech debt.

In the world of testing, risk management can get philosophical. Organisations weigh up failing fast vs failing safe, while others might choose to do the minimum necessary and deal with the consequences later. Some key questions to consider are:

Is the level of testing sufficient, or does it actually allow systemic build-up of tech debt?
Does the complexity of the technology mean that the testing and release process is overly difficult, unwieldy, or prone to error or rollback?
Is testing automated or could it potentially be?
Could you use a third party to test (at least in the short term), leaving all your resources to focus on development?
Is the release cadence in accordance with support policies and will you be able to get your customers to use the latest version?

If the business plan envisages growth in new country X, can the platform support that? Are there any localisation requirements (e.g. language, currency)? Do data residency requirements mean the infrastructure needs to be located differently? Does the system meet current regulatory needs or can it be adapted to comply with them? Will you need catch-up development to do this?

Skills and specialisms evolve alongside software languages. For example, Fortran and COBOL are two first-generation development languages that were developed in the 1950s. Today, it’s very difficult to find skilled people who can code in Fortran and COBOL, but they’re still in use. Niche issues like this can present an unexpected challenge for security and maintenance. So we consider them an example of tech debt, along with other team-related factors like cost and physical location.

We reviewed a legal services software business whose platform was based on Progress (AKA OpenEdge since 2020). Most of the core development team were approaching retirement age, and the business wasn’t able to find new team members at a commercially reasonable rate. This meant they had to consider an expensive refactoring of the platform core, or broaden the talent search globally along with the cost and operational implications that would bring.

Clearly, all these topics are related and play into one another. The picture can quickly become complex, and it can be difficult to know where to begin.

There’s always a time factor

Tech debt can be a ticking clock. Something that isn’t a significant problem today could quite easily become one in the near future or at investment exit if it’s not proactively addressed and monitored. If you evaluate your situation once a year and conclude there’s no pressing tech debt, this can lead to a false sense of security given the pace of tech change.

Some tech debt might be tolerable

As with broader risk appetite, there can be a difference of opinion between the business, the investor and their advisors on what should be tolerated and what’s unacceptable. What is deemed to be urgent debt might have immediate implications on a deal, while manageable debt might be addressed through business-as-usual activities.

There are no hard and fast rules on the right way to address tech debt. The answer is different depending on the situation and the organisations involved.

Examples of our work in this space

For a process automation vendor

Our client wanted to sunset some legacy (and difficult to support) applications and migrate resources supporting tech debt to lower-cost jurisdictions. We helped by reviewing the existing product set, underlying technology and associated tech ops, and created a structured 3-year plan to achieve the change. Our private equity client benefited from an EBITDA margin improvement of 3.1% (equating to c. €60m of deal value).

For a fashion retailer

Our client was planning to acquire a turnkey ecommerce platform and wider ecosystem to cover everything front-end UX to warehouse management and fulfilment. Our work quickly showed them that the in-house and third party components and functions were unsustainable, with significant amounts of tech debt that couldn’t easily be addressed, making the acquisition unsuitable for our client’s needs.

For a research and data analytics company

Our private equity client was looking to acquire an online research organisation with various platforms it had itself acquired over time. Our due diligence focused on understanding technical risk across the various code bases. We ran a software composition analysis code scan, reviewed architecture patterns, and evaluated system performance to understand the cost and effort required to remediate important platforms. The investment to fund the modernisation was partly offset by value creation savings found in other parts of the business.

See the true potential

In a deal scenario, whether you’re buying or selling a technology asset, it’s important to understand the inherent tech debt and its potential implications. Extensive tech debt, or an insouciant approach to managing it, will have significant implications for the future of the business. This is particularly true if the value of the asset is premised on its ongoing maintenance, extension, enhancement or integration to support future growth.

While we’ve been looking at this topic for over 10 years, it’s more relevant than ever today. Our latest CEO survey shows that technology is a focal point for organisational leaders.

56%

of CEOs believe that technological change will drive how their business creates value in the next three years.

39%

believe that time their company spends addressing technology issues is inefficient.

With the right technology due diligence, you’ll be able to understand which technology assets require attention and prioritisation, and be able to adjust valuations and future plans based on the potential increases in cost, time, complexity and effort.

If you’d like to discuss any of the issues raised in this article, or find out how you can maximise the deal value for your technology business or within your wider portfolio, please get in touch. PwC’s software platform and product team has an extensive track record in supporting investors and businesses in deals in the UK and across the globe.