Technical debt audit: what to check and what to fix first

A technical debt audit answers two questions: what in your application costs your team time or exposes you to an incident, and where to start. It is carried out with read-only access to the code, the database, the accounts and the incident history. It ends with a list of fixes ranked by business risk and by effort, and a decision for each module: keep it, fix it or replace it.

What is technical debt, in practice?

The metaphor comes from Ward Cunningham in 1992: shipping code written in a hurry is like taking on debt, and every minute spent afterwards working with not-quite-right code is interest paid on that debt (Cunningham, OOPSLA 1992). Taking on debt is not a mistake in itself. Martin Fowler separates debt a team takes on deliberately, to hit a date while knowing what it is putting off, from debt that builds up without anyone noticing (Technical Debt Quadrant). The first kind can be managed. An audit exists mostly to bring the second kind to light.

For a founder, debt rarely shows up as code. It looks more like this:

• a library or framework that is no longer maintained, so it no longer gets security fixes;
• a part of the code nobody dares to touch because it has no tests;
• an access rule written in a rush that lets one user read another user’s data;
• a manual release process that only one person knows how to run;
• an architecture designed for a few hundred users, whose cost climbs with every new customer.

What are the signs that you need an audit?

You can spot these without reading a line of code:

• each new feature takes longer than the last one of similar size;
• the same bugs come back after being fixed;
• only one person can ship to production, or understands part of the code;
• you do not know what the app costs per month, or why the bill keeps rising;
• a contractor is leaving, or a new team is coming in;
• an investor, an acquirer or a large customer asks technical questions nobody can answer;
• the app was generated with Lovable, Bolt or a similar tool, and real customers are about to use it.

If a funding round or an acquisition is what triggers the audit, read what a technical due diligence checks as well. If a customer is asking security questions, the article on SaaS security and GDPR covers the baseline they expect.

What does a technical debt audit cover?

Some of the debt sits around the code rather than in it: in accounts, backups and dependencies. A serious audit covers at least these ten points.

• What really worksEach announced feature is working, partial or missing.
• Data accessUsers only see their own data, enforced on the server.
• Secret keysNo keys in the code sent to the browser or in the history.
• DependenciesVersions still maintained, with no known vulnerability left open.
• Code structureAnother developer can take over without the original author.
• Tests and releasesCritical journeys are tested and a rollback is possible.
• BackupsA restore has already been tested on a copy of the database.
• Account ownershipRepository, hosting, database and domain belong to the company.
• Monthly costsKnown line by line, today and at 10 times the users.
• DocumentationArchitecture and routine operations are written down somewhere.

Four of these points deserve a closer look.

Dependencies and versions

An application relies on many libraries written by other people. When one of them is no longer maintained, it stops getting security fixes. A dated example: Node.js 20, a version of the JavaScript runtime used on servers, reached end of life on 30 April 2026 (Node.js release schedule). The Node.js project advises running only Active LTS or Maintenance LTS versions in production (Node.js).

OWASP, the reference foundation for web application security, ranks software supply chain failures (risks that come from third-party components) third in its 2025 list (OWASP Top 10:2025). On GitHub, Dependabot alerts flag dependencies with a known vulnerability (GitHub documentation).

Data access and secret keys

The top risk in the same list is broken access control: a user can see or change data that is not theirs. The audit checks that every rule is enforced by the server or the database, and not merely hidden in the interface. On Supabase, for example, that means row level security policies, known as RLS (Supabase documentation).

For secret keys (payments, email, AI), GitHub secret scanning searches the whole repository history (GitHub documentation). A key deleted from the code can still be read in that history, so it has to be replaced with a new one.

Releases and rollbacks

The DORA research programme offers simple indicators to track how a team delivers: the time from a change to its release, how often releases happen, the share of releases that need immediate intervention, and the time it takes to recover from a failed release (DORA). The audit also checks whether the team can go back to the previous version within minutes, and whether database structure changes are stored in the repository.

Accounts, backups and costs

The code repository, hosting, database and domain name should all be in your company’s name. A backup is only worth something once a restore has been tested. Monthly costs should be broken down line by line, today and at ten times the users: that is the scale at which an unsuitable architecture shows up on the bill.

How does the audit work?

The five steps of a technical debt audit

1. 01Read-only accessCode repository, database, hosting and error tracking.
2. 02ScopingWhat the app must do, what worries you, recent incidents.
3. 03AnalysisEach point checked in the code, with specific examples.
4. 04RatingA green, amber or red light per point, with the effort estimated.
5. 05DebriefA keep, fix or replace plan, in the order to tackle it.

You grant read-only access to the code repository and the tools (database, hosting, error tracking), then explain what the app must do, what worries you and what went wrong recently. A non-disclosure agreement can be signed before any access is opened.

You get a report that a founder and a developer can both read: one point per line, a green, amber or red light for each, examples taken from your code, and a plan. At Techvisor, the express assessment takes about 3 working days and costs €1,200 excluding VAT. The full audit, which adds a feature-by-feature inventory of what really works and a costed roadmap, takes about 5 working days for €2,400 excluding VAT. The app audit page shows a made-up sample report.

How do you prioritise the fixes?

Each finding gets two scores.

• Business risk. What happens if nothing is done? From most to least serious: customer data leaked or lost, money lost or stuck (payments, invoicing), the app going down, a sale or funding round blocked, a slower team.
• Effort to fix, in working days, estimated by whoever will do the fix.

Putting the two together places each fix in one of the four boxes below.

Rank each fix by risk and effort

LowBusiness riskHigh

Along the wayLater, or neverRight nowPlan itExposed secret keyOpen access ruleBackup never restoredUntested payment flowFramework out of supportNo documentationDuplicated codeInterface redesign

LowEffort to fixHigh

• Right now (high risk, low effort): before any new feature. An exposed key or an open access rule belongs here.
• Plan it (high risk, high effort): break it into steps, each with a date and an owner.
• Along the way (low risk, low effort): fix it the next time the team works in that area.
• Later, or never (low risk, high effort): write it down and accept it. Debt that costs nothing can stay.

For each module, the final call comes down to these criteria.

How do you pay down debt without stopping new features?

• Deal with the urgent items in one go, before resuming planned work.
• Set aside a fixed share of every development cycle for debt, agreed with the team and kept even when the schedule is tight.
• Consolidate where you are about to build: before adding a feature to a fragile module, stabilise it and cover it with tests.
• Keep a debt register: every deliberate shortcut goes in, with its reason and the date you plan to pay it back.
• Track a few indicators, always the same ones: time to release, failed releases, incidents and monthly cost.

What should you ask an audit provider?

Before signing, ask:

1. Is access read-only, and removed at the end?
2. Does the report quote examples from my code, or stay general?
3. Is the price fixed and known before work starts?
4. Does the report give a decision for each point that a non-developer can follow?
5. In which cases do you advise keeping existing code? A provider who recommends a rebuild every time tells you nothing about your app.
6. Can my team, or another agency, use the report?

My take as a CTO

I co-founded Welco in 2019 and I am its CTO; I have also been a partner and CTO at Jo’s Burger since 2024. In both companies, a bad technical call costs my own business, and that is the lens I use to read someone else’s debt. At Axiome Avocats, I compared several scenarios for the firm’s information systems, with their costs and risks, before proposing a phased roadmap. I handle debt the same way: I only recommend rebuilding what has to be rebuilt, and I always start with whatever exposes your customers’ data or money. Debt that is known, costed and paid back on a plan worries neither a team nor an investor. Debt discovered in the middle of an incident gets handled in a rush, at the worst possible moment.

Frequently asked questions

How much does a technical debt audit cost?

At Techvisor, €1,200 excluding VAT for the express assessment (security, code, data and costs) and €2,400 excluding VAT for the full audit with a costed roadmap. Fixes are not included: your team can carry them out from the plan, or the takeover and launch option starts at €5,000 excluding VAT.

How long does the audit take?

About 3 working days for the express assessment and about 5 for the full audit. These are estimates: the size of the codebase and the number of connected tools change them.

Do we need to pause development during the audit?

No. The audit is read-only and does not touch the app. It actually helps if the team keeps shipping, because the auditor sees how it really works.

Isn’t an automated analysis tool enough?

Tools (dependency alerts, secret scanning, static code analysis) spot symptoms and are worth running continuously. They do not tell you what matters for your business, whether announced features really work, or who owns your accounts. An audit starts from their output, then makes the calls.

My app was built with Lovable or Bolt. Does the method change?

The method stays the same; the priorities shift: database access rules, keys in the code sent to the browser, separation between test and production, and ownership of the tool accounts.

Next step

For a first pass without being a developer, the production-readiness checklist (in French) asks 30 yes/no questions about data access, secrets, accounts, backups, payments and GDPR. Every “I don’t know” becomes a question for your team.

For an outside view of your code, the app audit applies this method: one light per point, a keep, fix or replace plan, and a one-hour video debrief. If you are unsure which option fits, book a 15-minute call. The call costs nothing and comes with no commitment.

Sources

• Ward Cunningham, “The WyCash Portfolio Management System”, OOPSLA 1992
• Martin Fowler, “Technical Debt Quadrant”
• OWASP, Top 10:2025
• Node.js, release schedule and previous releases
• GitHub Docs, Dependabot alerts and secret scanning
• Supabase, Row Level Security
• DORA, software delivery performance metrics