Audit → backlog
How I Evaluate and Reduce Tech Debt
Most "we think we have a technical debt problem" calls are really asking two things: how bad is it, and can I trust the team that built it? Here's how I find out, and how the debt gets paid down afterwards without freezing your roadmap.
Starting point
What I Look At First (Before the Code)
Technical debt is identified by watching how the code moves: what's slow to change, what the team's afraid to touch. So I start with three signals, before any opinion about your stack.
The Test Situation
Can a developer make a scary change and find out in ninety seconds whether they broke it? If the answer is "we click around and hope," that's your real debt. Almost everything else is downstream of it.
Coupling & Hotspots
How many files do you touch to add one field to a form? The files that show up in every third commit are where your team bleeds time, and it's almost never where they think it is.
The Deploy Pipeline
How long from "I'm done" to "it's in production"? Who can do it, and what happens when it breaks? A slow, manual, one-person deploy tells me more about a team than any architecture diagram.
Priorities
Debt That Costs You Now vs Debt That Might Cost You Later
A list of forty ugly things isn't an assessment. It's a morale problem with a spreadsheet attached. Most of that list is fine, and the sort that matters comes down to one question: is this charging you interest now, or might it someday?
Debt that costs you now
It has a heartbeat you can measure. The flow that breaks whenever someone touches checkout. The service nobody will deploy on a Friday. The migration half-done for eight months. You can point at the calendar and show the days each one ate.
Debt that might cost you later
The architectural stuff: the monolith that'll hurt to split when you're three times bigger, the database that'll need sharding at a scale you haven't hit. Real, but speculative. Startups die from present problems far more often than future ones.
Priorities
Turning Findings Into a Backlog That Doesn't Lie
What you get is a map. Not a forty-item indictment. A map. Each item gets three things, and I'm strict about it, because a debt backlog without them is just a list of opinions.
What it costs you now
A real number, in time. "Every checkout change risks the onboarding flow: about two extra days of testing per release." If I can't put a number on it, it drops off the map.
What it costs to fix
Honestly, including the part where the estimate is a guess. A range, not a date. Then I sort by the ratio of cost-now to cost-to-fix, and the top of that list is almost always smaller and more boring than anyone expected.
What it unlocks
Debt paydown that doesn't make the next ten features faster is a vanity project. If fixing it only makes the code prettier, it waits. Boring is the point: the boring items at the top are the ones charging the most interest.
It's rarely "rewrite the architecture." It's usually "get the test suite under five minutes so people actually run it," or "delete the dead half of that migration," or "make the deploy a button instead of a ritual." The exciting rewrite everyone fantasizes about is usually paying nothing today and would cost a quarter to chase.
The approach
Actually Reducing It, Without Freezing the Roadmap
The assessment is the cheap half. This is where debt work usually dies: everyone agrees the map is right, and then nobody wants to be the person who tells the board the roadmap slipped a quarter for a refactor. So the reduction has to happen inside the feature work, not instead of it.
A standing slice, not a cleanup quarter
"We'll clean up after the launch" has never once survived contact with a launch. What works is boring: a standing slice of every cycle that belongs to the top of the debt list, small enough that nobody has to approve it, permanent enough that it compounds. Don't set it as a percentage. A policy number ("we do 20% tech debt") gets defended in budget meetings long after the map says the friction moved, and it promises an end state that doesn't exist. Size the slice to what the assessment measured: if the top item is charging two days a release, the slice is whatever pays that down, and it shrinks when the interest does.
Fix it where you're already standing
The files your team is scared of are usually the files the roadmap keeps sending them back into. That overlap is the whole trick: pay down the module you're shipping a feature through, and the cleanup arrives with a business reason attached instead of a request for permission.
Wrap it, then replace it
For the big ugly thing nobody wants to touch, the strangler pattern: put a new layer in front of the old system and move one slice at a time behind it, until nothing is running on the old path. You're never down, and you can stop halfway if the business changes its mind.
You'll know it's working before any chart does. The change everyone dreaded stops being a two-person job. Someone deploys on a Friday without narrating it in Slack. The number that matters isn't debt removed (nobody can count that honestly): it's how long it takes to ship the next scary thing.
Fit
Telling Founders the Truth Without Tanking Morale
The deliverable isn't the map. It's a founder who can make a decision and a team that still wants to be there next week.
Founders want a grade: "is our code good or bad?" There's no honest answer, so I don't give one. I reframe it to the only thing a business can act on: what the debt costs you in velocity now, the slice that's cheap to fix, and the bigger stuff we're deliberately leaving alone for now.
The best outcome isn't a clean codebase. It's a team that's no longer afraid of its own debt, holding a short list it believes in, shipping a little faster every month. That's usually what they hired me to fix anyway. They just thought it was the code.
Background
About Me
I'm Ezequiel Actis Grosso, a technology leader with 25 years in software — from Buenos Aires to Miami, and from San Francisco to Sydney, across global corporations and fast-growing startups.
For the past decade I've worked with founders in Latin America and the United States — helping them move fast, find product-market fit and scale their B2B SaaS products, without the over-engineering that slows them down.
Ezequiel Actis Grosso
Fractional CTO
- Architecture for AI products in production
- Technical due diligence for investors
- From zero to first customer with MVP delivery
Next step
Get an Honest Read on Your Technical Debt
I'll tell you what's costing you velocity now, what's safe to ignore, and where the cheap, high-leverage fixes are, in plain business terms. Sometimes an afternoon and the three right questions is all it takes.
FAQ
Frequently Asked Questions
What is a technical debt assessment?
A technical debt assessment measures the gap between what your team can ship today and what they could ship before the codebase slowed them down. Done well, it's less about counting code smells and more about pricing them: what's charging you interest right now, what might cost you later, and what you can safely ignore for years. The deliverable is a prioritized backlog, not a forty-item indictment.
What does a fractional CTO look at first when evaluating technical debt?
Three things, before forming an opinion on your framework choices: the test situation (can a developer make a scary change and find out in ninety seconds if they broke it?), coupling (how many files you touch to add one field), and the deploy pipeline (how long from "I'm done" to "it's in production", who can do it, and what happens when it goes wrong). The git history tells me where the code actually changes most, which is rarely where the team thinks it does.
What's the difference between debt that costs you now and debt that might cost you later?
Debt that costs you now has a heartbeat you can measure: the service everyone's afraid to deploy on a Friday, the half-finished migration every feature has to handle, the flow that breaks whenever someone touches checkout. Debt that might cost you later is speculative and architectural: the monolith that'll be painful to split when you're three times bigger. Startups die from present problems far more often than future ones, so the present-cost debt almost always wins.
How do you read a codebase without making the team feel audited?
I don't ask the code where the bodies are buried. I ask the people: "If you had a free week to fix one thing nobody's letting you fix, what would it be?" Every engineer has that answer loaded. The framing matters: the debt is a property of the code, and treating it as a verdict on the coder kills the conversation. Most of it was written by good people under real deadlines making the right call for that week. Kill the fear that the assessment is a weapon, or you'll never hear the truth.
Should we rewrite our codebase from scratch to clear technical debt?
Almost never. The ugly code you want to throw away is a logbook: every weird conditional is a production bug someone already fixed. I wrap the old system and replace it one slice at a time, so you're never down and never betting the company on a big-bang switch. A full rewrite is a rare exception you earn your way to, never the reflex you start from.
How do you present a technical debt assessment to founders without tanking morale?
Founders want a grade ("is our code good or bad?"), and there's no honest answer to that, so I don't give one. I reframe it as a budget decision: here's what your debt is costing in velocity right now, here's the slice that's cheap to fix, here's what it buys back, and here's the larger stuff we're deliberately not touching yet. And I talk about the system, never the people, in front of the team when I can, because the moment engineers think the assessment is pointed at them, they stop telling you where the real problems are.
How does a fractional CTO reduce technical debt without stopping feature work?
By refusing the cleanup quarter. Debt reduction that needs its own sprint needs a business case, and it loses that argument to revenue every single time. Instead: a standing slice of each cycle assigned to the top of the debt backlog, paydown done inside the modules the roadmap is already sending people into, and the one big untouchable system wrapped and replaced a slice at a time rather than rewritten. The reduction rides along with the features. That's the only version I've seen survive a busy quarter.
How long does technical debt reduction take?
The top of a good debt list is usually days, not quarters: get the test suite under five minutes so people actually run it, delete the dead half of a migration, turn the deploy into a button instead of a ritual. Those land in the first few weeks and buy time back immediately. The architectural items (splitting a monolith, replacing a system through a wrapper) run for months alongside feature work, and they're supposed to. If someone hands you a debt reduction plan with a finish date on it, they're selling you a rewrite.
When should a startup not bother assessing technical debt?
Before product-market fit. At that stage the code is supposed to be disposable, because half of it gets thrown away once you discover what you're actually building. Assessing technical debt pre-PMF is like repainting a house you haven't decided to live in. There's a time to take debt deliberately and run, and recognizing it is the same craft as recognizing when to pay it down.