Why vibe-coded apps are still leaking user data in 2026
Last month a founder showed me their Lovable app, proud of what they built. "It's ready to launch," they said.
I asked them to open DevTools. Their Stripe keys were sitting right there in the client bundle. Visible to anyone.
That is the misconception I keep running into:"I built it on Lovable/Bolt/Replit, it's ready to launch."
As a software engineer I want to share an honest take
on this. Genuinely open to pushback.
What these tools are actually good at
Incredible for validating an idea fast. Build it, put it on Product Hunt or Indie Hackers, get real users to test it, collect feedback. That is the exact right use case.
The problem is when founders treat the prototype as the product.
The architectural gaps, by platform
Lovable
- Connects your React frontend directly to Supabase with no backend layer in between
- Database access rules are auto-generated and frequently misconfigured
- API keys sit inside the client bundle, visible to anyone who opens DevTools
- CVE-2025-48757 exposed 170+ live apps: names, home addresses, financial records, Stripe keys
Bolt.new
- Backend locked to Node.js/Express only, no flexibility as your stack evolves
- Generated code frequently described as "half done" in production scenarios
- New infrastructure (2025), compliance-heavy workloads still need migration to established cloud
Replit
- In July 2025, Replit's AI agent deleted a live production database during an explicit code freeze, then misreported what it had done
- Free tier exposes your source code publicly
- Better for learning than for production systems handling real user data
The pattern across all of them
- A 2025 scan of 5,600+ vibe-coded apps found thousands of vulnerabilities and hundreds of exposed secrets
- No server-side layer means payment processing and permission checks happen client-side
- No separation between development and production environments by default
My honest take as an engineer
Use these tools to get your mental model out of your head and into something testable. A working prototype is genuinely useful. It shows exactly what you need and what matters to you as a founder.
The prototype tells you what to build. It does not tell you how to build it safely. Those are two completely different problems and conflating them is where most founders get hurt.
Notion, Figma, and Canva did not get to millions of users by prompting harder. They have been running for 10 to 15 years with real technical teams making real
architectural decisions every single day.
Your product deserves the same thinking, even at day one.
Have you shipped on one of these platforms and hit this wall? Or do you think the tools have gotten good enough that this concern is outdated?
one thing worth separating in the stripe example: pk_ and sk_ differ by one character and they are not the same finding. the publishable key is designed to sit in the client bundle, so pk_live_ showing up in devtools is not a leak. an sk_ in there is the real emergency, since it reads your full customer list and charge history and can create charges and issue refunds. we build affiliate software on stripe so this is daily work for us, and my worry with treating "stripe keys in the bundle" as one thing is that the founder who learns pk_ was fine is exactly the one who shrugs at an sk_ later.
You are right to separate them. What we actually saw was an sk_ not a pk_. The reason it ended up in the frontend is the most common one with non-technical founders: they open Stripe, see two keys, do not know the difference, and paste both because the app was not working with just one. Not negligence in the way they understand the word. Just someone doing what made sense in the moment.
We talk to founders every week and a big part of those conversations is teaching them how a properly built system handles this.
Lovable even acknowledges in their own docs that their frontend architecture means secrets cannot be stored safely client-side. Which tells you everything about how structural this problem actually is.
Your distinction is correct and important. What I would add is that the architecture makes sk_ exposure almost inevitable for someone who does not know that sensitive integrations should never originate from the browser.
You’ve clearly seen a lot of founders move from prototype to launch.
After those conversations, what changed most in how you think founders should decide whether something is actually ready to become a real product?
The biggest shift in how I think about it comes down to three questions. Not features, not design, not user feedback. Three questions about what breaks when
something goes wrong.
The first is consequences of failure. A prototype failing is fine. Nobody loses data, nobody gets charged, nobody's business depends on it. The moment real users are trusting it with their information or their money, failure has a completely different cost. That is the first line a product has to cross before the architecture underneath matters.
The second is simultaneous load. A prototype is built assuming one person is using it at a time. Production means multiple users hitting the same system simultaneously. This is where most vibe coded apps break first because there is no queue management, no connection pooling, no rate limiting at the server layer. Ten users at once on a Lovable app can bring down a Supabase instance. Not because the idea is bad. Because the architecture was never built for that reality.
The third is data permanence. A prototype can reset. Production cannot. The moment a user creates an account, makes a payment, or stores something they expect to find again later, you have entered permanent data territory. Losing or corrupting that data is not a bug you fix in the next sprint. It is a legal and
reputational event.
Most founders cross all three lines without noticing because the product looks exactly the same from the outside. The architecture underneath is what changes
everything. And by the time they notice, real users are already inside it.
I am actually putting together a detailed breakdown of each of these three stages with real examples of what breaks and when. Will share it here when it is
ready if that would be useful.
The interesting distinction is that the product can look identical from the outside while the risk profile changes underneath.
The transition from prototype to something people can rely on is where those hidden assumptions start becoming visible.