Technical debt across a portfolio: how to size it and where to spend

Technical debt across a portfolio is sized by running one method on every company and comparing the results. The method produces three numbers per company: a debt score, the cost to reduce the debt in engineer-weeks, and the share of engineering time the debt is consuming today. The fund spends where the return on an engineer-week is largest, and the point of the comparison is that this is often a different company from the one with the worst score.

The single-company version of the method is described in the diligence guide's page on assessing technical debt, and this page does not repeat it. What changes at portfolio level is the need for the results to be comparable, and the need to decide where to spend.

Why can technical debt scores from different reviewers not be compared?

They cannot be compared because each reviewer scores against their own idea of what good looks like, and a portfolio has as many reviewers as it has diligence reports. One reviewer counts test coverage; another counts open security findings; a third describes the architecture in prose. Each report is useful on its own company and useless as a ranking.

The fix is one method, written down, applied by whoever does the work, with the same inputs for every company. The inputs should be things that can be counted rather than judged, so that two people running the method on the same company get the same score. A workable set:

Input	How it is counted	Why it matters
Test coverage of the modules that carry revenue	Percentage of lines in billing, ordering, authentication and the core product path that an automated test executes	Untested revenue code is where incidents cost money
Open security findings by severity	Count from a scan run the same way on every company	Comparable across companies because the scanner is the same
Dependency age	Share of third-party dependencies more than two major versions behind	Old dependencies are where the next forced upgrade comes from
Deployment effort	Engineer-hours from a merged change to production, measured on the last ten deployments	The cost of every future change
Single-person knowledge	Count of production systems only one engineer can deploy or repair	The risk the fund cannot see until that person leaves
Known rework backlog	Engineer-weeks the team itself estimates to fix what it knows is wrong	The team's own view, which is usually the most accurate

Each input is a number. The score is a weighted total, and the weights are the fund's choice, written once and kept fixed so the score means the same thing at entry and at exit.

Reveneau runs this method as a fixed-scope review across a portfolio, produces the three numbers per company from the same inputs, and writes an evaluation suite for the modules it then works on, so the fund can see the score move and can re-run the check itself. The pillar guide to technology after the deal sets the sizing among the four phases of post-deal work.

What are the three numbers per company?

The three numbers are the score, the cost to reduce it, and the share of engineering time the debt consumes now. They answer three different questions, and a fund needs all three.

The score answers "how bad is it". It is the weighted total of the inputs above. On its own it is a ranking and nothing more.

The cost to reduce it answers "what would it take". It is the engineer-weeks the team estimates to move each input to the fund's target, summed. The scaling engineering teams guide covers why that estimate should come from the team that will do the work rather than from a reviewer.

The share of engineering time consumed now answers "what is it costing today". It is the share of the last quarter's engineering hours that went to maintenance, incidents and rework rather than to new capability. Stripe's Developer Coefficient survey, published September 2018 from a survey of developers and executives across six countries, measured a mean of 17.3 hours per week on maintenance work such as debugging and refactoring out of a 41.1 hour week, with 13.5 hours attributed to technical debt and 3.8 to bad code. That is a survey mean across all companies, and a portfolio company's own number is what the method measures; Stripe's figure is the scale to expect if nobody has looked.

Where should the fund spend?

The fund should spend where the share of engineering time recovered per engineer-week of remediation is largest, and then check that answer against the investment case for each company.

The arithmetic is a ratio: the third number divided by the second. A company that spends 40 percent of its engineering time on maintenance and could halve that with 20 engineer-weeks of work returns more per week than a company at 60 percent that needs 200 weeks. The worst score is usually the second company, and the best spend is usually the first.

The check against the investment case is the other half. A company whose deal thesis is a product rebuild will replace its worst modules anyway, and remediating them first is money spent twice. A company whose thesis is buy-and-build needs its shared layer clean before the next add-on connects, whatever its overall score. Turning the diligence report into the first-year plan describes how the debt work is sequenced against the builds inside one company; at portfolio level, the same sequencing decides which companies get the budget this year.

Bain & Company's press release of 23 February 2026 says typical deals now need 10 to 12 percent average annual EBITDA growth to return 2.5x, against 5 percent in the previous era. Engineering time recovered from maintenance is engineering time available for the growth, which is why the third number is the one to optimise.

How should the score be reported?

The score should be reported as a table with one row per company, captured at entry and re-captured each year with the same method, so the fund can see the trend per company and the total across the portfolio.

Company	Score at entry	Score now	Cost to target (engineer-weeks)	Engineering time on maintenance now	Spend this year
A	72	58	30	28 percent	Yes
B	85	84	210	55 percent	No, rebuild planned
C	41	39	12	18 percent	No

The figures in that table are an illustration of the layout and carry no data. What matters is that every column is produced the same way for every row, and that the "score at entry" column never changes, because it is the number the exit story is measured against.

BCG's survey of 100 senior private equity investors, published 7 January 2026, found that 82 percent of firms track return on investment from digital initiatives while only 40 percent use formal digital-maturity scores and 11 percent explicitly link digital progress to exit narratives. The same survey found 40 percent of investors had experienced a valuation haircut of 5 percent or more from technology issues. A debt score captured at entry and shown falling at exit is a direct answer to a buyer's diligence, and it is one that 60 percent of funds in that survey could not give.

Reporting engineering progress to the fund carries the score into the quarterly format beside the four delivery measures.

Does AI-written code change the sizing?

AI-written code changes the sizing in one input: deployment effort and stability, which DORA measures directly. Google Cloud's announcement of the 2024 DORA report, on 22 October 2024, said that as AI adoption increased it was accompanied by an estimated 1.5 percent decrease in delivery throughput and a 7.2 percent reduction in delivery stability, and that 39 percent of respondents reported little to no trust in AI-generated code. The 2025 report, announced on 23 September 2025 from nearly 5,000 technology professionals, found a positive relationship between AI adoption and throughput, a continued negative relationship with stability, and 30 percent reporting little or no trust.

For the portfolio method, that means a company writing much of its code with AI should be scored on stability with extra care, because the survey pattern says stability is where the cost appears. It also means the remediation itself can be done faster with AI, provided each change is checked against an evaluation suite written from the specification, which is how the stability gap is closed. The AI-generated code to production guide holds the full argument and the security figures, and AI adoption in portfolio companies covers what the fund-level surveys say.

What should the operating partner have at the end of the exercise?

At the end of the exercise the operating partner should have four things:

• The method, written down, with its inputs, its weights and the target for each input.
• One row per company with the three numbers, produced from the same inputs.
• A spend decision per company for the year, with the ratio and the investment-case reason recorded.
• The entry scores frozen, so the exit comparison is against a number nobody can revise.

That is enough to defend the engineering budget at the fund level and to answer a buyer at exit. If the fund would rather have the sizing run and the remediation delivered by one team that takes the outcome, building with investors and their portfolio companies describes how we take that on.