Build Log: What We Actually Find When We Take a Vibe-Coded App Apart

I am Ishan, I run DappaSol, and a lot of our week is spent taking AI-built apps apart to see what is really inside. Before anything else, the framing: this is the pattern across our audits, a composite. No single client is described here, and nothing is invented. The reason I can write it as one story is that it keeps being the same story.

The first hour

Every Week-1 Build Audit starts with the same three checks, because they find the worst problems fastest:

1. Query the database with the public anon key. On a Supabase app with row-level security off, select * from users just works, from anyone’s browser, for every table. This is the single most common critical finding we see, common enough that we wrote a dedicated RLS hardening guide.
2. Grep the built JavaScript bundle for keys. Not the source, the shipped bundle. AI-generated code routinely inlines OpenAI, Stripe and service keys client-side, where anyone who opens devtools owns them. The pattern is widespread enough that we documented it in exposed API keys in AI-built apps.
3. Call the API directly, skipping the UI. A login screen is not authentication. We regularly find auth that only exists in the frontend: hide the button, gate the route in React, and the server trusts whatever arrives. One curl command demonstrates it.

When an app fails all three, the founder usually already suspected something. The demo felt too easy.

The rest of the week

Past the first hour, the audit works through the slower layers, and the recurring findings stack up:

• Unmetered AI endpoints. An endpoint that calls a paid model with no rate limiting is an open wallet: a for-loop away from someone running their token bill through yours.
• Secrets in git history. Rotated keys that live forever in an old commit. The current code looks clean; the history does not.
• Admin by obscurity. Admin panels protected by an unlinked URL rather than a permission check.
• Demo seed data in production. Test users, fake orders and placeholder content sitting in the live database next to real records.
• Nothing watching. No error monitoring, no logs worth reading, so the first alert about any of the above would have been a customer, or a screenshot on social media.

The full checklist we work through is published in the AI code security checklist and the OWASP top 10 for vibe-coded apps. We keep those public on purpose: run them yourself and you will find a real share of what we would find.

What usually survives

Here is the part that surprises founders: most of these apps are worth saving. The product decisions, the flows, the UI, the thing users said yes to, all of that usually survives. What gets rebuilt is the part users never saw: auth, security, the data layer. Building the prototype in Lovable or Bolt was the cheap way to find out what to build, and that value is real. The fix or rebuild guide covers where the line sits.

The verdict distribution across our audits, roughly: most apps are hardenable, a minority need the rebuild-grade MVP Sprint from $7,500, and a small number are one curl away from a very bad week and need the audit report treated as an incident list.

If this sounds like your app

Start free: the production readiness check takes minutes, and the AI code security audit covers the security slice specifically. When you want the whole truth in writing, the Week-1 Build Audit is $500 flat, takes one week, is credited against any build, and carries the guarantee: every blocker found or it is free. Book a 15-minute intro call and bring your repo. The first hour is usually enough to know.