How I Evaluate 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 what you actually get.
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.
Debt That Costs You Now vs Debt That Might Cost You Later
Most debt conversations go sideways the moment someone lists everything ugly: forty items, and now the team feels like it's in a condemned building. Most of that list is fine. The only question that matters: 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.
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.
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.
About Me
I'm Ezequiel Actis Grosso, an experienced technology leader with over 25 years of experience in software development. I've worked across the globe—from Buenos Aires to Miami, and from San Francisco to Sydney—helping companies of all sizes succeed, from global corporations to fast-growing startups.
For the past decade, I've partnered with startup and scale-up founders in Latin America and the United States, helping them move fast, find product-market fit, scale their B2B SaaS products, and avoid leaky retention—without the burden of over-engineering and processes that slow them down.
- Track record of successful digital transformations
- Deep expertise in cloud and product development
- Proficient in DevOps practices and GenAI
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.
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.
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.