The practical answer
- Short answer
- Tech debt can eat 40% of a portfolio company's IT budget. Here's how an Operating Partner prices it, caps it, and protects the exit multiple.
- Best fit
- Industry: Private Equity. Function: Operations
- Operating path
- Technical Debt → Turnaround & Restructuring → Transaction Advisory Services
- Key metric
- 40% of IT Budgets Consumed by Tech Debt Maintenance (McKinsey, 2025)
The line item that wasn't in the model
Month seven post-close. The growth model said the platform would absorb its first bolt-on in a quarter; you're now five months in and the integration team is still reconciling two customer databases by hand. The roadmap you underwrote is frozen. And the VP of Engineering — the one you inherited, the one who seemed sharp in the management presentation — just used the word "rewrite" in a board meeting.
That word should make the hair on your neck stand up, because it means the asset you priced as a scalable SaaS engine is partly a maintenance operation wearing a growth costume. The market knows this happens. Research on acquisitions has found that something like 31% of acquired codebases carry severe technical debt, and weak technology diligence is a recurring thread in the well-documented reality that a large majority of deals miss their financial objectives (ACA Group, 2019). The mess was almost certainly there before you signed. It just didn't show up anywhere you were looking.
Here is the reframe that changes how you operate the company. Technical debt is not an IT issue you delegate to the CTO. By 2025, maintaining legacy systems and unpaid debt consumes as much as 40% of enterprise IT budgets (JetSoftPro, 2025) — and on a $10M engineering budget, that's $4M a year that funds neither a new feature, a new market, nor a single point of multiple expansion. It's interest on a loan that never amortizes, and unlike a real loan, it appears on no statement until it detonates: a breach, a botched integration, a buyer's diligence team walking away. You spent your career learning to read a leverage ratio. This is the same discipline pointed at a different liability. You don't need to read the code. You need to price it.
I don't ask portfolio CTOs whether the code is good. I ask what percentage of the engineering payroll is servicing interest instead of building the thing we're going to sell.
Turning the CTO's complaint into a number the IC will respect
When a portfolio CTO says "we have a lot of tech debt," what your investment committee hears is "give me a blank check." Your job is to convert that vibe into a defensible figure — the kind you'd put next to a working-capital adjustment. The first conversion is the easiest, because the cost is already sitting in payroll.
Developers in high-debt environments lose roughly a third of their time fighting old code instead of shipping new value; Forbes put the figure around 33% in its work on measuring and managing technical debt (Forbes, 2022). Run that against the org chart. A 40-engineer team at a fully loaded $200K a head is an $8M line; a third of it — call it $2.6M a year — is being spent to stand still. That is not a software metaphor. That is OPEX you are funding every month while the EBITDA bridge assumes those people are building the things that justify the entry price.
Stop asking "is the code good?" — it's the wrong question and you can't grade the answer. Ask the CTO for three numbers you can grade, on a Tuesday, without a single line of code in front of you:
- The maintenance ratio. What share of engineering hours this quarter was tagged to bugs, incidents, and keeping-the-lights-on versus net-new capability? North of 40% maintenance is a company servicing its debt, not growing.
- Cycle-time variance, not average. A team where a small feature ships in two days one week and three weeks the next isn't slow — it's brittle. The unpredictability is the tell that nobody fully understands the system anymore.
- Senior-engineer ramp. If a strong new hire needs four-plus months to safely change anything, the complexity tax is high enough to depress every future hiring decision.
Those three numbers turn "we have tech debt" into a dollar figure and a trend line — something the IC can underwrite. When you're ready to put it in front of them with rigor, our framework on quantifying technical debt in dollar value walks through how to present it as a financial exposure rather than an engineering grievance.
How to pay it down without freezing the company
Once the debt is priced, the inherited engineering leader will often propose the worst possible remedy: the Grand Rewrite. Twelve months, no new features, rebuild the platform clean. Veto it. In a PE-held company on a three-to-five-year clock, a rewrite is a near-guaranteed loss — the market moves faster than the rebuild, the team that knew the old system leaves halfway through, and you spend your hold period shipping nothing. You're not running a software charity. You're running a capital-allocation exercise with a sale date.
Run it like one, on three moves:
Ring-fence the legacy core
Freeze new feature work inside the worst of the monolith. Build everything new as separate modules around it, so the old system gets slowly starved and retired instead of nobly rebuilt. You keep velocity while the principal shrinks.
Set a fixed paydown rate
Dedicate a flat 20% of every engineering sprint to debt — and treat it like a debt covenant, not a nice-to-have that evaporates the first time sales screams about a feature. The instant the product leader says they can't spare it, that's your signal the company is already insolvent on velocity and is borrowing against the exit.
Refactor only what touches money
This is the move that separates an Operating Partner from a CTO. Don't fund "cleaner code." Fund the two modules that generate the most support tickets — that's a direct OPEX reduction — and the one that keeps the sales team from closing enterprise contracts — that's revenue you can show a buyer. If an engineer wants to refactor something that works because it offends their taste, the answer is no, and you don't apologize for it.
The destination isn't an elegant codebase. It's a transferable asset. When you take this company to market, the buyer's diligence team will not award you a single basis point for clean code — but unpriced, undocumented debt is exactly the kind of red flag that resets a valuation in the eleventh hour. Three years from now, the question that decides your multiple is simple: does the technology stop the next owner from buying? Fix the foundation, document it, and walk past the cosmetic stuff. If you want a read on how exposed your current portfolio is, that diligence guide is the right place to start.
