v0 ships features fast. The same pattern that makes that possible — confident code, idiomatic-looking output, fast iteration — is what hides the risk we read for. We audit v0 codebases line by line, name what's broken, and tell you what to fix first.
Next.js apps deployed on Vercel with Supabase as the default database, often shipped before any backend review.
The database has tables marked as public, or RLS policies of the form `USING (true)`. Anyone with the project's anon key — which is meant to be public — can read or write the full table from a browser. The application looks safe because the UI gates the views, but the data is open by default.
A privileged key (typically Supabase service_role, Firebase admin or a payments secret key) ends up referenced in client-side code. The build pipeline inlines it into the JavaScript bundle, where any visitor can read it from DevTools and bypass every row-level rule the database has.
Endpoints that mutate data — create, update, delete — accept requests without ever checking for a session, JWT or API token. The UI hides the buttons behind a login screen, so the developer assumes the API is protected. It isn't: anyone with curl and the URL can call it.
A query reads by id but never checks that the id belongs to the authenticated user — typically `SELECT * FROM invoices WHERE id = ?` instead of `... WHERE id = ? AND user_id = ?`. Two seeded test accounts can read each other's records by changing a number in the URL.
Any authenticated user can hit the LLM endpoint as fast as their browser will send requests. A loop in DevTools — or a single curious user finding the right textarea — burns through the monthly inference budget in an afternoon.
Knowing the tool that built the code lets us focus the audit. We start by detecting the v0 signature in the codebase, then we read the surfaces where v0-specific failure modes cluster: auth, secrets, data access, dependencies and LLM-touching paths. Five to ten business days from kickoff to written report. No deployment access required — read-only repository access is enough.
Severity-ordered findings with file paths, line references, why it matters and a fix sketch. Readable by both engineering and non-technical stakeholders.
15-minute recording of the report — for the cofounder, investor or director who didn't make the live call.
Live discussion of severity, fix order and the calls that need a human in the loop.
Slack or email for clarifications, fix reviews and a second pair of eyes on the patches.
Typical SMB AI-built codebase, kickoff to written report. Larger or multi-repo audits scoped separately.
Often yes. The single most common v0 finding is RLS misconfig — public tables behind a private-looking UI, anon-key reads of customer data, service_role keys leaked into the client bundle. We start there.
Yes — and after the audit you'll have a checklist of fixes that include a redeploy. We can review the post-fix deployment as part of the 30-day follow-up window.
Sometimes. Each iteration can undo a security fix from a previous iteration if the prompt didn't preserve it. We look for places where the latest version of a file has lost protections that an earlier commit had.
Next.js, Python and full-stack apps with Tailwind, shipped at high velocity by individual developers.
Read more →Terminal-driven, multi-file changes across a codebase — often touching infra, tests and product code in a single agent loop.
Read more →Inline completions across enterprise codebases, mixed with hand-written code from many authors over years.
Read more →We design for privacy from the start, human control, traceability, usage limits, permissioning and documentation. For sensitive processes, we help assess risk and applicable obligations under GDPR and the EU AI Act.
Every engagement is led personally by one of the partners. If there's a fit, you get a personal first read of your case within one business day — not a canned demo.
