Every Change Takes Longer Than the Last One
A small feature used to take three days and now takes three weeks. Nobody dares touch the billing module. The only person who understands the deployment left last year. That is not bad luck, it is technical debt compounding, and it has a measurable interest rate. We audit the codebase, quantify what the debt is costing you every month, and hand you a prioritized refactoring plan that ships alongside your roadmap instead of replacing it.
What a Technical Debt Audit Covers
- Codebase Audit With Evidence: Static analysis plus manual review of the parts that matter: cyclomatic complexity, duplication, coupling, dead code, and the modules your git history shows everyone is afraid of. Every finding points at a specific file and line, never at a vague "the architecture needs work".
- The Debt Expressed in Money and Time: We translate the findings into the numbers your management actually decides with: extra developer hours per sprint caused by each debt cluster, delivery slowdown, incident frequency, and infrastructure you are overpaying for. A number turns an engineering complaint into a business case.
- Dependency and Security Review: Outdated libraries, abandoned packages, known vulnerabilities, and runtimes past end of life. We separate what is genuinely urgent from what a scanner flagged in a dependency you never call, so your team spends its upgrade budget where the risk actually is.
- A Refactoring Plan in Shippable Slices: Ordered by return, not by how much the code offends us. Each slice fits inside a normal sprint, leaves the system working, and can be stopped after any step without leaving the codebase half migrated. The big-bang rewrite is the failure mode we are hired to avoid.
- Legacy Modernization Without a Rewrite: Strangler pattern, module by module: the new code takes over one responsibility at a time behind a stable interface while the old system keeps serving everything else. Users see no interruption, and you can stop or reverse at any point because both versions run side by side.
- Safety Net Before Surgery: Refactoring without tests is just moving risk around. We add characterization tests around the code we are about to change, set up CI so a regression is caught in minutes, and document what the module actually does, which is often the first written record of it.
How the Audit and the Remediation Run
- Read-Only Access and Context: We get read access to the repository, the issue tracker and the monitoring, and we interview whoever maintains the system. The team already knows where the bodies are buried: the audit exists to prove it with numbers and to find what nobody had noticed.
- Automated Analysis: Complexity, duplication, coupling, test coverage, dependency and vulnerability scanning, plus git history mining to find the files that change most often and break most often. Those two lists overlapping is the map of where your debt actually hurts.
- Manual Review Where It Counts: Tools find symptoms, not causes. We read the critical paths by hand: authentication, billing, anything touching money or personal data, and the integrations that fail silently. This is where an audit stops being a report and starts being useful.
- Costing and Prioritization: Each finding gets an estimated remediation effort and an estimated monthly cost of leaving it alone. Sorting by the ratio between the two produces the plan, and it regularly surprises people: the ugliest code is often not the most expensive.
- Report and Decision Session: You receive the findings, the costs and the phased plan, and we walk through it with both your technical and business people in the room. Some items you will decide never to fix, and that is a legitimate outcome: what matters is that it becomes a decision instead of an accident.
- Incremental Execution (Optional): If you want us to execute it, we work in slices alongside your roadmap: tests first, then the refactor, then the measurement that proves the slice paid off. You can stop after any slice, and your team can take over at any point because the plan is documented, not in our heads.
What the Debt Costs While You Postpone It
These are the four costs we measure in every audit. The pattern is always the same: the debt is never the most urgent thing on the list, which is exactly why it keeps growing.
- Delivery speed: The same feature, three times the estimate: Duplication and coupling mean one change has to be made in four places, and nobody is sure they found all four. The estimate inflates to cover the uncertainty, and the sprint absorbs the difference. (Estimates padded for fear → Estimates based on the work)
- Incidents: Production breaks in the same three places: Without tests, every deployment is a bet. The team learns to deploy on Tuesday mornings and to avoid certain modules entirely, which is a workaround for a problem, not a solution to it. (Deployments feared and deferred → Deployments boring and frequent)
- Infrastructure: Paying for servers to hide a query: Scaling up is the fastest way to make a performance problem invisible, and the most expensive way to keep it. In most audits a handful of unindexed queries and N+1 loops account for the majority of the monthly cloud bill. (Oversized instances as painkillers → Capacity matched to real load)
- People: Knowledge that lives in one head: Onboarding takes months, holidays become risks, and one resignation can stall a roadmap. Undocumented code is a retention problem disguised as a technical one, and it gets worse every quarter. (One person is the documentation → Anyone can pick up the module)
Stacks We Audit and Modernize
We work on the platforms that most legacy systems in Spain are actually built on, and we audit code we would not choose today: the point is to improve what exists, not to relocate it to our favourite framework.
Frequently Asked Questions
Is this going to end with you telling us to rewrite everything?
Almost never, and we treat that recommendation as a last resort. Full rewrites overrun, lose behaviour nobody documented, and freeze the product for months while competitors keep shipping. In the rare case where a rewrite genuinely is cheaper, we will show you the arithmetic that got us there rather than asserting it.
Do we have to stop developing features during the audit?
No. The audit is read-only and does not touch your repository or your deployments, so your team keeps working normally. During the remediation phase we work in slices that fit inside your existing sprints, which is slower than a freeze but is the only version that survives contact with a real business.
Our code is embarrassing. Is that a problem?
It is the normal case. Code that looks bad usually got that way because the business needed something shipped, which is a defensible trade at the time. We are not there to judge decisions made under deadline pressure, we are there to price what those decisions are costing now and to tell you which ones are worth reversing.
How much does a technical debt audit cost?
A focused audit of a single application usually runs from 3,000 to 6,000 euros, and a multi-application or microservices estate from 8,000 euros upwards depending on how many repositories are in scope. Remediation is quoted separately per phase so you never commit to the whole plan up front. The first consultation is free.
We did not build the system. Can you still audit it?
Yes, and inherited systems are a large share of this work. We do not need the original team, only read access to the code and whatever history exists. When there is no documentation at all, reconstructing what the system actually does becomes the first deliverable, and it is usually worth the audit fee on its own.
Will you sign an NDA before looking at our code?
Yes, before any access is granted, and we are happy to work under yours rather than ours. Access is read-only, limited to the people doing the audit, and revoked when the engagement ends. We keep no copy of your repository after delivery unless you ask us to for a remediation phase.