Technical Debt Triage: Decide What to Fix First and What to Leave
Build a simple technical debt register and scoring method so you fix the debt that slows the business and consciously ignore the rest.
This is for CTOs, engineering managers and founders who hear that the code is a mess but cannot tell which parts actually hurt. Without triage, debt work is either ignored until something breaks or becomes an endless rewrite wish list. This post gives you a debt register, a scoring method tied to business outcomes, a capacity rule you set yourself and a way to explain debt decisions to non-technical leadership in plain terms.
The founder asks why a simple change to the pricing page takes two weeks. The engineers explain that the pricing logic is copied in four places and nobody trusts the tests. They have been asking for a rewrite for months, but every sprint fills with customer requests. Meanwhile, two engineers have left, partly because working in that code felt hopeless.
Most teams discuss technical debt as a single vague complaint. Engineers want time to clean up, product wants features, and there is no shared list of what the debt is, what it costs or which pieces matter. The result is either no debt work at all, or a large rewrite that stalls halfway and leaves two systems to maintain.
A logistics SaaS in Gurugram had a long-running debate about rewriting its rate engine. The engineering manager instead asked each engineer to add specific debt items to a register with the business pain each caused. Scoring showed that the rate engine itself was fine, but duplicated tax and currency logic around it caused most bugs and slow changes. The team reserved a fixed share of each sprint and cleaned up that logic piece by piece while building planned features. Changes to pricing became quicker, the rewrite request faded, and leadership finally had a clear view of what debt existed and why some was left alone.
How much engineering time should go to technical debt?
There is no universal answer. Pick a share that leadership agrees to protect, review it quarterly and adjust based on whether bugs, incidents and slow changes in debt areas are improving. Consistency matters more than the exact figure.
How do I explain technical debt to a non-technical founder?
Translate each item into business terms: this area causes most billing bugs, or changes here take three times longer than elsewhere. Show the register with scores so they can see priorities and trade-offs rather than a general complaint.
When is a rewrite actually justified?
When the system cannot support a required capability, the technology is unsupported or insecure, and incremental improvement is clearly more expensive. Even then, replace it in stages behind a stable interface rather than switching everything at once.
Who should own the technical debt register?
An engineering manager or tech lead owns the register and the scoring process. Every engineer can add items, but one person makes sure it is reviewed, scored and connected to sprint planning.
Want this fixed in your business?
Send the workflow. You get a scope and a fixed price within two working days — or a straight answer that it isn't a fit.