Codebase giving you Reagan era vibes? Don't freak out! Software Technical Debt 101

Disclaimer: Unless noted otherwise, views and analysis expressed here are the author's own and based on public sources. The article is intended for informational and entertainment purposes only. This is not financial advice. Please consult a professional for investment decisions.

*********************

Technical debt in software is like foregone capex in manufacturing. Obsolescence accumulates gradually over the years. And then boom! Suddenly you are left with a pile of scrap metal.  

Same as with the factories, though - for an untrained eye it is nigh on impossible to spot obsolete software assets. Especially in the deal’s initial - courting phase.  

The majority of our readers are dealmakers, who want to know how to mitigate technical debt in M&A context. To help you, below we list the 4 most common categories of technical debt, along with strategies for handling each:

1. Legacy tech stack

2. The “New Project” trap

3. Billing system debt 💵

4. Third-party agency dependence

For each category, we go over telltale signs of a problem; as well as prevention (pre closing) and remediation (post closing) strategies. We finish with practical 5 steps to avoid acquisition horror stories.

This article is part of our "Software Gym" series where we teach software acquirers to become better. And where do they all congregate IRL? Of course, at our Software Serial Acquirers Summit. The next one’s in London on 6 May. Get your ticket here.  

Hang on, we are not done with the ads yet. 

A reader who’s transitioning between a blue chip UK serial acquirer to setting up his own shop (funded with £20M in equity!) has asked to share this exciting job spec:

Founding M&A Associate - B2B Services Rollup - London

You will be working alongside the CEO who comes from a highly successful, brand-name B2B Services rollup. The company is progressing the first cohort of acquisitions. The right candidate is a highly motivated and resourceful self-starter. End-to-end M&A experience is highly desirable. This is a rare opportunity to join a new, funded rollup OUT OF THE GATE, and contribute to its long-term success in a quasi co-founder role. 

Interested? Apply here: https://lnkd.in/gM-NTfRv

Alright, back to technical debt! 

1. Legacy tech stack

This is THE most common form of technical debt. In fact, a fair few of Constellation Software acquisitions fall into this category.

Think very old code base built on out-of-date frameworks that are no longer supported. While the software may work flawlessly, failure risk increases over time. 

Practically speaking, having old and legacy code may prevent you from:

• Launching new features - forcing you to constantly find workarounds

• Hiring good developers - who wants to toil away on legacy code?

How to identify legacy code early in the due diligence process?

Inquire about:

• Back-end and front-end languages and frameworks

• Database systems

• Server / hosting setup

Yellow flags include old programming language versions, on-premises setups, and legacy languages that have lost popularity (e.g. Visual Basic, Delphi, Cobol and many others). For example, as of 2024, a staggering 62% of PHP-powered websites still relied on PHP 7, a version that lost support at the end of 2022​​​​.

How to mitigate?

Number one mitigant is negotiating hard on price. If the price is good, and you believe in the product, get the seller buy-in to reduce technical debt during the transition period.

To make this happen, allocate part of the purchase price as a technical debt holdback with specific release timelines. You will be surprised how hard sellers work to fix technical debt when the holdback represents a meaningful percentage of the total consideration!

Additionally, during tech DD, consider the following:

• DD scope should help you understand the size and scope required to resolve the tech debt. Is this a code rewrite or refactoring?

• Is there a system / architecture issue e.g. is multi- vs single-tenancy and hence is going to drive (a) higher recurring maintenance R&D and (b) relatively higher hosting cost 

• Vendor lock-in. Software that runs on e.g. Oracle cloud? Time-consuming and very expensive to move away from

• Companies could add in copy-left libraries and XSS issues

Finally, consider your investment time horizon. Perpetual owners like Constellation can afford to take on these projects. If you are a PE backed buy and build, your exit timeline is probably 3-5 years. Are you ready to absorb the impact? Or do you just pass the “hot potato” if the asset does not boost revenue or EBITDA quickly?

Further reading: No stone left unturned: how TechMiners approaches tech / product DD

2. The "New Project" trap

You have found a great product that customers love. The metrics are solid. The growth rate too. There’s a wrinkle though: the product looks kinda old school… Sure, Benson Boone (of the “Beautiful Things” fame) can pull off that 1970s glam rock / disco era look - but it is not for everyone. 

Now, the sellers are telling you that they have been working flat out on v2 over the last twelve months… it is ready to launch...right AFTER you close the deal. They promise revenue uplift. Swift customer migration. All of that is presumably achievable within the 3-month transition period they are so insistent on.

Beware! Big lift projects like these never finish on time. Even if the founder tells you their CTO is “best-in-class” and “always delivers on schedule”. Expect delays counted in years, not months.

How can you mitigate this?

Use the same approach as with technical debt. Link part of the consideration to project completion. If the sellers outright turn down the offer, you know they are bluffing.

3. Billing system debt

Today, Stripe reigns supreme among SaaS billing systems. But go back 10+ years, when many SaaS businesses were launched, the billing landscape looked very different. Most businesses never bothered to switch vendors. Some out for fear of upsetting the customers. Others took one look at Stripe’s early product and moved on. It is hard to believe now, but in the 2010s Stripe was pretty basic:  

• A simple API for accepting card payments

• No invoicing UI

• No subscriptions or dunning

• No taxes, no client portal, no invoice PDFs

• And definitely no automation or provisioning logic

I have lost count of seemingly legitimate software businesses that run on legacy invoicing / admin panels with 3rd party billing - or just invoices / credit card payments with proprietary invoicing tools.

Now, why is this problematic? For reasons such as:

Subscribe to Premium to read the rest.