When Tech Debt Becomes Existential

What you actually need to know

• Existential tech debt is not a technical problem. It is a business problem that has a technical cause.
• The line between annoying debt and existential debt is when the codebase is limiting the company's growth more than the market or the team is.
• Engineers adapt to debt. Founders do not see it. The gap between these two realities is where companies get into trouble.
• The warning signs are measurable: velocity decline, increasing incident rate, engineer attrition citing codebase quality, features delayed or canceled for technical reasons.
• Recovery is possible. It requires treating debt reduction as a product priority with business outcomes, not a cleanup project without a sponsor.

The core argument

The easiest way to explain existential tech debt to a founder is to count sprint hours. If the engineering team is spending more than half their time on maintenance, fixes, and working around broken abstractions, the codebase is consuming the company. Every hour on debt is an hour not on the feature that could close the deal, keep the customer, or open the new market.

I have seen this calculation done in retrospect, after a company lost a customer who left for a competitor with a faster shipping cadence. The engineering team knew. They had been flagging it. The founder heard it as engineers complaining, because engineers always complain about the codebase. The difference between normal engineering complaint and an existential warning is hard to hear when you are managing investors, customers, and hiring simultaneously.

The accumulation is slow. Year one debt is the authentication flow that was hardcoded because there was no time to build a proper roles system. Year two debt is the database migration that was deferred because it would have taken two weeks and the board wanted to see the new feature. Year three is when those two things meet. The new feature needs the roles system, which needs the database migration. The two-week migration is now a two-month migration because the schema has grown in ways that were not anticipated and the authentication hack is woven through twelve endpoints.

This is not bad engineering. This is what normal software development looks like when velocity is prioritized over architecture. The problem is not the individual decisions. It is the absence of debt repayment. Debt without repayment compounds.

The four signs that debt has become existential

Sign one: the estimate has become meaningless

When the engineering team cannot give a confident estimate for a feature because they do not know what they will break in the process, the codebase has structural debt. Estimates stop being predictions and become guesses. Sprints end with half the work moved to the next sprint. This happens once and it is a warning. It happens every sprint for six months and it is existential.

Sign two: engineers are afraid of the codebase

Fear of a codebase is a specific, recognizable thing. Engineers stop refactoring because they do not want to break something. They write new code that duplicates existing code rather than touching the original. They avoid changing certain files because "nobody knows what that does." When new engineers ask why a system works a certain way and the answer is "we're not sure, just leave it," the debt is structural.

Sign three: incidents are increasing despite no new features

If the production incident rate is climbing while the feature development rate is flat or declining, the existing codebase is becoming less stable over time. This is usually debt. Old code that was never cleaned up has subtle dependencies. Changes in one part of the system break unexpected things in another. The team is playing defense on a product they built.

Sign four: good engineers are leaving and citing the codebase

Engineers do not always tell you the real reason they are leaving. But exit interviews from engineers at startups with existential debt often include some version of "I was not making progress" or "I did not feel like I could do good work." Engineers want to build things. When the job is maintaining broken abstractions, they leave for companies where they can build.

What it costs to fix it

What to look for when auditing tech debt severity

• Velocity trend: is the team shipping fewer story points per sprint than twelve months ago, adjusted for team size
• Maintenance ratio: what percentage of engineering time is going to keeping existing features working versus building new ones
• Test coverage in critical paths: if the team is afraid to change code, ask whether tests would catch the breakage
• Engineer sentiment on the codebase: not a survey, a conversation. Ask engineers which parts of the codebase they avoid and why
• Feature cancellation rate: how many features were deprioritized or canceled in the last six months for technical rather than product reasons

Expert opinion

I have seen tech debt described as a tax and as a productivity drain, and both framings are accurate but neither captures the existential version. Existential tech debt is not a tax. It is a ceiling. The company cannot grow past what the codebase allows. The market might be ready, the team might be capable, the product might be right, and none of it matters because the code takes three months to do what a better-structured system would do in three weeks. That ceiling is survivable only if the business grows slowly enough to not hit it. Most startups do not have that luxury.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A SaaS company I worked with had a feature launch that was six months late. Not because the team was slow. Not because the requirements changed. Because the part of the codebase the feature needed to touch was so entangled with a legacy authentication module that every change introduced a new failure mode. The team spent four of those six months untangling the authentication module before they could start building.

The founder had been told twelve months earlier that the authentication module was a liability. The estimate for addressing it at that point was three weeks. The estimate when they finally had to address it, under deadline pressure, while untangling it from a new feature, was three months. The tech debt audit they ran after the launch showed that this pattern was present in four other areas of the codebase. The cost of addressing all four at the point of the audit was estimated at nine months of engineering time. The cost if they had addressed each one when it was first flagged would have been three to four weeks total.

The company survived. But the six-month delay cost them a customer who had been waiting for the feature and signed with a competitor. The negotiation with the board about whether to do a debt reduction sprint happened after the loss, not before. That is the most common timing for this conversation.

Common mistakes

1. Treating tech debt as an engineering problem rather than a business problem. Until founders see the velocity cost, the debt will not get funded.
2. Promising to clean up after the launch and never scheduling it. The next launch is always more urgent than the cleanup from the last one.
3. Measuring productivity by features shipped without measuring the cost of maintaining existing features. The maintenance ratio is invisible without deliberately measuring it.
4. Doing a debt reduction sprint once and treating it as resolved. Debt reduction is a discipline, not a one-time event. It needs to be on the engineering calendar permanently.
5. Starting a rewrite instead of a targeted refactor. Rewrites almost always take longer than estimated and are more disruptive than incremental improvement.
6. Not communicating the debt to investors and the board. Boards that understand the debt can fund the fix. Boards that find out about it when it causes a missed deadline are surprised and angry.
7. Letting the codebase develop fear zones that nobody touches. Fear zones grow. The solution is to write tests for the fear zone before refactoring it, not to avoid it.

A 6-month plan to address existential tech debt

1. Run the debt audit in month one. Use the framework above: velocity trend, maintenance ratio, test coverage in critical paths, engineer sentiment, feature cancellation rate. Produce a list of the five most expensive debt areas with a rough estimate of the cost to address each.
2. Build the business case and present it to the founder and board. Frame it in business outcomes: the estimated velocity unlock if the top two debt areas are addressed.
3. In month two, designate 20% of each sprint as a permanent debt track. This is not negotiable sprint to sprint. It is a standing allocation.
4. Start with the debt area that is blocking the most planned features. Do not start with the area that is most technically interesting. Start with the one that is costing the business the most.
5. Measure velocity in the affected area before and after each debt sprint. The improvement should be visible in sprint completions within two to three cycles.
6. At the six-month mark, run the debt audit again. Compare the five areas from month one to their current state. Show the improvement. Use the improvement to advocate for continuing the allocation.

The tech debt ledger is the tool that keeps this from reverting. Without a written record of what the debt is, who owns the area, and what the remediation plan is, the debt reduction sprint becomes another thing that gets dropped when the roadmap gets crowded. Write it down. Maintain it. Treat it like a product backlog.