A code audit is not a verdict on your developers. It is a risk assessment
A conversation about a source code audit usually starts with one of four sentences: "our investor is asking for due diligence", "we're taking over a project from another software house", "every new feature takes longer than the last" or "I don't know whether what we have can be developed any further". Four different business situations, one common denominator — someone has to make a financial decision and doesn't have the technical data to make it.
And that is the proper definition of a code quality audit. It isn't a beauty contest for code or a review of the team's work. It translates the state of the repository into the language of risk, cost and time: what could cause an outage, what is slowing development down, how much fixing it will cost and what can safely be left alone.
In this article we describe what such an audit looks like from the inside — what exactly we check, what we need from the client, how long it takes, what you get at the end and when an audit is not worth it.
When a code audit makes sense
Before an investment or acquisition (technical due diligence)
The most common scenario, and one with a hard deadline. The investor or buyer wants to know whether they are buying a product or a liability. The questions are specific: can the code be developed further without a rewrite from scratch, are there any licensing or legal time bombs, is the team replaceable, are production secrets sitting in the repo, and what will maintenance realistically cost over the next two years.
Here, an audit rarely changes the "buy / don't buy" decision — it changes the price and the terms. The risks we find end up on the negotiating table as a discount or as conditions precedent.
When taking over a project from another team
We step into someone else's repository and have to answer the question nobody likes asking out loud: keep developing or rewrite. Without an audit, that decision is made on gut feeling — and developers' gut feelings are strongly biased towards "let's rewrite it from scratch".
When velocity drops and nobody knows why
The symptoms are distinctive: estimates grow for similar tasks, every release drags regressions along with it, and the team increasingly says "we'd need to clean that up first". We covered them in more depth in 5 signs your mobile app is quietly dying. An audit tells you how much of the slowdown is technical debt and how much is a process problem or a lack of people.
Before a major change — a refactor, a migration, scaling
If you're planning to rewrite the frontend, switch databases, enter a new market or prepare for ten times the traffic, the audit is your baseline: a reference point that lets you measure later whether the change actually improved anything.
After a year of working with AI assistants
A new but already very common trigger. Code is being produced faster than anyone can read it with understanding. The patterns we find most often in these projects — missing input validation, secrets in the repo, N+1 queries, dead tests — are collected in a separate article: AI-written code in production.
What we check — six areas
A good audit isn't a list of "missing semicolon here". It has a fixed structure, so projects can be compared and nothing slips through the cracks by accident.
1. Architecture and system boundaries
We start at the top, because that's where the most expensive mistakes live. We want to know whether the system has clear module boundaries, whether business logic is smeared across controllers and UI components, whether dependencies flow in one direction, and whether a piece of the system can be extracted without dismantling the rest.
A practical test: how many files do you have to touch to add a typical feature. If the answer is "it depends, but usually a dozen or more across four layers", the architecture is a cost, not a foundation.
2. Code quality and readability
This is where metrics come in, but we treat them as indicators, not verdicts: duplication, cyclomatic complexity of hotspots, file and function size, consistency of conventions, dead code. On top of that comes a manual review of the hottest areas — the files that change most often and also have the highest complexity. That is usually 5–10% of the repository, and it generates most of the bugs.
Separately, we check whether the project has a working mechanism for maintaining quality at all: a linter in CI, formatting, and code review with real comments rather than rubber-stamping PRs.
3. Security
A dependency scan for known vulnerabilities, a review against the OWASP Top 10, authorisation and authentication (the most common finding: permissions checked in the UI instead of on the backend), secrets management including a scan of the Git history, production configuration, and handling of personal data.
It's worth repeating something many teams discover too late: removing a secret in a later commit doesn't remove it. The key stays in the history and you have to assume it has leaked — the only correct response is rotation.
4. Performance and costs
Database queries (the classic N+1, missing indexes, unbounded queries), API response times, bundle size and Core Web Vitals on the web side, cold start and memory usage in mobile apps. Plus the cloud bill — surprisingly often the largest line item is something nobody consciously designed: excessive logging, cross-zone data transfer or an instance forgotten after a migration.
Most of the bottlenecks that look like a "slow interface" in a mobile app actually sit in the backend and API.
5. Tests and CI/CD
We don't ask "what's your coverage", but "do these tests protect anything". We read the assertions, check whether the tests verify nothing but mocks, and look at tests for critical paths — login, payments, placing an order. We also check how long the pipeline takes and whether the team trusts a red build or has learnt to ignore it.
On the CI/CD side: release automation, reproducible environments, the ability to roll back, and time from merge to production.
6. Operations, documentation and people risk
Monitoring and alerts (do you find out about an outage from the system or from a customer's phone call), logs, backups — and above all, whether a backup has ever actually been restored. Then the bus factor: how many people understand the key parts of the system, whether onboarding a new developer is documented, and whether access can be handed over without depending on one specific person.
In regulated projects there's an additional compliance layer — GDPR and, since June 2025, the accessibility requirements of the European Accessibility Act, which in practice means WCAG 2.2 at level AA.
How it works and what we need
A typical technical audit takes 1–2 weeks. It can't be done properly in less, and going longer rarely makes sense — after two weeks, further findings stop changing the picture.
The process looks like this:
- Day 0 — scope. We agree on the business question. An audit before an investment and an audit before a refactor are two different documents.
- Days 1–2 — access and orientation. The repository with its full history, CI access, environment configuration (without production secrets), documentation if it exists, and access to monitoring.
- Days 2–4 — interviews. 45–60 minutes with the tech lead, the same with someone on the business side and, where possible, short conversations with 2–3 developers. This is the most underrated part of an audit: the team usually knows where the bodies are buried — it's just that nobody has asked them in a way that doesn't sound like looking for someone to blame.
- Days 3–8 — analysis. Automated tools plus a manual review of hotspots, running the project locally, and tracing 2–3 critical paths end to end.
- Days 8–10 — report and walkthrough. A document plus a meeting where we go through the priorities and answer questions.
What we need from the client: access to the code with its history, an hour of the tech lead's time and honesty about what hurts. What we don't need: access to production data or a polished story about how things were supposed to be.
What you get at the end
A report that can be read in two modes. The board reads the first two pages; the technical team reads the rest.
- Executive summary — overall condition, the three biggest risks and a one-sentence recommendation.
- Prioritised list of findings — each with a description, evidence (a specific file, query or screenshot), the real business impact and a fix estimate in person-days.
- Priority map — what's blocking, what's urgent, what can be scheduled and what we're deliberately leaving alone. That last category matters as much as the first: an audit that doesn't say what doesn't need doing turns into a wish list.
- 30/90-day remediation plan — the order of work, with the dependencies between tasks.
- An answer to the original question — keep developing or rewrite, buy or don't buy, is a refactor enough or is a rebuild needed.
What the report doesn't contain: assessments of individuals, a list of grievances against the previous vendor, or a recommendation to rewrite everything from scratch. The last of these is almost always the most expensive and worst answer — if we do propose it, we have to back it up with numbers.
How much it costs — and what really drives the price
We price a code audit by time, not by lines of code. As a reference point: one to two weeks of work by an experienced engineer (two engineers for larger systems), plus time for the report and walkthrough. For a typical web or mobile app with a backend, that comes to a cost comparable to 2–4 weeks of one developer's work.
Three things genuinely affect the price: the number of separate systems in scope (an app + backend + admin panel + integrations is four things, not one), depth — a review alone, or penetration testing and load performance analysis as well — and the form of delivery: just the document, or the document plus a workshop with the team.
Comparing that figure with the cost of a wrong decision is usually a no-brainer: a misguided refactor costs a quarter of the team's work, and a bad investment costs an order of magnitude more than the audit. We apply similar logic when quoting projects; we described it in our article on what to ask when getting a quote.
When an audit isn't worth it
Three situations in which we honestly advise against it:
- The decision has already been made. If you're rewriting the system regardless of the outcome, the audit is an expensive confirmation. That money is better spent on designing the migration.
- The project is less than a few months old and has a single source of truth. For a fresh MVP, a one-off code review or an architecture consultation is usually enough.
- The problem is organisational, not technical. If the team knows what to fix but isn't given time to do it, an audit won't change a thing — it will just be another document nobody implements. In that case, an ongoing retainer that gives you arguments in the conversation about priorities makes more sense.
In the first two cases it's worth considering a lighter format: a consultation of a few hours instead of a full audit.
An audit is the beginning, not the end
The biggest waste in this category is a report that goes into a folder after the presentation and stays there. An audit only pays for itself once its findings turn into backlog items with owners and deadlines.
That's why at Mobilesoft an audit rarely ends with the document. It often leads into rescue & refactor — a four- to eight-week hands-on engagement with a project in crisis — or into ongoing collaboration: weekly code reviews and a second pair of eyes before each release. If you'd like to gauge the scale of the problem yourself first, go through our 15-point checklist; if you'd rather see how we work in practice, take a look at our case studies and how we approach building mobile apps.
And if you have a specific repository and a specific question you need to answer within the next month — get in touch or go straight to getting a project quote. The first conversation is usually enough to tell whether you need a full audit or whether an hour's consultation will do.