Technical audit of a software product: when you need one and what it covers

A technical audit is an independent review of a product's code, architecture, infrastructure and processes that shows how reliable, secure and ready for growth it is. It is ordered before an acquisition or investment, when changing vendors, or when every change becomes a struggle. The output is a prioritised list of risks and a plan of fixes.

Here is when an audit is needed, what it covers and how to use the results.

When do you need a technical audit?

You need a technical audit when a decision about money or timelines depends on the state of the system and nobody inside the team can look at it independently. It usually happens at turning points in a product's life.

Typical triggers:

• an acquisition or investment — understanding what you are really buying and what it will cost to bring it up to standard;
• changing vendors — taking over a project and learning its real condition before work begins;
• slow development — every new feature costs more than the last, and changes break other parts;
• speed and stability problems — the site slows under load or goes down regularly;
• preparing to grow — before scaling, entering new markets or a major rebuild;
• security requirements — before handling payments or personal data.

What does a technical audit check?

A technical audit checks everything that drives the product's cost of ownership: architecture, code quality, dependencies, security, infrastructure, data and team processes. Each area produces its own list of risks.

Area	What we look at	Typical findings
Architecture	Module structure, coupling, boundaries, integrations	Everything depends on everything; business logic scattered across layers
Code quality	Readability, duplication, standards	Copy-paste, huge classes, no conventions
Tests	Coverage of critical flows, stability	No tests, or tests that do not run
Dependencies	Framework and library versions, known vulnerabilities	An outdated version with no security updates
Security	Authorisation, input handling, secrets, access	Secrets in the repository, access to other users' data
Infrastructure	Servers, deployment, backups, monitoring	Manual deploys, backups never test-restored
Performance	Slow queries, caching, load	Queries without indexes, N+1 problems
Documentation and process	README, architecture docs, reviews, releases	Knowledge lives only in one developer's head

Photo: Unsplash

Tools that speed up an audit

Some checks are automated: dependency analysis, static analysis, secret scanning and query profiling. The manual work is reading key modules, talking to the team and checking how the system behaves in real scenarios.

# Known vulnerabilities in dependencies
composer audit
npm audit --omit=dev

# Secrets accidentally committed to repository history
gitleaks detect --source .

# Slow PostgreSQL queries from pg_stat_statements
psql -c "SELECT calls, mean_exec_time, left(query, 80) FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10"

More on finding slow queries in PostgreSQL indexes, and on the main vulnerabilities in OWASP Top 10 explained.

What does the client get from an audit?

The client gets a report of the problems found, with their risk and the cost of fixing them, plus a prioritised work plan. A good report is clear not only to developers but also to the executive making the decision.

Report structure:

1. An executive summary: overall condition, key risks, a recommendation.
2. Critical issues — fix immediately: vulnerabilities, data loss risks.
3. Significant issues — what slows development and raises maintenance costs.
4. Improvement recommendations with effort estimates.
5. A staged plan: what to do in the first month, quarter and half-year.

How long does an audit take and how do you prepare?

An audit of a typical web product takes us one to three weeks — our own benchmark; the duration depends on code size, the number of services and integrations. Audits go fastest when auditors get access and a chance to ask the team questions from day one.

What to prepare:

• read access to repositories, including history;
• access to a staging environment and, ideally, to monitoring and logs;
• an architecture and integrations overview, if one exists;
• a developer or tech lead who knows the system;
• a list of problems worrying the business, so they get special attention.

What should you do after the audit?

After the audit, fix the critical issues, build the rest into the development plan and repeat the review after a while. An audit without follow-up is just a document that ages along with the code.

A typical post-audit plan:

• immediately — vulnerabilities, secrets in the repository, backups never test-restored;
• within a month — upgrading outdated dependencies, error monitoring, automated deployment;
• within a quarter — refactoring the most problematic modules, tests for critical flows;
• ongoing — regular maintenance so problems do not pile up again.

We covered how to organise regular support and what it costs in website and app support cost.

In short

• A technical audit is an independent review of code, architecture, infrastructure and processes.
• It is commissioned before acquisitions or investment, when changing vendors and when development slows down.
• It covers architecture, code, tests, dependencies, security, infrastructure and documentation.
• The output is a business-readable report with prioritised risks and a work plan.
• An audit's value lies in what happens next: critical fixes now, the rest on a plan.