Most founders treat technical debt as an engineering problem — something the team should be managing, something that slows features, something that will "be addressed when we have time." At $5M–$20M ARR, that framing is expensive. Technical debt at this stage is a revenue problem, and it compounds.
What Technical Debt Actually Costs
The costs are rarely visible in one place, which is why they're underestimated.
Feature velocity. A codebase with significant debt takes 2-4× longer to add capabilities that should be straightforward. Teams become reluctant to change areas of the code that "nobody fully understands anymore." New engineers take longer to become productive. The cost shows up in your roadmap — features scheduled for Q2 that ship in Q4, or don't ship at all.
Incident rate. First-generation stacks are often built without proper observability, error boundaries, or graceful degradation. When something breaks, it breaks loudly and unpredictably. At $10M ARR, a 2-hour outage is a measurable revenue event, not an engineering embarrassment.
Engineering retention. The candidates your culture and brand attract want to work on interesting, well-crafted systems. When the codebase is a drag, the engineers who care most about craft leave first. The ones who stay are less discerning about quality. This feedback loop is slow but real.
Opportunity cost. Every engineering hour spent on workarounds, hotfixes, and "fighting the system" is an hour not spent on the capability that would move the business forward.
How to Quantify It
The most useful framework: total engineering hours per shipped feature, compared to a baseline.
Take a feature from 12 months ago that everyone agrees should have taken 2 weeks. How long did it actually take? Now take a comparable feature from 6 months ago. From last month. If the trend is upward — each comparable feature taking materially longer — you're paying compounding technical debt interest.
The second metric: incident rate and time-to-recover. Track the number of incidents per month and the average time from detection to recovery. At a well-architected system, this should be declining as the team learns the system. If it's flat or increasing, the debt is generating new failure modes faster than the team is resolving them.
Put rough numbers on it. If your engineering team costs $1.2M/year fully burdened and 30% of hours are spent on debt-related work — workarounds, incident response, reverse-engineering undocumented systems — that's $360K/year in direct cost before you account for the features that weren't shipped.
When the Rebuild Math Works
The standard advice ("don't rewrite, refactor instead") is often correct for legacy codebases with long histories and uncertain scope. For many B2B SaaS products at $5M–$20M ARR, it's the wrong advice.
The rebuild math works when:
The first-generation architecture is the constraint, not the implementation. If the core data model is wrong — if tenant isolation was bolted on after the fact, if the event schema doesn't match how the product actually needs to query it — refactoring around a bad architecture produces a slightly cleaner version of the same problem. The architecture decision is a one-way door. If you got it wrong, a targeted rebuild is cheaper than decades of maintenance.
The surface area is bounded. The highest-risk rebuilds are "rebuild everything at once." The ones that work target one system — the analytics layer, the ingestion pipeline, the API layer — while leaving adjacent systems running. Incremental migration with a clear strangler fig strategy dramatically reduces risk.
You have the baseline to measure against. "The new system is better" is not a sufficient definition of success. "P99 query time decreased from 1.2s to under 200ms, measured against the same queries on the same data volume" is. The rebuild should have explicit performance targets before you start, not after you ship.
Engineering time saved pays back the build cost within 12 months. If the rebuild takes 14 weeks at $X in engineering cost, and it recovers Y hours/week of engineering velocity, the payback calculation is straightforward. If it doesn't pencil at 12 months, reconsider scope.
The Conversation Your Team Is Not Having
The blocking dynamic in most companies with significant technical debt is this: the engineers know the system is a drag, but they've stopped raising it because previous attempts went nowhere. Founders and PMs hear "technical debt" as "engineering wants to clean up code" rather than "we are paying a meaningful tax on every feature we ship."
The conversation worth having is quantitative. Not "we have too much debt" but "we spent 14 weeks on the search revamp that should have taken 4, and here is what that cost in opportunity. Here is the trend over the last 12 months. Here is what I think a targeted rebuild of the query layer would return."
That conversation is hard to ignore. The abstract version almost always gets deprioritised.
What a Good Architectural Audit Surfaces
If you suspect significant debt but can't quantify it, a structured audit is the starting point. What to look for:
P99 and P95 latency on critical paths. Not average — P99. Average hides the outliers that your worst-case users experience.
Bundle size and load time on the front end. If the front-end bundle has grown 4× since launch without a corresponding 4× increase in user-facing capability, something is wrong.
Infrastructure cost per unit of output. If your hosting costs are growing faster than your usage, you have architectural inefficiency somewhere.
Time to deploy and rollback. A healthy system should be deployable in minutes and reversible in seconds. If deploys take hours and rollbacks are manual, the system cannot be maintained safely.
Undocumented systems. Areas of the codebase where "only one engineer knows how it works" are liability, not just technical risk. Knowledge concentration is a bus-factor problem that technical debt makes worse.
The output of a good audit is not a list of everything wrong. It's a ranked list of the specific changes that would produce the most measurable return, in the order that makes structural sense to implement them.
That's the starting point for making the rebuild decision with numbers rather than intuition.