AI App Builder Audits · AI Development Series
v0 App Audit
v0 produces the best-looking output of anything in this category. The interface is rarely the problem. What sits behind it is worth a proper look.
What v0 actually hands you
v0 began life as a user interface generator and has grown into something closer to a full application builder. That history matters, because it shapes what tends to be solid and what tends to be thin: the front end is usually excellent, and the data and security layer is usually the part that was added later.
What a v0 application is made of
- Framework Next.js with the App Router
- Frontend React and TypeScript
- Styling Tailwind CSS with shadcn/ui components
- Server logic Server Actions and route handlers
- Database Commonly Postgres, via Neon, Supabase or Vercel
- Hosting Vercel, though the code will run anywhere Next.js does
Next.js blurs the line between client and server more than most frameworks, deliberately. A component can run on the server, a function can be called from the browser as though it were local, and data fetching can happen in either place. When it is understood, this is powerful. When it is generated, it is the single most common source of security mistakes we see in Next.js applications.
The specific thing worth knowing: a Server Action is not a private function. It compiles down to a publicly reachable HTTP endpoint. Anyone can call it directly with whatever arguments they like, whether or not your interface offers them a way to.
What we consistently find
These are the issues that recur in generated Next.js applications, and the first two are close to universal.
Server Actions that trust whoever calls them
Because a Server Action is written like an ordinary function and called like one, generated code routinely treats it as though only the page that uses it can reach it. In reality it is an open endpoint. If it takes a record identifier and acts on it without checking who is asking and what they are entitled to, it will do that for anybody.
The interface never offers a user the chance to delete someone else's record, so it never comes up in testing. Calling the endpoint directly is not difficult, and every action needs to re-establish identity and permission for itself.
What it costs you: any visitor able to read or modify data through actions meant for one user.Secrets published to the browser
Next.js will send any environment variable prefixed with NEXT_PUBLIC_ to the browser, embedded in the JavaScript bundle. That is exactly how it is supposed to work, and it is fine for things like a public site URL.
It stops being fine when a database URL, a service key or a third-party API key ends up with that prefix, usually because it was the quickest way to make something work during the build. Anyone can read it out of the page. We check every variable that crosses that line.
What it costs you: credentials in public, and bills run up on your accounts.Beautiful front end, thin data layer
v0 produces genuinely well-built interfaces — accessible components, sensible structure, good responsive behaviour. The database underneath is frequently an afterthought: tables shaped around the screens that were designed rather than the business being modelled, missing indexes, and no constraints preventing invalid combinations.
This is the finding that determines whether an application can be repaired or has to be rebuilt, so it is worth knowing early rather than after another six months of building on top of it.
What it costs you: a rebuild you were trying to avoid, arriving later and costing more.Caching that serves one user's data to another
Next.js caches aggressively by default, and the rules about what gets cached and for how long are genuinely subtle. Generated code often does not set them explicitly.
The worst case is a page holding personal data being cached and then served to a different visitor. It is uncommon but not rare, it is very hard to spot from the inside, and the consequences are serious enough that we check it on every Next.js application we look at.
What it costs you: one customer being shown another customer's information.Where v0 is genuinely good
v0 is the strongest tool in this category for anything user-facing. The components it produces are well structured and accessible, it uses mainstream libraries rather than inventing its own, and the code is clean enough that a developer can pick it up without wincing.
Genuinely well suited to
- Generating polished interfaces quickly
- Scaffolding a front end for developers to build behind properly
- React and Next.js projects specifically
- Design exploration and iteration
- Adding well-made components to an existing Next.js codebase
Where it needs engineering behind it
- Multiple separate customers whose data must never mix
- Anything holding personal data, health data or payment details
- Applications where every Server Action needs its own permission check
- Data models that have to reflect real business rules
- Anything your business would genuinely suffer without
The honest summary: v0 gives you the best front end of anything in this category, and the quality of the interface can make the application feel more finished than it is. The work that remains is almost always behind it, not in front of it.
Prefer to watch? The short version of who we are and how we work
Do you need an audit?
Get it looked at if
- More than one customer or organisation uses it
- It stores personal data of any kind
- It takes payments or sits near anything that does
- You are using Server Actions and have not audited them individually
- You are about to promote it, launch it, or raise on it
You are probably fine if
- You are the only person who uses it
- It is a static or marketing site with no user data
- It holds nothing you would mind losing or leaking
- It is a throwaway you will rewrite when the idea is proven
Questions about auditing a v0 build
Not automatically. v0 is excellent at producing a polished Next.js interface and weakest at the layer underneath it. What we most often find is Server Actions that run whatever they are asked without checking who is asking, and environment variables exposed to the browser because they were prefixed to be public.
The front end usually is. The data layer is where the risk sits. v0 optimises for something that looks and feels finished, and a convincing interface over an unchecked API is a particular kind of dangerous, because nothing about using it suggests anything is wrong.
No. A Server Action is a public endpoint the moment it is defined, whatever component it sits next to. If it does not check the session and the caller's right to that specific record, anyone who can reach your site can invoke it directly. That check is not added for you.
It happens, and in Next.js there is an extra cause: caching. A response cached without being keyed to the user can be served to whoever asks next. The result is one customer seeing another's dashboard, intermittently, which is unusually hard to reproduce and easy to dismiss.
Not until someone has read the Server Actions and the caching configuration. Under UK GDPR the exposure is yours regardless of what generated the code. This is worth doing before the first real record goes in rather than after.
For a demonstration, generally yes, since presentation is what v0 does best. Under technical due diligence it is more exposed, because reviewers look past the interface at the data layer, which is the thinnest part. Better to know that before the meeting than during it.
It depends what is behind the interface. Our fixed-price audit is £495 + VAT and produces a written list of what needs doing, ranked by severity, with what each involves. If you then have us do the work, the fee is credited back in full.
In one narrow sense, yes: if you only ever used it to generate components and built the backend yourself, there is far less that can go wrong, because it was not making decisions about your data. That is no longer how most people use it. Once v0 is generating Server Actions and database access, it carries the same risks as any other generator, with a few that are specific to Next.js.
The code, in a GitHub repository or as an export, and read-only access to the database. If you are hosting on Vercel, sight of the environment variable configuration is useful too, since that is where several of the common problems live. We will not change anything or deploy anything.
No, and we would rather say so plainly than pretend otherwise. We build with Claude Code and Cursor, with senior developers designing the system, reviewing every change and testing it. What makes us useful here is not v0 expertise, it is that v0 produces Next.js, React, TypeScript and PostgreSQL, which is what we have been building and fixing for years.
Built with something else?
We audit what these tools produce, whichever one you used.
Other AI app builders
- Lovable app audit
- Emergent app audit
- Replit app audit
- UI Bakery app audit
- Bolt app audit
- Base44 app audit
- Firebase Studio app audit
- Databutton app audit
- Rork app audit
- a0.dev app audit
- FlutterFlow app audit
- Bubble app audit
- Glide app audit
- Softr app audit
- Adalo app audit
- Retool app audit
- Appsmith app audit
- Budibase app audit
- ToolJet app audit
- Xano app audit
- Airtable app audit
The audit
Find out what you are sitting on
The AI Code Audit is £495, fixed.
Tell us roughly what you built and how many people use it. If an audit is not the right thing for you, we will say so.
What the report covers:
- Every Server Action and route handler, and what it will do for a stranger
- Environment variables and anything exposed to the browser
- Database structure and whether it fits the business
- Caching behaviour and whether it can leak between users
We reply within one working day.
