Managing Technical Debt in Fast-Moving Startups

Technical debt isn’t a sign of bad engineering. It’s a sign of a startup making trade-offs to move fast. Myles Ndlovu has managed codebases with significant technical debt and learned that the key isn’t avoiding it — it’s managing it deliberately.

What Technical Debt Actually Is

Technical debt is the gap between the code you have and the code you’d have if you could rebuild with everything you know now. It accumulates in several ways:

Deliberate debt: “We know this isn’t ideal, but shipping this week matters more than architectural purity.” This is a valid business decision.

Accidental debt: “We didn’t know a better way to do this when we built it.” This is natural — you learn as you build.

Bit rot: “This code was fine when we wrote it, but the system around it has changed.” Libraries get deprecated, requirements evolve, scale increases.

Knowledge debt: “Nobody on the team understands how this works anymore.” The original author left, there’s no documentation, and the code is too complex to easily reason about.

When to Take on Debt

Taking on technical debt is justified when:

Speed matters more than quality: You’re validating a hypothesis. If the experiment fails, the code gets deleted. Perfect code for a failed experiment is wasted effort.
The cost of delay is high: A competitor is about to launch. A customer is about to churn. The market window is closing.
You’ll learn from it: Building the “wrong” way teaches you what the “right” way is. The second version is always better because you understand the problem.

Technical debt is NOT justified when:

Security is at stake (never shortcut security)
Financial accuracy is at stake (never shortcut money math)
You’ll forget about it (if there’s no plan to address it, it’s not debt — it’s negligence)

Tracking Debt

You can’t manage what you don’t track. Create a simple system:

The Debt Register

A living document (or tickets in your project tracker) that records:

What: Description of the debt
Where: Which files/services are affected
Impact: What problems does it cause? (Slow development, bugs, performance issues)
Cost to fix: Rough estimate in days/weeks
Priority: How urgently does it need to be addressed?

Categorise by Impact

High impact: Causes bugs, security vulnerabilities, or blocks feature development. Fix soon.

Medium impact: Slows development, makes code harder to understand, or causes intermittent issues. Schedule for next quarter.

Low impact: Cosmetic, minor inconsistencies, or affects rarely-touched code. Fix opportunistically.

The 20% Rule

Allocate roughly 20% of engineering capacity to debt reduction. Not in big batches — continuously.

In a two-week sprint with 10 available days:

8 days on features and bug fixes
2 days on technical debt

This ratio keeps velocity high while preventing debt from compounding out of control. Adjust based on how much debt pressure you’re feeling.

Refactoring Strategies

Strangler Fig Pattern

Don’t rewrite — wrap. Build the new system alongside the old one, gradually routing traffic to the new system until the old one can be removed.

Phase 1: All traffic → Old System
Phase 2: 10% traffic → New System, 90% → Old System
Phase 3: 100% traffic → New System
Phase 4: Remove Old System

Boy Scout Rule

Leave code better than you found it. When you touch a file for a feature, clean up small debt items in that file. Over time, frequently-changed files get cleaner.

Planned Rewrites

For isolated components with clear boundaries, a planned rewrite can be faster than incremental improvement. But only if:

The component has well-defined inputs and outputs
You have tests that verify the existing behaviour
The rewrite scope is bounded (days, not months)

Communication

Technical debt is a business concern, not just an engineering one. Communicate it in business terms:

Bad: “We need to refactor the payment module because the architecture is messy.”

Good: “The payment module’s architecture is causing 2-3 bugs per month and slowing new payment method integration from 1 week to 3 weeks. A 2-week refactor would reduce bugs and cut integration time by 60%.”

Product managers and founders respond to impact metrics, not architecture opinions.

Warning Signs

You have a critical debt problem when:

New features take 3x longer than they should because of workarounds
The same types of bugs keep recurring
Only one person can safely change certain parts of the code
Engineers are afraid to touch certain files
Deployment frequency is declining
New engineers take months to become productive

If you’re seeing these signs, the 20% allocation isn’t enough. You need a focused debt reduction initiative.

The Startup Reality

Perfect code doesn’t ship products. Shipped products with manageable debt build companies. The goal isn’t zero debt — it’s debt that you’ve chosen deliberately, tracked openly, and pay down steadily.

The startups that fail from technical debt aren’t the ones who took shortcuts — they’re the ones who took shortcuts and then pretended the shortcuts didn’t exist.