What does a proper AI codebase audit actually check?

Five things, at minimum: security (Row Level Security correctness, not just presence; secrets scanned across the full git history; auth boundaries; storage exposure), architecture and platform lock-in, whether features are real or placeholder stubs, test coverage as measured rather than assumed, and whether deployment and rollback actually work. A report that skips any of these and leans on a generic tool-output dump is not a full audit.

Do I need a codebase audit if my app has no real users yet?

Usually not. If you are still validating the idea, have no paying customers, and nothing you'd lose sleep over if it broke, an audit is money spent on certainty you don't need yet. The trigger points are raising money, onboarding your first real customers, inheriting an AI-built app someone else wrote, or facing a specific security question you cannot answer yourself.

How is a codebase audit different from running an automated scanner?

An automated scanner checks whether a control exists — is Row Level Security switched on, is there a test file present. It does not check whether the control is correct. A policy of USING (true) is enabled, passes a scanner, and returns every row in the table to anyone holding the public key. A real audit reads the policy against the roles it's meant to separate, which nothing currently automates.

What's a red flag when choosing who does the audit?

A price quoted before anyone has read the code. A report with no reproducible findings — no file, no table, no line you can go check yourself. A report that is mostly a pasted tool dump. A recommendation to rewrite before the auditor demonstrates they understand what the product actually does. And no real security depth beyond a checklist. Any one of these is worth asking about before you pay.

The AI Codebase Audit: What It Covers, What It Costs, When You Need One

The short version

Skip it if your app is a weekend project, has no real users yet, or you're still validating the idea. An audit is money spent on certainty you don't need yet.
Get one if you're raising money, taking on your first real customers, inheriting someone else's AI-built app, or facing a security question you can't answer yourself.
The evidence standard is reproducible findings — a file and a table reference, not a slide of adjectives. A finding you can't reproduce is an opinion.
UK day-rate medians put this work in a checkable band. A multi-week, five-figure quote for a two-month-old app is usually scope inflation, not diligence.

When you actually need one

Four situations reliably justify paying for an outside technical read, because in each of them the cost of being wrong is no longer just yours to absorb:

Raising money. An investor, or their technical diligence contact, will ask a question about your codebase you cannot answer with confidence — what happens if this fails, who can see whose data, what breaks at 10x load. An audit gives you an answer you can defend in the room, not a guess.
First real customers. The point where user data starts landing in the database — real emails, real payment details, real documents — is the point where "it seems to work" stops being an acceptable security posture.
Taking over someone's AI-built app. A founder, a departing contractor, or an agency handed you a codebase with no institutional memory attached. You need to know what's actually there before you commit to building on top of it.
A security question you genuinely can't answer. "Is this safe to launch" is a specific, checkable question, and if nobody on your team can answer it with evidence, that's the gap an audit fills.

None of these need a large team or a mature product — a two-month-old app raising a seed round qualifies just as much as a three-year-old one. What they share is a decision behind the question, where being wrong is expensive.

When you don't

If your app is a side project with no users, or you're still testing whether anyone wants the thing at all, an audit is premature. Code you might throw away next month doesn't need a risk-ranked remediation plan — it needs you to keep shipping and find out if it's worth keeping. The same goes for a team that already has a senior engineer capable of reading their own Row Level Security policies and git history; paying an outsider to confirm what you already know is theatre, not diligence. Spend the money when the answer starts to matter to someone other than you.

What a real audit covers, versus a shallow one

The difference between a real audit and a shallow one is not effort or price — it's whether the findings are checked against the actual system, or against what the system is supposed to do.

Security: correctness, not presence

A shallow review checks whether Row Level Security is switched on. A real one reads what each policy actually permits. In 2025, researchers confirmed CVE-2025-48757 — 170+ live apps built on one popular AI platform exposing data publicly because RLS was missing or, in many cases, technically enabled but functionally useless: a policy of USING (true) passes an automated scan and returns every row in the table to anyone holding the public key (Superblocks). This is not an isolated platform problem. Veracode's 2025 study across 100+ models found AI-generated code chose the insecure implementation roughly 45% of the time, with no meaningful improvement in newer models (Veracode). A real audit reads policies against the roles they're meant to separate, scans the full git history for secrets (a key committed early and later "removed" is still live in history), checks which server functions hold privileged keys or skip auth verification, and traces the two or three riskiest flows — sign-up, role assignment, anything touching money — end to end.

Architecture and platform lock-in

What's genuinely portable versus what only runs inside one vendor's platform is a factual question, not a vibe. A real audit states plainly which parts of your stack you own outright, which depend on a vendor's managed database or AI gateway, and what leaving would cost in developer-days.

Real versus placeholder

AI tools are fluent at producing code that looks finished — a settings page that renders, a button wired to nothing, an integration returning mock data. A shallow review reads the UI and assumes what it sees is what ships. A real one traces each claimed feature to the code path that actually executes, and says plainly which parts of the product are real.

Test coverage, measured

"We have tests" is not a number. A real audit runs the suite, reports what percentage of the codebase it actually exercises, and states which critical paths — payment, auth, data deletion — have none. Coverage claimed from memory or a README is not evidence.

Deployment and rollback, tested not assumed

The last shallow-review gap shows up at the worst possible time: can this app actually be redeployed and rolled back, or does "deployment" mean clicking a button in a platform UI with no record of what ran and no way back if it breaks. A real audit checks whether a bad release can be undone in minutes, not discovered as a gap during the first incident.

The evidence standard

Every finding in a real audit should be reproducible: a specific file, a specific table, a specific policy, a command you can run yourself and get the same answer. If a report tells you "security needs work" with no file reference, that's an opinion, not a finding — and opinions are cheap to produce and expensive to act on. Ask any audit provider, before you pay them, whether their findings will be reproducible by someone else reading the same repository. If the answer is vague, that's your answer.

Red flags in an audit provider

A number before reading the code. Nobody can price this work honestly without first seeing what's actually there.
No reproducible findings. If a claim can't be checked against a specific file or table, it isn't a finding.
A report that's a tool dump. Pasted output from a linter or a scanner, with no interpretation of what it means for your specific product, is not an audit — it's a screenshot.
Recommending a rewrite before demonstrating understanding. If the first conclusion is "start again" and it arrives before any evidence that they understood what the product does, that conclusion is about their pipeline, not your code.
No real security depth. A checklist that confirms controls exist, with nothing on whether they're correctly scoped, misses the class of bug that actually causes breaches.

Questions to ask before you buy

Will every finding come with a file, table, or line reference I can check myself?
Do you check whether Row Level Security policies are correct, or only whether they're enabled?
Will you scan the full git history for secrets, not just the current branch?
Is the fee fixed once you've seen the repository, or does it change afterwards?
What's the deliverable — a written report I can share with investors or a board, or a call?
If the honest verdict is "this is fine as it is", is that what the report will say?

If you want a straight answer

Appaya's own audit works on the standard above: security reviewed for correctness rather than presence, architecture and lock-in stated plainly, real-versus-placeholder traced through the actual code paths, test coverage measured rather than assumed, and every finding attached to evidence you can check yourself. It's one fixed fee, agreed at a fit check once your codebase's scope is clear — not a number produced before anyone has read your code.

How the audit works Request a fit check

If your app is specifically built on Lovable or Base44, the platform-specific guides go deeper on lock-in and migration: moving off Lovable and Base44 — stay or migrate.

The AI codebase audit: what it covers, what it costs, when you need one