How to audit a vibe-coded app: what gets checked, and what you should get back

You built it over a few weekends. It's got a login, a database, a payment button and, last week, its first real customer. Then someone asks a question you can't answer: "Is it safe?"

You can't tell by using it. A vibe-coded app looks identical whether the database is locked down or wide open. The demo and the dangerous version are the same thing, which is exactly why AI tools are so good at getting you to "it works" and so quiet about everything after.

We've written about the risks of vibe coding and what it costs to fix. This is the step in between: what an audit actually looks at, and what you should expect to be handed back.

What tends to be wrong

Wiz Research looked at apps built on AI app builders and kept finding the same handful of problems:

• Logins checked in the browser rather than on a server, so anyone who knows where to look can wave themselves through.
• Secret keys sitting in code the browser downloads, where anyone can read them.
• Databases with loose access rules, or none, so the public key in the page is enough to read other people's data.
• Internal tools and test versions left open on the public internet.

A separate audit of 35 AI-built apps, by a firm called Teyrex, found none had rate limiting (so nothing stops someone hammering the login) and none had a meaningful test suite. They sell a different way of building, so read that as a signal, not gospel. But it matches what the first lot found.

What an audit is for

Not to give you a pass or fail. It should answer three questions:

1. Is this safe to run a business on?
2. What has to be fixed now, and what can wait?
3. Do we fix it, or start again?

What gets looked at

Who can see what comes first: how people log in, what they're allowed to do once they're in, and whether the database has rules about whose data is whose. Then where the secrets live, because a key in the wrong place is a bill or a breach waiting to happen.

After that, the less exciting bits that decide whether the app has a future:

• Can you get the code out? Some AI building tools host your app for you. If you can't take the code and run it somewhere else, you're renting.
• Could someone else pick it up? A new developer should be able to get it running without a phone call to whoever built it. That means a readme, a sensible structure and no mystery.
• Is anything tested? Not everything, but the journeys that can never break: signing in, paying, the main thing your app is for.
• How does it ship? If every release is one person pressing a button and hoping, that's a risk too.

What you should get back

A written report, in plain English. What's built, what's solid, what isn't, and what to do next, with each problem explained in terms of what it means for your business, not just a code reference.

It should say what's critical and what can wait. Hand over a list of 40 unranked findings and you've paid for a list of complaints. It should also give you a straight answer on fixing or rebuilding, with the reason. If someone recommends a rebuild, they should be able to say exactly what's wrong with the foundations.

And you should be able to walk away with it. A good audit works whether or not you hire the person who wrote it.

What ours is

Our Tech & Product Audit starts at £700, fixed, agreed before we begin. You get the written report above, and then you decide what happens next, with us or without us. If the app's fine, we'll say so. Some are.

Not sure whether yours is? See the pricing or get in touch.

Sources

• Logins checked in the browser, secret keys in client-side code, loosely configured databases, and internal tools left public, from Wiz Research's study of apps built on AI app builders: Wiz, Common Security Risks in Vibe-Coded Apps
• 35 AI-built production apps audited, none with rate limiting or a meaningful test suite: NoCode.Tech, We Audited 35 Vibe-Coded Apps (reporting an audit by Teyrex, which sells a competing approach to building)