How technical debt is measured and put into a deal

Almost every technical review of a software company says the code has technical debt. It is true of nearly every product that has been in use for more than a couple of years, which is exactly why the sentence is worth so little. A buyer cannot price it, counsel cannot draft around it, and a seller cannot answer it except by saying that every company has some.

What a deal needs is narrower and harder to produce. Which part of the system, seen where, doing what to the business, and costing roughly how much to fix, on which assumptions. Without those four things, buyers use debt to argue the price down in general terms, sellers dismiss it in general terms, and neither side learns anything.

This is the reviewer's view of how debt is measured and carried into a transaction.

"The code has tech debt" is not a finding

Technical debt is the accumulated cost of past decisions that make a system harder to change. Many were sensible at the time: ship before a funding round, copy a module instead of generalizing it. The debt is not the decision. It is the extra cost every later change carries because of it.

That definition already shows why a general statement fails. Debt only has a price relative to a change someone wants to make. A messy reporting module nobody touches costs almost nothing. A tidy-looking billing module with no tests costs something on every release. The same debt can be harmless under one owner's plan and expensive under another's.

Our engineering partner PERETZ shows the same mechanism from the client's side of a project in The Hidden Technical Debt That Makes Website Redesigns More Expensive Than Planned: debt stays invisible while a system keeps working and surfaces the moment someone asks it to change. A deal is that moment for the whole company at once, because the buyer is paying for a product that will be asked to change after closing.

What a usable finding contains

Every finding in our report has the same parts, and debt findings are no exception:

• What exactly. A title that states a fact, not an opinion. "The application runs on a framework version past its end of security support" rather than "the stack is dated".
• Evidence. Where it was seen: the dependency manifest, the pipeline configuration, the vendor's published support dates, an interview. A reader should be able to tell a direct observation from something the team said.
• Impact. What it does to the business in plain words: security fixes no longer arrive, every release needs manual testing, a new integration takes a quarter instead of a month.
• Cost and time to fix. A range in money and calendar time, with the assumptions that produce the low and the high end.
• Severity and a recommendation. Rated on our severity scale, with a suggested route: before closing, in the first 100 days, in the first year, or when the team is next in that area.

A generic, fictional illustration of the shape:

The web framework is two major versions behind and past its end of security support. Layer: Code & architecture. Severity: High. Evidence: version read from the dependency manifest; support dates from the framework's published policy; a sample of modules shows three custom packages that do not exist for newer versions; no automated tests around checkout or login. Impact: newly found vulnerabilities in the framework will not be patched by its maintainers; questions from insurers and enterprise customers become harder to answer. Cost to fix: roughly 10 to 18 engineer weeks, assuming two engineers who know the framework, an upgrade one major version at a time, tests written first around the paths that carry money (included in the range), and no feature work in the same modules. The high end assumes two of the custom packages must be rewritten rather than replaced. Time: about four to six months of calendar time alongside normal work. Recommendation: start in the first 100 days; raise with counsel whether it belongs in price.

Nothing in it says the code is bad. It says what will cost money, why, and how much, and gives the other side something specific to check.

The debt that matters in a deal

Most of what engineers call debt never reaches a deal document, and should not. The kinds that do share one property: they change the cost, risk or speed of the plan the buyer is paying for. They sit mainly in two of our six layers, code and architecture, and infrastructure and cost, with some reaching into data and team.

Debt that is only taste

A reviewer also has to say what is not a finding. A language the buyer's team does not use, a monolith where an engineer would prefer services, naming conventions, an older but supported framework, code a new team would have written differently. None of these is debt in the deal sense unless it changes a cost the buyer can name. If the buyer will merge the product into its own platform, a technology mismatch is integration cost and belongs in that estimate. Otherwise it is preference, and treating it as debt gives the other side an easy way to discredit the report.

The test we apply is simple to state: if the item were left alone for a year, what would it cost the owner, in money, risk or speed? If the honest answer is nothing measurable, it stays out of the findings register, or appears as a Low item with no cost attached.

From finding to cost range and time line

A buyer does not need a full rewrite estimate to price debt. It needs bounded ranges for the findings that matter, built so the other side can follow them. That work is slow and careful.

Measure the surface, not the whole system

The reviewer sizes each item by counting what the fix has to touch. For a framework upgrade: how many major versions to cross, how many modules call the parts of the framework that change, how many custom or abandoned packages have no newer version. For copy-paste customizations: how many copies, how far they have drifted apart, how many customers depend on each. For a data model problem: how many tables and integrations read the field in question. Samples are read line by line to check the count.

The count is then turned into effort, in engineer weeks, by the kind of people the work needs. The range states who is assumed to do the work, and effort is priced at market rates for that kind of engineer. Release history is a check: a plan that assumes a much faster pace than the team has shown has to explain why.

Order the work before dating it

Calendar time is not effort divided by headcount. Fixes depend on each other. Tests around billing usually come before a framework upgrade, because without them nobody can tell whether the upgrade broke anything. The reviewer sets out that order, notes which items can run in parallel, and allows for the fact that the team still has to run the product while it fixes it.

State the assumptions and the exclusions

Every range carries its assumptions: the starting point, the team, what must hold for the low end, what pushes it to the high end. Where a range is wide, the report says why, often because a part of the system could not be seen or a third-party component has an unknown upgrade path. Costs that cannot be priced honestly, such as incidents that have not happened or legal exposure, stay out. A wide range with clear reasons is more useful in a negotiation than a narrow one nobody can defend.

Why a rewrite is rarely the right answer

When debt is heavy, "rebuild it" is the tempting recommendation. It is rarely the right one in a deal. A rewrite asks a team to reproduce years of business rules, edge cases and integrations, many of them undocumented, while the old system keeps running and customers keep asking for changes. Its cost is hard to bound, and it puts the product at risk exactly when a new owner wants it stable.

Incremental routes usually cost less and carry less risk: upgrade one version at a time, wrap the risky parts in tests before touching them, move deployments into a pipeline, replace modules one by one behind the existing interface, consolidate copied customizations into configuration. Each step leaves a working product behind it.

A rewrite makes sense in narrower cases: the platform itself is gone, the product is small enough that rebuilding is cheaper than understanding it, or the buyer will retire it into its own platform. Then the report prices migration rather than repair. Sellers should take the same lesson in reverse: a rewrite started shortly before a sale tends to read worse to a buyer than an older, stable stack with a clear plan.

Debt that changes price, and debt for the plan

Most debt does not belong in the price. It raises the cost of owning the product, and belongs in the first-year budget. We do not negotiate and give no valuation or legal advice; these are the distinctions a deal team and its counsel usually weigh.

Debt tends to be argued into price when several of these hold:

• The fix is needed whatever the buyer plans to do with the product, not because of a new feature or a different strategy.
• Its cost is large relative to the deal and can be estimated with stated assumptions.
• It affects something the price already assumes: margin, the ability to keep customers, security fixes, the cost of serving the next customers.
• The seller knew about it and did not disclose it or plan for it.

Debt tends to belong in the 100-day or first-year plan when it is the ordinary cost of a product of that age and stage, when the buyer's own plan will touch that area anyway, or when the fix is modest and ongoing. Missing tests, thin documentation and hand-built servers usually land here. The fix plan in our report sets them out with cost ranges and order.

Two cautions for counsel. Watch for double counting: a cost that has already reduced the price should not also sit in an escrow or a plan budget for the same work. And the buyer's plan matters: a finding that is High for a buyer who wants to scale the product fast may be Medium for one who plans to keep it steady, and the report should say which plan it rated against. The routes into terms are covered in our buyer's guide to technical due diligence.

How a seller can show debt honestly

Every buyer expects debt. What surprises them, and what tends to cost sellers, is debt they find on their own with no plan attached. The same framework upgrade reads very differently as a line in the seller's data room with a priced plan than as a discovery in the third week of exclusivity.

A seller who wants debt to stay a planning item rather than a price argument can do most of the work in advance:

• Keep a short debt register: the item, where it lives, what it does to the business, and what fixing it would take.
• Price the main items with assumptions, the way a reviewer would, so the buyer is checking a number rather than inventing one.
• Fix the cheap items that look worse than they are: secrets in the repository, a deployment only one person can run, a backup nobody has restored.
• Avoid starting a large migration shortly before a sale; finish or stabilize what is in flight.
• Put the register and plan in the technical section of the data room, consistent with what reviewers will find in the systems.

Ownership questions usually matter more than debt: a buyer can price an old framework but not a repository held by a former contractor. Our note on ownership gaps in a software acquisition covers that side. With months to spare, exit readiness builds the register and works through it. Closer to a sale, vendor due diligence gives buyers an independent reading of the debt with costs attached.

A checklist for reading debt in a report

Questions worth asking of any technical report before its debt findings reach a negotiation:

• Does each debt finding name a specific part of the system, or only a general quality?
• Is the evidence stated, and can you tell what was seen in systems from what was said in interviews?
• Is the business impact written in terms of money, risk or speed, rather than engineering preference?
• Does every cost come as a range, with who does the work, the starting point and what drives the high end?
• Is it clear which plan the findings were rated against, and would a different plan change them?
• Is each finding marked for a route: before closing, price, 100 days, first year, or when convenient?
• Could any cost be counted twice across price, escrow and the plan budget?
• Does the report say what it could not see, and how that widens the ranges?

What to do next

If you are buying, ask for debt findings with evidence, impact and cost ranges with assumptions, and share your plan for the product with the reviewer, because it decides which debt matters. Our technical due diligence is built that way: a findings register, a fix plan for the first 100 days and the first year, and points for counsel, at a fixed fee agreed in writing before we start. If time is short, a red-flag memo separates the debt that could move the price from the rest.

If you are selling, the work is the same from the other side: find the debt before the buyer does, price it honestly and show the plan. Neither job is quick, and neither is helped by a general statement that the code has debt.

Questions