Technical Debt

What does technical debt mean?

Technical debt describes the additional effort that arises in the further development and operation of software because faster or simpler rather than sustainable solutions were chosen when it was built. As with a loan, speed is gained today and paid for later with interest: every further change takes longer until the debt is repaid through rework.

The term describes an economic fact, not a balance sheet item. Technical debt appears neither as a liability nor as a provision, but shows up in higher personnel costs, slower product development and higher operating risks. In financing rounds and company sales, it is assessed in technical due diligence, that is, in the review of source code, architecture and operations by investors or buyers. The results feed into valuation, the purchase agreement and integration planning.

Causes

• Deliberate shortcuts: a team implements a function in simplified form to meet a market deadline. This is legitimate if the decision is documented and the rework is planned, for example after a minimum viable product (MVP), the first deliberately simple version of a product.
• Unintended defects: lack of knowledge, time pressure without an explicit decision, or staff turnover. This debt is riskier because nobody has recorded it.
• Ageing: software libraries and operating systems become outdated even if nothing is changed in the company's own code. Components without vendor support no longer receive security updates.
• Growth: an architecture that was adequate for a hundred customers no longer holds at ten thousand. The debt here arises from changed requirements, not from mistakes.

Added to these are missing automated tests and patchy documentation. Both make every change more expensive because developers cannot reliably estimate its consequences.

Measurability

Technical debt cannot be expressed in a single figure. Its effects, measured over time, are meaningful:

• delivery frequency and lead time, that is, how often and how quickly finished changes go into operation,
• error rate after changes and recovery time after incidents,
• share of development capacity spent on bug fixing and workarounds,
• time for new developers to get up to speed,
• age of the components used and number of known security vulnerabilities.

Tools for automatic code analysis provide supplementary indications, for example on test coverage (the share of the code that automated tests check) and on complexity. Without context, however, they are of little informative value. If delivery frequency falls over months without the team having become smaller, that is a clearer warning signal than any analysis report.

Assessment in technical due diligence

Buyers and investors often engage specialised advisers for the technical review. They examine the source code and its change history, speak with the responsible developers, review architecture and security and analyse the components used for currency and licences (open source). The findings are ranked by severity and, where possible, quantified in person-months (working months of a full-time employee) and euros.

What matters is the classification. Debt in areas that hardly change costs little. Debt in core areas that the buyer wants to expand, or in security-relevant parts, weighs heavily. Sellers can anticipate part of the review by commissioning a technical review themselves before the sale process (vendor due diligence).

Investors in a financing round ask less about the purchase price than about the use of the new capital. If a large part of development capacity flows into repairs, the product grows more slowly than planned with the money raised. They therefore check whether the known debt is budgeted as an expense in the financial model and whether security risks or dependence on individual developers endanger growth.

Effect on purchase price and integration planning

Quantified remediation costs reduce the enterprise value because they burden future cash flows. In the DCF valuation (discounted cash flow), which derives the value from discounted future cash surpluses, they appear as additional investments or personnel costs. In valuations using multiples, where the value is derived from a multiple of an earnings measure, they appear as a discount. Buyers sometimes try to deduct deferred investments as debt-like items in the bridge from enterprise value to the purchase price of the shares (equity bridge). Critical findings such as open security vulnerabilities are often remedied before closing or, because they are known to the buyer, secured through a separate indemnity.

In integration planning, the buyer decides whether the product is developed further, transferred to its own platform or replaced. If it is to be replaced, much of the debt loses significance. If it is to grow, remediation and additional capacity belong in the budget of the first years.

Worked example

A software company employs 12 developers with average personnel costs of EUR 110,000 per person per year. Technical due diligence shows that 35% of development capacity goes into bug fixing and workarounds. The buyer considers 15% appropriate.

• Excess share: 35% minus 15% = 20 percentage points
• Capacity tied up: 12 × 20% = 2.4 full-time positions
• Ongoing additional costs, in effect the interest on the technical debt: 2.4 × EUR 110,000 = EUR 264,000 per year
• Remediation, that is, the repayment, as estimated by the reviewers: 3 developers over 18 months, so 3 × 1.5 × EUR 110,000 = EUR 495,000
• Payback: if the share then falls to 15%, the company saves EUR 264,000 per year. The remediation pays for itself after 495,000 divided by 264,000 = around 1.9 years, counted from its completion, that is, around 3.4 years after its start

The buyer can demand the EUR 495,000 as a discount or include it in its integration budget. Which solution is chosen is a matter of negotiation. A seller who knows the figures themselves and presents a remediation plan negotiates from the stronger position. In a financing round, the same calculation shows that around half a million euros of the new capital goes into remediation instead of new features.

Distinctions from related terms

• Tech stack: the technologies used. Technical debt describes not their choice but the state of their implementation.
• Software bug: a specific malfunction of the program. Technical debt often causes bugs but also exists in code that runs without errors.
• Deferred investments: the commercial umbrella term for necessary but postponed expenditure. Technical debt is one form of it in software development.

Common mistakes

• Wanting to rewrite everything. A complete redevelopment often takes considerably longer than planned and delivers no additional benefit to customers in the meantime.
• Not recording the debt. What is not documented is neither budgeted nor credibly explained in due diligence.
• Treating it as a purely technical topic. The trade-off between speed today and speed tomorrow is an entrepreneurial decision for the management.
• Cosmetics shortly before the transaction. Reviewers look at trends over twelve months and more; a short-term clean-up hardly changes these series.
• No fixed capacity for repayment. Without a regular share of development time for rework, the debt grows with every new feature.

Frequently asked questions

Does every software company have technical debt?

Yes. Every product that has grown contains places that would be built differently with today's knowledge. What matters is whether the debt is known, assessed and taken into account in planning.

How much capacity should be planned for paying it down?

A fixed share of development capacity is common, in practice often between 10 and 20%. More important than the exact rate is that the share is planned regularly and not cut at every deadline pressure.

How is technical debt presented to investors?

Openly and with a plan. An overview of the known debt with its effect on the business, the capacity planned and the metrics by which progress can be read is convincing.

Does technical debt always reduce the purchase price?

No. If it lies in areas that the buyer replaces anyway, it hardly matters. It affects the purchase price when it concerns core functions, security or the planned scaling.

The Roemer Capital view

For clients considering a sale in the coming years, Roemer Capital recommends continuously recording delivery frequency, error rate and the share of capacity spent on bug fixing. These series can no longer be improved shortly before a transaction, and buyers read the state of the product from them.

In preparing the sale, Roemer Capital translates the known technical debt, together with the development team, into person-months and euros. This way the figure comes from the seller and not first from the buyer's review report, and it can be built into the financial model as an investment plan.