Code audit · Technical due diligence

A senior engineer reads your codebase and tells you, in writing, what will break.

For software you are about to ship, buy, fund or inherit. We read the code rather than run a scanner over it, and deliver a ranked report with file-level references, concrete failure scenarios and an effort estimate for every fix. Three to seven days, fixed price, no obligation to hire us for the fixes.

Read-only access is enough · NDA on request · Reply within one business day

When you need one

Five moments where reading the code first saves real money

Before you buy or invest

Technical due diligence for an acquisition, a funding round or a joint venture. You get an independent view of what the asset actually is, what it will cost to maintain, and which claims in the deck the code does not support.

Before you launch

An MVP is about to meet paying customers. Find the authorisation gap, the exposed key and the query that times out at 10,000 rows before a customer does.

After a vendor or freelancer hand-off

The agency delivered and left. Before your team commits to maintaining it, know what you have been handed and what the first three months of ownership will cost.

When an AI tool built most of it

Codebases produced with Cursor, Lovable, Bolt, v0 or Replit have a recognisable set of problems. The audit is the first step of every rescue engagement.

Before a compliance or security review

An enterprise customer's security questionnaire, a SOC 2 or ISO 27001 effort, a GDPR question. Know your gaps before the auditor finds them for you.

Before you scale

Traffic is about to grow ten times. Find the parts of the system that were designed for one region, one tenant or one server while there is still time to change them.

Scope

What we examine

Eight areas, every time. We read handlers, middleware, data access and infrastructure configuration line by line. Automated scanners run too, but their output is the starting point, not the report.

If a prior audit exists, we check each of its findings against the current code and report which are still open. That alone is often the most useful page.

ArchitectureService boundaries, coupling, duplicated logic across services, contracts between frontend and backend, what breaks when one part fails.
SecurityAuthentication and, above all, authorisation on every data path. Secrets in code or client bundles. Injection via SQL, shell or templates. SSRF, CORS, cookie and token handling, rate limiting, dependency vulnerabilities.
Data layerSchema and migrations, indexes against the real query patterns, N+1 queries, unbounded result sets, transactions, backups and whether a restore has ever been tested.
Reliability & operationsError handling, timeouts and retries on outbound calls, concurrency and race conditions, resource leaks, health checks, logging, monitoring and alerting, deployment and rollback.
Code qualityDead code, god functions, inconsistent error handling, magic values, commented-out blocks, how hard it is for a new engineer to change something safely.
TestsWhat exists, whether it runs, whether it covers the paths that carry money and permissions, and what is glaringly untested.
Dependencies & licensingOutdated or abandoned packages, known CVEs, licence terms incompatible with commercial use, pinned versions and reproducible builds.
Delivery processRepository hygiene, CI, environments, how a change gets from a laptop to production, and what a bad deploy costs.
Deliverable

What the report looks like

One document per service or module, plus a summary you can hand to a board or an investor. Every finding is written so that an engineer who has never seen the codebase can go straight to the line and fix it.

  • Executive summary: overall health, the three things to fix first, total estimated effort
  • Findings grouped critical, high, medium, low, each with file and line, a quoted snippet, the concrete failure scenario and a fix
  • Status of every finding from any previous audit: still open, fixed, or partially fixed
  • Code smells and maintainability notes, kept separate from the risk findings
  • Test coverage notes and a short list of what the team does well
  • A 45-minute readout call to walk through it and answer questions
Example finding (format)Critical
[API-004] Team ID taken from request header, not from the session
api/remediation_handler.go:142
What. The handler reads X-Team-ID from the request and uses it to scope the query. Nothing verifies the authenticated user belongs to that team.
Why it matters. Any logged-in user can set the header to another team's ID and list, create or execute remediation actions on that team's agents. This is a cross-tenant command-execution path.
Fix. Resolve team membership server-side from the JWT subject; reject requests where the header does not match a team the user belongs to. Apply the same helper across the eleven handlers listed in Appendix B.
effort: 1–2 daysaffects: 11 handlersprior audit: still open
Illustrative format. Identifiers and paths are examples, not from a client engagement.
How it runs

Scoping call to readout in about a week

01
Scoping call, 30 min. What the system does, size of the codebase, what you are worried about, what decision the audit informs. Fixed price the same day.
02
Access. NDA if you want one. Read-only repository access, and ideally read-only cloud console and a staging environment. No production credentials, no customer data.
03
Review, 3 to 7 days. We read. If we find something actively exploitable on day one, you hear about it on day one, not in the report.
04
Report and readout. Written report delivered, then a 45-minute call. You own the document and can take it anywhere.
Pricing

Fixed price by codebase size

The price is set after the scoping call and does not change. It does not depend on whether you hire us for the fixes afterwards.

CodebaseDurationPrice
Up to 25k lines, one service3 daysfixed
25k to 100k lines, a few services4–5 daysfixed
Larger or multi-team systemsscopedper module

Ask for a number. You get it within a business day.

FAQ

Questions about code audits

What does a code audit include?

A senior engineer reads the code, the infrastructure configuration and the data model, then delivers a written report covering architecture, security, data layer, reliability and operations, code quality, test coverage, dependencies and delivery process. Every finding has a severity, a file and line reference, a concrete failure scenario and an effort estimate for the fix.

How long does a code audit take?

Three to seven working days depending on codebase size. Under 25,000 lines is typically three days; up to 100,000 lines four to five days; larger codebases are scoped individually and may be split into modules.

What access do you need?

Read-only access to the repository and, ideally, read-only access to the hosting or cloud console and a staging environment. We sign an NDA first if you want one. We do not need production credentials or customer data.

Is this the same as a penetration test?

No. A penetration test probes a running system from the outside. A code audit reads the source and finds the class of bugs a pen test misses: authorisation logic errors, secrets in the repository, unsafe shell or SQL construction, data-layer problems that only appear at scale, and maintainability issues. The two are complementary; we can arrange both.

Do you also do the fixes?

If you want. The audit stands on its own and you can take the report to any team. Many clients ask us to continue into a rescue engagement or a retainer, but there is no obligation and the audit price does not depend on it.

Can you audit an app built with AI tools?

Yes, and it is a large share of what we audit. Apps generated with Cursor, Lovable, Bolt, v0 or Replit have a recognisable set of problems around authorisation, secrets handling, input validation and deployment. See our dedicated page on rescuing vibe-coded apps.

Contact

Request an audit

Tell us what the system does, roughly how big it is, and what decision the audit needs to inform. An engineer replies within one business day with a scoping call slot and a price.

NDA on request · Read-only access is enough

We use what you send only to reply to you. No newsletters, no sharing. See the privacy policy.