Existing SaaS · Technical debt
How to identify and reduce
technical debt in an existing
SaaS application?
Technical debt is the gap between what was coded fast and what should have been done properly. A codebase audit, scaled to its size, identifies it. Reducing it requires a prioritised plan that distinguishes what's truly blocking from what can wait, without rewriting everything.
The concrete problem
What technical debt means in practice
No theory needed. Technical debt is when adding a feature takes three times longer than it should, when every change creates a bug somewhere else, or when nobody on the team dares touch certain files.
I worked 7 years on Sellermania, a SaaS with an ageing codebase. I know how to recognise genuine risk zones vs simply inelegant code. That distinction is what separates a useful plan from an unworkable audit.
The bad news: every application accumulates technical debt. The good news: any technical debt can be reduced progressively, without a full rewrite, without interrupting production.
My approach
How I identify the debt
Mapping
I read the code, look at frequently touched areas in the git log, and ask the team: "which parts of the code do you most try to avoid?" The answers reveal more than any metric.
Prioritisation
Three criteria: frequency of change, impact on stability, human cost. What's modified often and poorly structured comes first. What's stable and rarely touched can wait.
Remediation plan
Written deliverable: each problem area, the concrete risk, recommended refactoring, effort estimate in person-days. Applicable by your existing team, not only by me.
Method
Refactor vs rewrite
A full rewrite is rarely the right answer. It takes 3 to 4 times longer than planned, accumulates its own debt, and creates a risky transition period.
The Strangler Fig pattern progressively replaces problematic components with new ones while keeping the application in production. I applied this approach to the Symfony 2 → 3 → 4 migration at Sellermania: zero downtime over 7 years.
When rewriting makes sense: when the fundamental architecture is broken, when couplings prevent any decomposition, or when the maintenance cost exceeds the cost of a targeted module rewrite. It's never the whole application at once.
Deliverable
What you receive
- Written audit report (PDF + collaborative format)
- Risk zone map, by criticality
- Prioritised remediation plan across 3 horizons (short / medium / long term)
- Recommendations applicable by your existing team
- Effort estimate for each action
- 45-minute debrief session
Go further
Other audit cases
First contact
Worried about your codebase?
Tell me about the situation in a few lines. I reply within 24 hours with an initial assessment.