Your Vibe-Coded MVP Just Got Real Users

The pattern is familiar by now: a founder builds a working product over a weekend with Cursor, Lovable, Replit, or Claude, the demo looks and feels finished, and it goes out into the world. Then real users show up — or real data, or a funding conversation, or a partner asking for security details — and the app that worked perfectly for a handful of friends starts failing in ways nobody anticipated. This isn't a rare edge case anymore. It's common enough that a specific category of engineering work has formed around it, and there's now real research showing exactly what tends to break, and why.

What "breaks" actually looks like

In September 2026, security firm Symbiotic Security scanned 1,072 confirmed vibe-coded applications built on Lovable, v0, Bolt.new, Replit, Windsurf, and Tempo, all running on Supabase backends. The methodology was thorough — 65,643 URLs crawled across 19 discovery sources, then run through 80 automated security checks covering key exposure, row-level security, headers, CORS, and JWT handling. The result: 98% of the applications had at least one security flaw. Only 26 out of 1,072 came back clean.

The severity breakdown from the Symbiotic Security scan is the part worth reading twice: 172 sites allowed anyone to delete records from the database with an unauthenticated call, 172 more allowed unauthenticated modification, and 39 had tables fully readable by anyone holding the public API key — meaning user data, payments, and private messages were sitting in the open. In nearly every case, the root cause was the same: a Supabase (or similar) API key shipped in client-side JavaScript with row-level security never turned on. It's the kind of oversight that costs a few minutes to fix and, left unfixed, hands over the entire production database.

This isn't hypothetical — three incidents from the last few months

In February 2026, security researcher Etizaz Mohsin demonstrated a zero-click exploit against Orchids, an AI app-building platform, live with a BBC journalist as the test subject. Mohsin slipped one line into the AI-generated code for a project the journalist had built, and within moments had full remote control of the journalist's laptop — wallpaper changed, a file titled "Joe is hacked" placed on the desktop — without the journalist clicking anything at all.

Around the same period, Amazon — hardly a startup with a weekend prototype — ran into its own version of this problem after mandating that 80% of its engineers use its internal AI coding assistant weekly. Between December 2025 and March 2026, Amazon logged at least four Sev-1 production incidents tied to a trend of AI-assisted changes, including a six-hour outage on its retail site that blocked checkout and account access for millions of customers. Amazon's response was telling: a 90-day "code safety reset" across 335 critical systems and a new requirement that senior engineers sign off on AI-assisted code before it ships.

And in one of the more direct examples of the pattern this article is about: researchers at RedAccess found a Supabase API key exposed in the client-side code of a vibe-coded customer intake form, built over a weekend, deployed publicly, and indexed by Google — one of roughly 5,000 similarly exposed apps in their sample holding real sensitive data, from hospital patient summaries to bank financial records. It's now tracked as CVE-2025-48757: insufficient row-level security across more than 170 Lovable-generated Supabase projects.

Why the demo works and production doesn't

None of this is really about the AI models being bad at coding — they're good at producing something that runs. What they're not optimized for is the invisible layer experienced engineers add by habit: input validation, authentication checks on every route (not just the ones you tested), rate limiting, error handling for the request that doesn't look like the happy path, and — the one that shows up again and again in the research above — actually turning on row-level security instead of trusting the client. A demo only ever exercises the happy path. Real users, by definition, don't.

The fix is smaller than you think — if you catch it early

The good news buried in all of this: fixing it is rarely a rebuild. It's a hardening pass — someone who didn't write the original code going through it with the specific, well-understood list of things vibe-coded apps tend to get wrong: RLS and auth policies, secrets management, input validation, error monitoring, and a real test suite where there wasn't one. The scope of that work maps closely to what we already price as standalone engagements: a Backend & Database Setup pass (real-time sync, RLS policies done properly) runs $2,000 over 2–4 weeks; folding in a proper dashboard or admin UI on top brings it to $3,200 over 3–5 weeks; a full hardening-plus-new-features pass lands in Full Product Build territory, from $8,500. The number moves with how long the gap has gone unexamined — a codebase looked at a month after launch is a tune-up, one left for a year is closer to a rebuild.

Signs it's time to get someone to look

• Real users are signing up beyond the friends-and-family circle who forgave the rough edges.
• The app stores anything you'd mind seeing on the news — payment details, health information, private messages.
• You're in, or about to be in, a funding conversation — investors increasingly ask what's actually under the hood.
• A partner, customer, or investor has asked for a security review, SOC 2, or even just "who else has looked at this."
• No one but the AI assistant has ever reviewed the code — not a rule against AI-written code, just against zero human review of it.
• You genuinely don't know whether row-level security is turned on for your database. (It's worth checking today, not after this list.)

None of this is an argument against building fast with AI tools — it's clearly how most working software gets its first users now, and that's not changing. It's an argument for treating the moment real users show up as the actual milestone it is: the point where a fast prototype needs someone to go back through it with production eyes, before the gap between “works in the demo” and “survives contact with the internet” gets found by someone other than you.