How teams use SystemAudit

A codebase audit gets run at four moments: before a fundraise, while assessing an acquisition, after inheriting a system nobody documented, and before AI-generated code meets real users. Each one is the same question asked by a different person — what is actually in here, and what does it put at risk?

Named customer stories are not published here yet. Rather than fill the page with anonymous quotes, this sets out the situations the tool is built for, what a report contains, and what it cannot tell you.

The four scenarios

Before a fundraise

Founders raising a seed or Series A

The situation. An investor is going to run technical due diligence, and you do not know what they will find.

What the audit is used for. Run the audit on your own repository first. Disclosing known issues with a prioritized plan builds credibility; letting an analyst discover them mid-process is what damages a deal.

Do you need a code audit before raising? →What investors look for in a code audit →For startups →

Assessing an acquisition target

Investors, acquirers and corp-dev teams

The situation. You are buying software you did not write and cannot personally review, and the seller controls the narrative about it.

What the audit is used for. Map the architecture and dependency surface before the deeper technical conversations, so the questions you ask in diligence are informed by what is actually in the repository.

Codebase red flags before you acquire →How to read a code audit report →For investors →

Taking over an inherited codebase

New CTOs, and teams after an agency handover

The situation. You are now responsible for a system you did not build, often with no documentation and nobody left to ask.

What the audit is used for. Get the architecture map and the secrets scan before changing anything. Understanding what exists is the work of the first week; improving it comes after.

I inherited a codebase. Now what? →Rewrite vs refactor: the founder's decision →For CTOs →

Cleaning up AI-generated code before launch

Teams who shipped fast with Cursor, v0, Bolt or Replit

The situation. The product works, but it was written faster than anyone reviewed it, and it is about to meet real users.

What the audit is used for. Scan for exposed secrets first, then check whether authorisation actually authorises, then audit the dependencies the AI chose for you.

Is AI-generated code production ready? →Vibe-coded app cleanup before launch →For vibe coders →

What a report contains

A security and secrets scan, with the exact file, line and a redacted snippet for every critical and high-severity finding
An architecture map of the system's components and how they connect
Dependency analysis across nine package ecosystems
Handoff Readiness and Supply Chain Resilience grades
An AI Readiness Grade (A–F) across five dimensions, on paid tiers
A prioritized fix plan with cost-to-fix and cost-if-ignored estimates, on paid tiers

See exactly what each tier unlocks on the pricing page.

What it will not tell you

An audit tool that overstates its reach is worse than no audit tool, because it buys false confidence. Three limits are worth stating plainly:

It does not read your entire repository. The scanner fetches a capped subset of files through GitHub's API — 40, 80 or 150 on the free scan and 80, 160 or 240 on a paid audit, depending on project size — and reports coverage as a ratio, so a report never implies more was read than actually was.
It does not find every vulnerability. It is surface-level, prioritized risk discovery, not a substitute for a penetration test or a deep human review of a high-stakes system.
It does not judge whether your product is a good idea. It reports on the condition of the code, not the merit of the business.

Why you can check our work

The detection engine is MIT-licensed and public, so the rules behind every finding are readable rather than asserted. Every finding is checked against your actual source: anything the analysis cannot tie to a specific file and line is downgraded or dropped before it reaches your report.

Read the scanner source →Who builds this →How we handle your data →

Run it on your own repository

The fastest way to judge whether the output is useful is to point it at code you already know. Free on public repositories, no signup.

Run a free scan Read the code audit guide

Used SystemAudit for something worth writing up? Get in touch — we publish stories with permission and real names, or not at all.