5 Warning Signs of Critical Technical Debt

Technical debt doesn't warn you

Every startup I've audited said the same thing: "We know we have debt, but we don't have time to deal with it." The problem is that technical debt doesn't behave like financial debt. It doesn't generate regular interest — it explodes all at once, when it's too late.

After 14 years and over 30 technical audits, I've identified 5 unmistakable warning signs.

1. Deployment time is exploding

When a deployment takes more than 30 minutes, it's rarely an infrastructure problem. It's a symptom:

• Flaky tests that fail randomly and get rerun "fingers crossed"
• CI/CD pipeline without caching that rebuilds everything on each commit
• No feature flags so code accumulates behind increasingly long branches

The red line: if your team hesitates to deploy on a Friday, you have a problem.

2. New features take 3x longer

If a feature that "should take 2 days" consistently takes 6, it's not an estimation problem. It's that every change requires touching 15 files, understanding 3 layers of unnecessary abstraction, and praying nothing breaks.

Classic causes:

• Tight coupling between modules — nothing can be changed without side effects
• Premature abstractions created "just in case" and never used as intended
• No documentation on past architecture decisions

3. Bus factor of 1

If only one person understands the payment system, the API integration, or the deployment config, you have a bus factor of 1. One resignation, and everything stops.

Concrete signals

• Code reviews are always assigned to the same person
• Some files have only one contributor in the last 12 months
• Onboarding a new developer takes more than 2 weeks

4. Production errors are "normal"

When the team treats Sentry alerts as background noise, something is broken in the quality culture:

• More than 50 unresolved errors in the tracker
• try/catch blocks silently swallowing exceptions
• Monitoring exists but nobody watches it

At ETX Majelan, the first thing I did was push uptime from 99.2% to 99.9%. Not with miracle tools — by taking every error seriously.

5. The team avoids certain code areas

If developers systematically work around a module rather than modifying it, that's the clearest signal of toxic debt. They've learned from experience that touching that code opens Pandora's box.

How to act

Technical debt isn't repaid all at once. Here's my audit approach:

1. Map — identify risk areas (complexity, coupling, test coverage)
2. Quantify — estimate the velocity impact (time lost per sprint)
3. Prioritize — attack what blocks velocity first, not what bothers purists
4. Budget — allocate 20% of each sprint to remediation, not a "debt sprint" every 6 months

Technical debt isn't a failure. It's the natural result of decisions made with the right constraints at the time. The problem is not measuring it.