The real cost of technical debt
Antonio Chagoury, Founder & CEOOctober 20, 2026
The feature was supposed to take a week. It is week nine. The change is small. The release is not. Someone has to walk the deploy, watch production, and fix what the deploy broke. The next feature has not started.
That is the cost. Calendar time. A week that became a quarter. A Friday deploy the team will not try again until someone feels brave.
I am not writing a lecture on clean code. I am writing what I would tell a founder whose team is busy and still not shipping. Name the debt in weeks. Name the person who decides what gets paid down. Pay that, or say out loud that you are keeping the slow release.
What technical debt actually is
Technical debt is a shortcut that made one release possible and now taxes every release after it. The shortcut can be a missing test, a deploy that is a person, a module nobody will touch, or a second copy of the same data that has to stay in sync by hand.
It is a loan. The interest is calendar time. If you cannot point at the week it costs, you do not have a debt yet. You have a complaint.
A health score in a dashboard does not tell you whether Thursday's feature ships. The Thursday feature does. If it takes a quarter, the debt is already on the calendar.
Where the weeks go
I see the same three leaks, in this order.
Slow releases. The change is ready on Tuesday. It ships the Thursday after next, because the path to production is a checklist one person runs, and that person is also fixing last week's incident. A release that moves once a month is the interest payment. It is the queue of finished work sitting behind one deploy.
Brittle deploys. The deploy works until it does not. The rollback is whoever remembers the order. The team starts batching changes so they only take the risk once. Batching feels careful. It is how a one-day fix waits three weeks for the next window, and how that window gets heavier every time it fails.
A feature that takes a quarter. The product owner asked for one screen. The engineer has to touch the old module, the copy of that module, and the job that keeps them in agreement. There is no test that fails when the three disagree. So the engineer checks by hand, finds the disagreement, and the week is gone. Do that four times and the quarter is the feature.
Price it in calendar time
Write the cost as time a person can feel. Skip the score. If a row has no time on it, it is not on the payoff plan. A label that says "tech debt," with no weeks beside it, is a parking lot.
| What you feel | The calendar cost | A paid-down version |
|---|---|---|
| The release waits for one person | The days between "ready" and "in production" | A path more than one person can run |
| The deploy needs a babysitter | The hours of the deploy, plus the next day when it fails | A deploy you can run on a Tuesday, and a rollback that is a button |
| One feature touches three copies | The week of checking that they still agree | One place the data lives, and a test that fails when it drifts |
| Nobody will open a module | Every feature that has to go around it | A module with a test and a name next to it |
Pick three rows. Put a number of days on each, from the last time it happened. That list is the debt. Everything else can wait.
Who owns the payoff plan
One name. That person can say, this quarter, which items we will pay and which we will not. Engineering does the work. The owner picks the order, and says the "not this quarter" out loud so the product owner hears it.
"The team" is not an owner. A backlog filtered on the word debt is not a plan. A plan is a short list: the shortcut, the weeks it costs, the fix, and the date the interest stops.
On a small team the owner is often the engineering lead, or the founder who still ships. They do not have to stop building the product. They do have to be the name that says this deploy pain is worth a week of fix, and that other item is not.
| Question | What good looks like | Not good enough |
|---|---|---|
| What is on the plan? | Three items, each with the days it costs and the date the fix lands. | A tag called debt, with forty tickets and no dates. |
| Who picks the order? | One named person, with a backup. | "The team," or whoever is free on Friday. |
| What keeps shipping? | The product work that is not on the list. The list is beside the roadmap, not instead of it. | A freeze until the codebase feels clean. |
| How do you know it worked? | The same feature, the next time, takes the shorter time you wrote down. | A score that moved, and Thursday still takes a quarter. |
Pay the shortcut, or move the system
These are two jobs. Buy the one you have.
If the stack can stay, and the cost is the shortcuts inside it, the work is a payoff plan beside the roadmap. Write the weeks. Fix the expensive rows. Keep shipping. That program is tech debt resolution: an inventory, a rank by time returned, and the fixes done with your team.
If the runtime itself is why a change takes a quarter (the language, the server, the platform you cannot hire for), paying down shortcuts inside it will not give the week back. That move is legacy modernization. Phases. Production stays up. You do not freeze the product for a rewrite.
A rewrite that starts because the team is tired of the deploy is usually the longer loan. You respecify behavior the old system already encodes, and you ship nothing while you do it. Price that in calendar time too, before you call it the plan.
Same idea, other angles
This is the general-product version: slow releases, brittle deploys, and a feature that takes a quarter. The same week, the other Maxiom sites take the cost question from their own seat.
- The real cost of a cheap mobile app, on Maxiom Apps.
- The real cost of a bad developer hire, on Maxiom Dev.
- The real cost of HIPAA shortcuts, on Maxiom Labs.
FAQ: the real cost of technical debt
What does technical debt actually cost?
Calendar time. Releases that wait. Deploys that need a babysitter. A feature that was a week and became a quarter because three copies of the same thing have to be checked by hand. If you cannot name the days, you have not priced it yet.
How do we measure it without a score?
Take the last three times the team felt the pain. Write how many days each one took, from "ready" to "in production," or from "asked for" to "shipped." Those days are the measure. A dashboard number that moves while Thursday stays slow is not.
Who should own the payoff plan?
One person. They pick which items get paid this quarter and which wait, and they say the wait out loud. Engineering does the fixes. "The team" is not a name. A backup name sits next to the owner, or the plan pauses when they are out.
Will paying it down stop the roadmap?
No. The plan sits beside the roadmap. You pay the rows that return days, and you keep shipping the rest. A freeze until the code feels clean makes the next release later, and it does not tell you which shortcut was the expensive one.
How is this different from legacy modernization?
Tech debt resolution pays down shortcuts inside a stack you are keeping. Legacy modernization moves an aging system onto a stack your team can keep, in phases, while production stays up. If the language or the server is why the week became a quarter, start with the move. If the platform can stay, start with the payoff plan.
What does a one-page payoff plan look like?
Three rows. The shortcut. The days it cost last time. The fix. The date the interest stops. One owner. Anything that does not fit on that page is not this quarter's plan.
What if the cost is a mobile app, a hire, or a HIPAA shortcut?
Same week, different seat. A cheap mobile build that skips the hard parts is the real cost of a cheap mobile app. A contractor who leaves the team unable to ship is the real cost of a bad developer hire. A skipped BAA or PHI in the wrong log is the real cost of HIPAA shortcuts.
When should we bring someone in?
When the list is still a feeling, and nobody can say which three items return a week. That is tech debt resolution if the stack stays, or legacy modernization if the platform itself has to move. If you can already point at the days, the owner, and the date, you can run the next quarter yourselves.
If you want that plan, see legacy modernization or talk to an engineer. Thirty minutes is enough to tell whether the job is the payoff list or the move.
I write from the seat of a working engineering company, not a tool vendor. More at antoniochagoury.com.
