The buyer finds technical debt after signing. During due diligence the team reads revenue, margin, churn and cohorts, and leaves the code for later. By then the price is fixed. The seller arrives with no number either: the system runs, tests pass, and nobody totaled the cost of keeping it standing.
Questions that stay off the list
Buyers ask about LTV, CAC, recurring revenue and renewal rate. Engineering questions never make the list: time from commit to production, bugs per month, how many people change the core system, when the core dependencies last moved.
All those answers exist and cost an afternoon. Git, the pipeline and the issue tracker already hold the data. Someone has to open them.
Five engineering questions for diligence
- Build and deploy time. How long from commit to production? Hours point to a healthy pipeline. Days point to an approval queue, manual testing and a person on the critical path of every release.
- Production bugs. How many incidents per month in the last 12 months, and which way does the line go? Mature systems hold a low, steady rate. A rising rate marks decay.
- Knowledge concentration. How many people change the core without asking for help? Fewer than three, and the buyer inherits a key-person risk that shows up on the first absence.
- Dependency age. When did the core packages last update? A package sitting for two years carries a known CVE and blocks a language upgrade for three sprints.
- Architecture documentation. Is there a diagram dated from last year? A Confluence page from 2022 describes the 2022 system.
Nicole Forsgren, Jez Humble and Gene Kim measured the link between software delivery performance and company performance in Accelerate (IT Revolution, 2018). The same numbers tell a buyer how much maintenance consumes each quarter.
Turning findings into a number
Add three estimates. Stabilize: fix vulnerabilities, update dependencies, cover missing tests. Scale: what changes so the system carries projected growth. Ignore: what happens if nothing changes, with downtime, data loss and exposure.
The total goes on the negotiation table. For legacy systems past ten years, it lands between 15% and 40% of the acquisition value.
Steve McConnell argues in Software Estimation (Microsoft Press, 2006) for a range with a best and worst case instead of a closed number. A range absorbs the discussion that starts once the work begins. A single number turns into a fight.
Three ways to close the gap
Price adjustment. The buyer subtracts the estimated cost of the debt from the acquisition value. It is the simplest route and it holds when the number comes from evidence anyone can check.
Post-closing obligations. The seller commits to specific items with a deadline and a penalty. It works when the team that created the debt stays after closing.
Escrow. Part of the payment stays held until the agreed items reach an acceptable level. It takes more setup and covers debt that depends on internal work.
The seller who measures before going to market
A technical audit before listing the company puts the problem on the table while there is still time to fix it. The seller fixes what is cheap, prices what is expensive, and walks into diligence holding the number. The buyer meets a team that already looked at itself and asks for a smaller discount.
