Technical debt: rebuild or evolve? How to decide with facts
Technical debt is the accumulated cost of shortcuts taken in a piece of software, paid in time lost on every change. For leaders torn between rebuilding and evolving: the signals that show where it costs, a repair, repay or replace grid, and how to pay it down without stopping delivery.
Your product is three years old. Every new feature takes longer than the previous one, fixes break other things, and the developer who really knew it has left. Someone says the word “rebuild”. Someone else mentions the budget. You are in the middle, without the elements to decide.
Technical debt is the accumulated cost of shortcuts taken in a piece of software: code written fast, libraries never updated, tests put off until later. Like financial debt, it has a principal (what it would take to bring things up to standard) and interest (the time lost on every change until you do).
02
Which signals show where the interest is?
Debt cannot be seen in the code from a director's desk. It shows in symptoms. Four reliable signals you can observe without opening a file.
01
The same module comes back in every incident
Look at the fixes of the last six months. If a third concern the same area (payments, exports, synchronisation), that is where the debt costs. The rest holds.
02
A small request takes an unreasonable time
“Add a field to the form” should not take a week. When it does, it is not the field that costs, it is everything that has to be untangled to add it without breaking things.
03
The team is afraid to touch an area
When an engineer says “we do not touch that”, they are not talking about taste. They are talking about an area with no tests, no documentation, where every change is a gamble. It is a signal of high interest.
04
An expected evolution is blocked by the structure
Your users want multi-account, real time, bulk export, and the answer is “not with the current architecture”. It is the only case where rebuilding a module becomes an evolution, not a repayment.
03
Rebuild or evolve: how to decide?
The question is never “rebuild the product”. It is “for this module, this week, do we repair, repay, or replace?”. Three answers, and a grid to choose.
Three answers for a module that costs
Situation
Repair
Repay
Replace
What we do
Fix the symptom, without touching the structure
Add tests, update, simplify, document
Rewrite the module, keeping its interfaces
When
The module is rarely touched and incidents are isolated
The module is touched often and every intervention costs too much
The structure blocks an expected evolution, or nothing can be tested anymore
Cost
One request
A few requests, spread out
A workstream, split into deliverable requests
Risk
Low, but the debt remains
Low, every step is tested
High at switchover, reduced in stages
In practice, at Figue, the split on a product we take over is roughly this: most modules get repaired, a handful get repaid over a few months, and zero or one gets replaced. A whole product to rebuild is the exception, reserved for a dead stack or code that cannot be run.
“A full rebuild means paying for the software a second time to get back, at best, what you had. With the bugs you knew replaced by bugs you do not know yet.”
04
How to repay without stopping delivery?
Repaying debt is not a project. It is a habit: a share of the queue devoted to what makes the rest cheaper. Here is how it works in a queue handled one request at a time.
The right pace can be read in the queue: if feature requests get back to normal speed, the repayment is doing its job. If they stay slow on a module despite several passes, that is the signal to replace it, this time with facts to justify it.
There remain cases where replacing a module, or more rarely a product, is the right decision. They have one thing in common: they are not questions of code quality, but of capacity.
The stack is dead: the language or framework is no longer maintained, nobody knows or wants to work on it anymore, vulnerabilities will never be fixed. The architecture blocks: what your users expect cannot be built on the current structure, and the workaround would cost more than the replacement. Or nothing can be tested anymore: every change is a gamble, and the module carries revenue.
Even in these cases, the rebuild happens in stages, module by module, keeping the old one running until the new one is approved. A single switchover, on a Friday evening, is the best way to turn debt into an incident.
The model that lets you run this work one request at a time, while continuing to ship, is described on the unlimited development page.
Frequently asked questions
Technical debt, in questions
What we get asked once the word “rebuild” has been said.
How do I know if my product has technical debt?
It does, like every product that has users. The useful question is where it costs: look at which modules keep coming back in incidents, which small requests take an unreasonable time, and which areas the team does not dare to touch.
A provider recommends redoing everything. What should I ask?
Facts: which modules, which incidents, how much time lost, and why a progressive takeover would not be enough. If they answer in terms of technology rather than symptoms, the recommendation is for them, not for you.
How much does repaying debt cost?
It depends on its interest rate. In a subscription, these are ordinary requests in the queue, spread between features; you see the cost as space in the queue, not as a quote. The real cost is that of not repaying it: every evolution slower than the previous one.
Should evolutions stop during repayment?
No, the opposite: repay on the modules you are evolving, where the interest is being paid. A three-month “feature freeze” is a sign of a disguised rebuild.
Does AI help repay debt?
A lot, for writing tests, updating, simplifying. It is even one of the uses where it pays off most, because the work is repetitive and verifiable. Provided an engineer reviews: an unreviewed automatic simplification is new debt.
