Technical debt in 2026: demand, review prices and repair costs

Technical debt used to be an engineers' complaint. In 2026 it is a line in the deal model. Buyers ask for it in the data room, bankers name technology review as the hardest part of diligence, and AI coding tools now write a large share of new code faster than most teams can review it.

This note looks at the market around that debt: how large the problem is by the most credible numbers available, how much buyers and sellers now look for it, what a review and a repair cost on the open market, and why the firm that finds the debt and the firm that fixes it should be kept apart, even when they work together. How we measure a single debt finding and put it into a price is a separate note: How technical debt is measured and put into a deal.

How large the problem is

There is no single reliable figure for technical debt, and some of the most quoted ones are older or narrower than they look. The numbers below are the ones we would put in front of a board, with their dates and their origin.

• Developers name it first. In the 2024 Stack Overflow Developer Survey, technical debt was the top frustration at work, named by 62% of developers.
• It has a national price tag. Accenture puts the cost of technical debt in the US at $2.41 trillion a year and the cost of fixing it at $1.52 trillion. The estimate comes from a 2022 study that Accenture restated in 2024, adding that leading companies now set aside about 15% of their IT budget for remediation.
• It takes a third of the budget in many firms. In Protiviti's 2023 survey of more than 1,000 technology leaders, companies spent on average 30% of their IT budgets on managing it.

Two cautions. The often repeated "40% of the IT budget" is a misreading of a 2020 McKinsey survey, which spoke of 20 to 40 percent of the value of the technology estate, not of annual spend. And vendor reports on code quality are useful for direction, but they are written by companies that sell the cure.

Why AI made it a deal question

The debt that buyers worried about five years ago was old code nobody wanted to touch. The new kind is young: code written quickly, often by an AI assistant, that works today and is hard to change tomorrow.

• In Sonar's January 2026 survey of more than 1,100 developers, AI accounted for 42% of committed code. 96% of developers did not fully trust it, and only 48% said they always check it before it goes in.
• GitClear, which measures changes in code repositories, found that refactoring fell from about a quarter of changed lines in 2021 to under 10% in 2024, while copied blocks kept rising. Both are signs of code being added faster than it is tidied.
• Google's 2024 DORA report linked every 25% rise in AI adoption with an estimated 7.2% drop in delivery stability.

None of this means AI-written code is bad. It means that a company can now build in a year what used to take three, and also build up three years of debt in one. Our note on AI-written code in due diligence covers how we read it in a review.

How much buyers look for it

Demand for technical review has grown on both sides of a deal, but the work done has not kept pace with the talk.

• In the SRS Acquiom and Mergermarket due diligence study of US investment bankers, 51% called technology diligence the single most burdensome part of the review.
• KPMG's 2025 technology M&A survey found that 66% of dealmakers discuss technical and AI debt when planning a deal, but only 33% prioritise investigating it before signing.
• Black Duck, which audits code in transactions, reported unpatched vulnerabilities in 97% of the deals it reviewed in 2025 and licence conflicts in 94%. That is a sample of deals where someone ordered an audit, not the whole market, but it shows what turns up when someone looks.

Public search data tells the same story from the outside. One trend tracker shows searches for "technical debt" up about 44% over two years, and searches for "AI due diligence", still small in number, up many times over. People who search are mostly engineers and founders. Buyers rarely search: they ask their advisers, and the advisers increasingly ask for a technical review.

The gap between the 66% and the 33% is where most surprises come from. A debt that nobody priced before signing is paid for after closing, out of the buyer's integration budget or the seller's escrow.

What a review costs

Large firms rarely publish prices for technical review. Smaller specialists increasingly do, which gives a fair picture of the open market. The figures below are from the providers' own pages, as published in 2025 and 2026.

What moves the price is scope, not deal size: the number of products, the size of the engineering team, the compliance regime and how much of the system has to be read rather than sampled. Good providers charge a fixed fee agreed before the work starts. One of them puts it plainly on its price page: never as a percentage of the deal. We agree, for the same reason we keep the review apart from the repair: a reviewer paid by outcome has a reason to find a particular outcome.

For a seller there is a cheaper first step. A short red-flag review of the questions a buyer will ask, done months before a sale, costs a fraction of a full diligence and shows whether a full one is worth commissioning. That is the purpose of our red-flag memo.

What a repair costs

Repair is harder to price than review, because it depends on what was found and how much of it has to be fixed before the deal rather than after. The public reference points are wide:

• Fixed-price rescue programmes for a production codebase are commonly quoted at $25,000 to $50,000, from about $15,000 for light cases and up to $100,000 for complex products, over four to eight weeks.
• Senior engineers from established outsourcing regions cost about $60 to $76 an hour in Latin America and Europe according to Accelerance's 2026 rate review, with rates falling year on year.
• Code quality tools that keep the debt visible after the repair cost little: from a few dozen dollars a month for a small codebase to about twenty to thirty euros per developer a month.

In our experience three things decide the bill more than the hourly rate. First, the order of the work: the debt that blocks a sale or exposes data comes first, the debt that only slows the team comes later. Second, the surface: a repair limited to the parts of the system a buyer will touch in the first year costs a fraction of a full clean-up. Third, the choice not to rewrite. A rewrite looks clean in a plan and rarely is in practice; most debt is paid down in steps on a live system.

One firm to find it and fix it

Many providers now sell both the review and the repair, and the conflict is obvious. As one industry review put it, a firm that sells post-close implementation has an incentive to find post-close implementation. Some firms refuse repair work for companies they assess. Others do both and disclose it. There is no professional standard that settles it.

Our answer is a separation that a buyer can check:

• The review stands alone. The Structure reviews, ranks and writes the plan, with costs as ranges that any competent team could deliver. The report does not depend on who does the work.
• Repair is a separate engagement. When a client wants it, our engineering partner PERETZ can do the work, under its own contract and price. The client is free to give it to anyone else.
• Repairs are checked by people who did not make them. Work done by PERETZ goes to a separate team of senior engineers who took no part in it, and they check it against the same evidence as any other team's work.
• The report says who made each fix. A buyer sees exactly which parts of the product our partner touched and can commission its own review of them. Our FAQ sets out the same rules.

The benefit for a seller is time. A review that finds a problem in month two and a team that can start on it in month three is the difference between a fixed issue in the data room and a price reduction in the term sheet.

What a seller can do six to twelve months before a sale

• Get the questions before the buyer does. A short review of the six layers a buyer will read shows which findings would change the price and which would only go into the plan.
• Fix what moves the price. Security and access, ownership of code and accounts, data handling and anything that blocks a buyer from running the product without the founders. Leave taste for later.
• Write down what you do not fix. A known debt with a cost range and a date in the plan reads very differently from the same debt discovered by the buyer.
• Keep the evidence. Each fix with its date, its author and how it was checked. That is what turns a repair into value in the data room.

Our exit readiness review is built around that sequence.

What to do next

If you are buying, ask for the technical debt register before the management presentation, and ask who checked it. If you are selling, start with the questions a buyer will ask and fix in order of what changes the price. In both cases, keep the firm that grades the work separate from the firm that does it, or make sure the report says who did what.

Questions