What a $500 Code Audit Report Looks Like (Sample Inside)
Our Vibe Code Rescue starts with a $500 step: a written audit of your codebase within 48 hours, then a flat-price plan for the work. Below is a sample report. It's built from a real codebase we took over after it was written mostly by AI coding agents. The six findings are real. Names and product details are changed, and the wording is written for this post. If the findings sound familiar, we told the story of that rebuild in We inherited an AI-generated codebase.
A useful audit answers two questions for a founder: what's dangerous right now, and what it costs to make the product safe to grow. Everything in the report serves one of those.
What the $500 buys
- A written report within 48 hours of repository access.
- Every finding rated by severity, with the evidence and a verdict: keep, fix or replace.
- A plan split into phases, each with one fixed price and a definition of done.
The audit covers the places AI-built code tends to break: authorization and data isolation, secrets, money handling, uploads and background jobs, deploys, observability and tests.
What it leaves out on purpose: linter output, style opinions, a rewrite pitch and a 60-page PDF nobody finishes. If a finding wouldn't change what you do next month, it isn't in the report.
The sample report
Everything from here to the plan is the sample, laid out the way the client receives it.
Summary
The product is a multi-tenant platform. Organizations invite their community to send in media, which the system processes in the background. It's live with customer organizations and was built mostly with AI coding agents.
The part users see is in good shape. The screens and flows match what organizations need, and we'd keep them. The foundation underneath is not safe to grow on. Three findings are critical: one organization can reach another's data, authorization is decided route by route, and live secrets sit in the repository.
Our recommendation: close F1 to F3 before onboarding another organization. Then rebuild the upload pipeline and put a real release process in place.
Severity scale
- Critical: someone can see or change data they shouldn't, today. Fix before anything else.
- High: the core flow fails for real users, or a bad release can't be undone.
- Medium: it slows every change and hides the next bug.
Findings
| # | Finding | Severity | Verdict |
|---|---|---|---|
| F1 | Users in one organization can read another organization's data | Critical | Replace |
| F2 | Authorization is decided route by route, with no single rule set | Critical | Replace |
| F3 | Live secrets are hardcoded in the repository | Critical | Fix |
| F4 | Uploads and background processing fail on real files and networks | High | Replace |
| F5 | There is no deploy process | High | Replace |
| F6 | There are no tests | Medium | Fix |
Draft the findings table for your codebase
Tell ChatGPT how your product was built and who uses it. It will draft a findings table in this format for your stack, with a likely severity and a quick check for each row.
“|”
One finding in full
Every finding in the report gets an entry like this one.
F1. Users in one organization can read another organization's data. Critical. Replace.
Reproduce: sign in as a member of organization A and request a record that belongs to organization B. The record comes back.
Why it happens: organization scoping lives in application code, so every new query has to remember it. Code written one feature at a time forgets it somewhere, and one missed query is enough.
Fix: enforce organization scoping below the application, in a data-access layer or with database row-level security, so a query without an organization can't run. Add a test on every build that signs in as A and tries to read B.
Why replace and not fix: patching the missing filters one at a time leaves the next new query exposed. The rule has to move to a layer every query passes through.
The other five, shorter
F2, critical, replace. Signing in works. Deciding what a signed-in user may do doesn't, because no single place decides it and each route makes its own call. We'd replace it with one server-side authorization layer that every route goes through, with the rules written down in one place. Checks on the client are for display, never for access.
F3, critical, fix. The code that uses the keys is fine. The keys themselves are compromised: every key ever committed counts as leaked, including ones later moved to environment variables, because git history keeps them. Rotate all of them in the first 48 hours. Then move them to a secrets manager and scan the history.
F4, high, replace. Small files on fast connections go through. Long recordings from phones on weak signal don't, and that's where real users live. The replacement sends uploads straight to storage in pieces that survive a dropped connection. Processing becomes a background job with retries, and every item shows its status.
F5, high, replace. Code reaches production by hand, and nothing written down says how to do it again or how to undo it. There's nothing to fix here, only something to build.
F6, medium, fix. On its own, missing tests is a medium. It's also the reason every other fix is risky. We don't recommend a coverage target. We recommend tests on the paths where a failure costs trust, starting with organization isolation and the upload flow, written alongside F1 and F2 rather than after.
Keep, fix, replace
- Keep: the screens, the flows organizations already use, and the product decisions behind them.
- Fix: secrets (F3) and tests (F6).
- Replace: authorization (F2), organization isolation (F1), the upload and processing pipeline (F4) and the release path (F5).
Most of what users see stays. Most of what they don't see gets rebuilt.
Want this report for your codebase?
Rescue audit and plan from $500: a written report in 48 hours with every finding rated and sorted into keep, fix or replace, then a flat-price plan for the work. Send your email and we'll set up a 30-minute call within 24 hours.
The plan
| Phase | What's in it | Done means |
|---|---|---|
| 0. First 48 hours | rotate every key, close access that shouldn't exist | no key that was ever committed still works |
| 1. Foundation | one authorization layer, organization scoping below the app, tests for both | the cross-organization test runs on every build and passes |
| 2. Core flow | resumable uploads, background processing with retries, visible status | a long recording over a throttled connection arrives and gets processed |
| 3. Release path | pipeline, staging, migrations inside the deploy, one-step rollback | a release and a rollback both run from the pipeline, with nobody's laptop involved |
Each phase has one fixed price in the real report. We've taken the prices and dates out of this sample, because they came from that codebase and wouldn't tell you anything about yours. For scale, a focused rescue runs $500 to $12.5K.
That's the end of the sample.
What to demand from any code audit
Ours or anyone's, a report worth paying for has these five things:
- A severity on every finding, defined in terms of what can happen to your users.
- A way to reproduce each critical finding yourself.
- A keep, fix or replace verdict, so you know what survives.
- A plan in phases, with a price per phase instead of an hourly estimate.
- A definition of done for each phase that you can check without trusting the vendor.
If the report you're holding is missing two of these, it's a list of opinions.
Related reading
- We inherited an AI-generated codebase. Here is what we found: the same six findings, told as a rebuild story
- Getting your code back: what to demand before you walk away: the access an auditor needs before the 48 hours start
- Anatomy of a vibe-coded SaaS: what these codebases tend to look like inside
The service: Vibe Code Rescue. If your app was vibe-coded: vibe-coded app rescue. Weighing a rebuild: agency transfer vs rebuild.
Enjoyed this article? Share it with others
Related Posts
Anatomy of a Vibe-Coded SaaS: Eleven Things You Can Grep For Before Lunch
You don't need to read every file of a vibe-coded SaaS to know how it was built. Eleven greps, about thirty minutes: six show how the project was run, five find damage that breaks production or leaks data. Commands included.
We Don't Reject AI. We Use It Like Surgeons.
We write production code with AI agents every day, and we get hired to take over codebases that agents wrote with nobody steering. The tool is the same. Here is what we hand the agent, what never leaves a human, and the one rule behind both.
Seven Defects We Check First in Any Vibe-Coded App (proposed; old title in the notes)
AI coding tools make the same mistakes because they get asked the same questions. Here are the seven defects we look for first in a vibe-coded app, from paywalls enforced in the browser to AI features with unguarded tools, and a check for each.