DEV Community

Geminate Solutions
Geminate Solutions

Posted on • Originally published at geminatesolutions.com

Your Vibe-Coded App Will Break in Production. Here's Why.

Your Vibe-Coded App Will Break in Production. Here's Why.

170 out of 1,645 Lovable-built apps had data-exposure vulnerabilities. That's 10.3% — one in ten apps leaking user data before a single real customer signed up. This stat comes from a May 2025 security audit, and the problem has only gotten worse as vibe coding tools have grown in popularity.

I run a software development company that has rescued 12 vibe-coded apps in the past 6 months. Founders come to us after burning $5,000-$15,000 in Lovable and Bolt.new credits, with an app that works in demos but falls apart under real traffic. The problems are always the same.

The 80/20 Wall: Where Vibe Coding Breaks Down

AI-generated code is brilliant for the first 80% of a project. Landing pages, CRUD forms, basic auth flows, dashboard layouts — Lovable and Bolt.new handle these faster than any human developer.

The last 20% is where projects die:

  • Edge cases. What happens when two users submit the same form simultaneously? When a payment webhook fires twice? When a user's session expires mid-checkout?
  • Integrations. Stripe webhooks, OAuth flows with refresh tokens, email delivery with bounce handling, file uploads with virus scanning.
  • Performance under load. Your demo works with 3 concurrent users. What happens at 300? At 3,000?

Lovable's own documentation acknowledges this: the platform is designed for prototyping and MVPs, not production workloads. Bolt.new's token consumption scales with codebase size, meaning the same edit costs more tokens as your project grows — creating a perverse incentive where fixing bugs gets progressively more expensive.

Vibe Coding Security Problems: The Hidden Risks

The security issues in AI-generated code aren't random — they follow predictable patterns:

1. Exposed API Keys

Vibe coding tools frequently embed API keys directly in client-side code. We found Stripe secret keys, Supabase service role keys, and SendGrid API keys in the frontend bundle of 4 out of 12 apps we audited.

// This was in a production Lovable app's client bundle
const supabase = createClient(
  'https://xyz.supabase.co',
  'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...' // service_role key - full DB access
);
Enter fullscreen mode Exit fullscreen mode

The service_role key bypasses Row Level Security entirely. Anyone who opens browser DevTools can read, modify, or delete every row in every table.

2. Missing Server-Side Validation

AI-generated apps typically validate inputs on the client only. The server accepts whatever arrives:

// Client-side validation exists...
if (amount > 0 && amount < 10000) {
  await fetch('/api/transfer', { body: JSON.stringify({ amount }) });
}

// ...but the API endpoint trusts the input blindly
app.post('/api/transfer', async (req, res) => {
  const { amount } = req.body; // No server-side validation
  await transferFunds(amount);  // Negative amounts? Infinity? Strings?
});
Enter fullscreen mode Exit fullscreen mode

3. Broken Authentication

Session handling in vibe-coded apps is typically the weakest link. We've seen JWT tokens with no expiration, refresh tokens stored in localStorage (XSS-vulnerable), and password reset flows that don't invalidate previous tokens.

For the full security and architecture audit checklist, we published a detailed production-readiness guide covering every vulnerability pattern we've encountered.

Lovable to Production: What Actually Needs to Change

Taking a Lovable or Bolt.new app to production isn't about rewriting everything. It's about fixing the 20% that AI tools get wrong. Here's our audit checklist after 12 production rescues:

Authentication (2-3 days of work)

  • Move from client-side Supabase auth to server-side session management
  • Implement proper refresh token rotation
  • Add rate limiting on login endpoints (prevent brute force)
  • Set up email verification and password reset with token expiration

Database Security (1-2 days)

  • Enable Row Level Security on every Supabase table
  • Move service_role key to server-side only
  • Add database-level input validation constraints
  • Set up automated backups

API Hardening (2-3 days)

  • Move all business logic to API routes (not client-side)
  • Add server-side input validation on every endpoint
  • Implement rate limiting per user/IP
  • Add request logging and monitoring

Deployment and Infrastructure (1-2 days)

  • Set up proper CI/CD pipeline (not manual deploys)
  • Configure environment variables (remove hardcoded keys)
  • Set up error tracking (Sentry or similar)
  • Add uptime monitoring and alerting

Performance (1-2 days)

  • Add database indexes on frequently queried columns
  • Implement API response caching where appropriate
  • Optimize image loading (lazy load, proper formats)
  • Load test with expected traffic + 3x headroom

Total: 7-12 days of professional development work. That's the gap between a vibe-coded prototype and a production app. Not a rewrite — a hardening sprint.

The Credit Burn Problem: When AI Tools Cost More Than Developers

A pattern we see repeatedly: founders burn $3,000-$8,000 in Lovable credits trying to fix bugs that a developer would solve in 2 hours.

Lovable users report burning 400 credits in under an hour fixing circular bugs. Bolt users describe "endless error loops" where each fix creates a new problem. The AI doesn't understand the architectural context — it fixes symptoms, not causes.

Here's the math that founders discover too late:

  • Lovable Pro: $100/month for 5,000 credits
  • Average credits to fix a production bug: 200-500
  • Average bugs in a production launch: 15-30
  • Total credits to stabilize: 3,000-15,000 credits = $600-$3,000

Compare: a senior developer at $40/hour spends 2-4 hours per bug, fixes the root cause (not a workaround), and the fix stays fixed. Total for 15-30 bugs: $1,200-$4,800 — and you get a codebase that's actually maintainable.

The vibe coding tools aren't the problem. Using them past their intended scope is.

Production-Ready Checklist: AI App to Real Product

Before launching any vibe-coded app to real users:

Security

  • [ ] All API keys in environment variables, zero in client code
  • [ ] Server-side validation on every API endpoint
  • [ ] Row Level Security enabled on all database tables
  • [ ] JWT tokens expire, refresh tokens rotate
  • [ ] HTTPS enforced, security headers configured

Reliability

  • [ ] Error tracking (Sentry) configured and tested
  • [ ] Database backups running automatically
  • [ ] Health check endpoints monitored
  • [ ] Rate limiting on all public endpoints
  • [ ] Graceful error handling (no white screens)

Performance

  • [ ] Load tested at 3x expected traffic
  • [ ] Database queries use indexes
  • [ ] Static assets cached via CDN
  • [ ] API responses under 200ms for common operations

Operations

  • [ ] CI/CD pipeline (no manual deploys)
  • [ ] Staging environment for testing
  • [ ] Logging with structured output
  • [ ] Runbook for common failure scenarios

When to Keep Vibe Coding, When to Hire Developers

Vibe coding is perfect for:

  • Internal tools used by your team only
  • Landing pages and marketing sites
  • Proof-of-concept demos for investors
  • Personal projects and side projects

Hire developers when:

  • Real users will enter payment information
  • You need to handle sensitive data (health records, financial data)
  • Expected traffic exceeds 100 concurrent users
  • The app has complex integrations (payment processors, email, SMS)
  • You plan to iterate on the product for more than 3 months

The smartest founders we work with use vibe coding for the prototype, validate the idea, then bring in engineers for the production build. They get the speed of AI tools for exploration and the reliability of human engineers for execution.

The worst approach? Trying to make a vibe-coded prototype handle production load. That's how you get the 10.3% data-exposure stat.

What We Tell Every Founder Who Calls Us

Your Lovable or Bolt.new app isn't garbage. It's a prototype. A very good one, probably. The architecture just needs professional hardening — typically 7-12 days of focused work.

Don't rewrite from scratch. Don't burn more credits trying to fix it with AI. And definitely don't launch it to real users with payment processing in its current state.

Get a proper MVP architecture review, fix the security gaps, add monitoring, and ship it right. The total cost of hardening is almost always less than what founders spend on credits trying to fix problems the AI tools created.

Build fast with AI. Ship with engineers. That's the playbook for 2026.


Yash Korat is the CEO of Geminate Solutions, a custom software development company that has shipped 50+ products for startups across the US, UK, and Australia. His team has rescued 12 vibe-coded apps in the past 6 months alone.

Top comments (0)