Every technical debt conversation seems to begin the same way. Engineers describe a codebase that is hard to change. Product points to a roadmap that is already late. A founder asks how many sprints it will take to "clean everything up."
That framing almost guarantees a bad decision.
Cleanup sounds finite: remove the mess, get the code clean, and return to normal work. Software does not work that way. Customers change. Markets change. Teams change. The code keeps changing with them. So the question is whether fixing debt is a better use of the team's time than everything else it could do.
Technical debt is not primarily a code-quality problem. It is a decision about where the company should invest its next dollar and its next engineering hour.
Waiting is holding an asset
Debt is useful when it buys something more valuable than it costs. Technical debt works the same way. A startup may accept a manual process, a tightly coupled module, or an architecture that will not support ten times the current traffic because that growth may never happen. Shipping sooner may buy customer learning, revenue, or another funding round.
This is the economic argument behind YAGNI. As Kent Beck recently explained, "You Aren't Gonna Need It" was never about saving the effort of writing code. It is about committing to a design before you have the information you need.
Building for a predicted future has two costs. The first is lost optionality. When you design for a future feature, customer, or scale problem, you give up the option to wait and learn. Even if your prediction is right, you committed earlier than needed. If it is wrong, you pay again to change or remove the design.
The second is net present value. A design built today for a feature due in three months brings the cost forward and delays the return. Suppose doing something "right" costs $100,000 today. A narrower solution costs $50,000 now and another $100,000 to replace two years later. The narrow solution looks wasteful if you only compare engineering costs. But $50,000 today may be runway the company cannot recover. It may fund the experiment that tells you whether the product needs to scale at all. Two years later, the same $100,000 may be a much smaller share of revenue or capital.
AI does not remove either cost. It can generate the framework or service almost for free, which makes building ahead more tempting. But cheap code is not a cheap commitment. The company still gives up options, maintains more code, delays other work, and may understand less of the system it now owns.
The value of waiting is not the code you avoid writing. It is the option to make a better decision once reality has supplied more information.
The narrower solution only makes sense when the company understands the debt, can replace it later, and gets enough value from waiting. Unplanned debt is usually negligence. Deliberate debt can be strategy.
What the debt costs
Financial debt becomes dangerous when interest leaves no money to invest. Technical debt becomes dangerous when its cost leaves no time to change the product.
That interest rarely appears as a line item called "technical debt." It appears as:
- Features that require changes across five unrelated systems.
- Deployments that need a senior engineer and a maintenance window.
- Incidents caused by the same frequently changed components.
- Cloud bills that grow faster than customer usage.
- Customer-success workarounds that silently consume engineering time every sprint.
- Deals blocked by security, compliance, performance, or integration limitations.
An ugly module that has not changed in three years may cost almost nothing. A clean service touched by six teams every week may cost a fortune. Code-smell inventories and "percentage of debt" dashboards miss this. They measure what engineers can see, not what the business pays for.
I treat the technical roadmap as a portfolio. A team can spend its time on four kinds of work:
Product
Features, experiments, new use cases, and anything else customers will pay for.
Scale
Work that lets the product handle more customers, transactions, integrations, or complexity.
Risk
Work that reduces the chance or cost of outages, security incidents, compliance failures, and lost trust.
Speed
Automation, observability, internal tools, and other work that makes the next change cheaper or faster.
Most companies spend too much on the first category because features are visible and always have a sponsor. Everything else gets dumped into "tech debt." A security hole, a scaling limit, a flaky deployment pipeline, and an engineer's dislike of an old framework end up competing as if they were the same problem.
Naming the result changes the conversation. "Refactor the billing service" describes work. "Cut the time needed for a pricing experiment from three weeks to two days" describes a return. Founders can compare that return with a feature.
How I decide what to fix
For each piece of debt, I ask five questions.
- What does it cost now? Count delays, incidents, manual work, lost deals, cloud spend, and cognitive load. Ignore problems that exist only in theory.
- How quickly is that cost growing? Debt in a stable component and debt in the fastest-changing part of the product have different interest rates.
- When does it become too expensive or risky? Name the customer, financial, operational, or regulatory limit that forces action.
- Can we reverse the decision? A throwaway internal tool is different from a data model used by every workflow or a vendor that owns your core data.
- What will we delay to fix it? Name the feature, experiment, customer, or runway you are giving up.
This does not produce a universal debt ratio or a rule that says "reserve 20% of every sprint." Fixed allocations ignore context. A startup searching for product-market fit and a regulated scale-up should not make the same choices. The same company may make a different choice after signing a large enterprise customer.
Debt moves up the list when:
- It repeatedly delays work tied to revenue or customer learning.
- Its cost grows because the affected area changes often.
- It creates a risk the company cannot afford.
- A growth milestone will soon push the system past its limit.
- A small investment removes recurring work across multiple teams.
- The window for a cheap, incremental fix is closing and the alternative will become a rewrite.
Sometimes waiting is the right decision. The code may be stable. The product assumption may still be unproven. A replacement may consume runway the company needs elsewhere. Or a planned product change may remove the debt on its own.
Both choices can be correct. "Always fix debt" is not a strategy. Neither is "move fast until it breaks." Strategy means knowing which limit matters now and which options the company needs later.
From technical debt to technical capital
Reducing friction has a ceiling. Once the codebase works well enough, another round of tidying brings little value.
Luca Rossi calls the alternative technical capital: engineering work that keeps paying back through cheaper, faster, or safer changes. A deployment platform, an experimentation system, an internal tool, a reusable integration layer, or better observability can remove debt and make the next piece of work easier.
Companies do not win by having the cleanest code. They win by learning and shipping faster without taking risks that can kill them.
The next time someone proposes a technical debt sprint, ask what it returns, what risk it removes, and what you will delay to fund it.
