In February 2026, The Register reported that researcher Taimur Khan found 16 vulnerabilities in a single Lovable-hosted edtech app, exposing 18,697 user records, including 4,538 student accounts. In April, Lovable disclosed a separate public-project visibility incident: between February 3 and April 20, 2026, public project chat history and source code could potentially be accessed by any Lovable user with a project link.
Different bugs. Same lesson: a working URL is not a production system.
The phrase "production-ready" has been laundered into meaninglessness by AI app builders. A Lovable app that passes signup and renders a dashboard is deployed. It is not in production in any sense a senior engineer would recognize. The gap between "users can sign up" and "I can sleep through Saturday night" is roughly 14 disciplines wide, and the typical vibe-coded MVP fails at most of them.
This post is not anti-vibe-coding. We use AI heavily, it's literally in our tagline. It's anti-shipping-without-the-floor.
Deployed and in production are not the same thing
A deploy is a technical event: code runs on a server somewhere on the public internet. Production is an operational state: the system has owners, alerts, budgets, runbooks, backups, and the discipline to survive contact with real users.
Charity Majors, Honeycomb's CTO, puts it bluntly in "I test in prod": "Only one represents reality." She is talking about watching real code under real user behavior. That requires structured logs, traces, error tracking, and someone whose job it is to look. A typical Lovable app has none of those. It has console.log and the founder's inbox.
Google's Site Reliability Engineering team formalized this with the Production Readiness Review: a process that verifies "accepted standards of production setup and operational readiness." The companion launch checklist covers architecture, capacity, monitoring, security, rollout, automation, growth, and dependencies. That is the bar engineers mean when they say "production."
Lovable's docs can reasonably use phrases like "production-grade web applications" and "production-ready environment from day one" in the product-marketing sense: a generated app deploys, runs, and can be edited. A senior engineer means something stricter: an owned system with alerts, rollback, access control, tested recovery, and a human responsible when it breaks.
The Saturday-night test
Here's the test we use with every founder we work with. Imagine you're sitting on the couch on a Saturday night when your app gets featured on Hacker News. Five thousand concurrent users hit it in 20 minutes. Do you sleep that night, or do you spend the next 14 hours improvising?
For a typical Lovable MVP, the answer is fixed:
- If 5,000 concurrent users would melt the database (no load test, no read replicas, no point-in-time recovery): you don't sleep.
- If alerts go to an email address you don't read: you don't sleep.
- If a single bad migration loses customer data and there's no PITR: you don't sleep.
- If a researcher finds your Supabase URL and public key, then proves RLS allows anonymous or wrong-tenant reads: you don't sleep.
- If an AI agent has write access to prod with no environment separation: you don't sleep.
That last one is not hypothetical. On July 18, 2025, a Replit AI agent deleted a production database during an active code freeze. It destroyed 1,206 executive profiles and 1,196 company records, months of work. Replit's CEO called the incident unacceptable.
The root cause was not "AI is spooky." It was simpler: the agent could touch production data during a freeze, dev and prod were not safely separated, and the recovery path was not reliable when the incident happened.
If you can't answer the Saturday-night question with "I sleep," your app is not in production. It's running in public. Those are different things.
The 14 things a "production-ready" Lovable app is missing
Synthesize the Google SRE Launch Checklist, the 12-Factor App, the Supabase Production Checklist, the Vercel Production Checklist, and OWASP Top 10:2025. The shared floor is roughly 14 disciplines. A typical Lovable export ships without most of them:
1. Observability. No structured logs, no traces, no error tracking. console.log is not logging. Without this floor, every bug report is a guess.
2. SLOs and error budgets. Google defines an error budget as 1 minus the SLO. A 99.9% SLO gives you 43 minutes of downtime per 30-day month. Without an SLO, you have no objective definition of "broken."
3. Runbooks. Documented response for the top alerts. Without them, on-call is a panic improvisation at 3 a.m.
4. On-call rotation. Someone who gets the page. "The founder, asleep, on his phone" is not on-call.
5. Rollback and canary. Every release reversible in under 10 minutes. On Lovable, "rollback" means asking the LLM to undo.
6. Secrets management. Secret keys in a vault, rotated, never in client bundles. Next.js makes this explicit: NEXT_PUBLIC_ values are inlined into browser-delivered JavaScript at build time. That is fine for public values. It is catastrophic for OpenAI, Stripe, Supabase service_role, database, or internal API secrets. Wiz Research found vibe-coded apps shipping sk-proj-* keys live, and passwords as s === "welcometoredacted" in JS files.
7. Authorization and RLS. Server-enforced, deny-by-default. Supabase's production checklist leads with RLS because [publishable and anon keys are public by design](https://supabase.com/docs/guides/getting-started/api-keys); the protection comes from policies on the anon and authenticated roles. Without reasonable policies, any client can access or modify data. OWASP Top 10:2025 keeps broken access control at A01 and says every tested application in its contributed dataset had some form of it.
8. Tested backups and PITR. Point-in-time recovery, with restores actually tested. Untested backups are a story you tell yourself.
9. Disaster recovery. What happens when the region goes down? When your provider suspends your account? When Lovable changes its pricing model overnight?
10. Load testing and capacity planning. Google's classic question: what breaks first at 10x current traffic? If your first viral moment is also your first capacity test, you have your answer.
11. Performance budgets. Core Web Vitals, p95 latency targets, bundle size ceilings. Without budgets, performance regresses every sprint.
12. Accessibility. WCAG 2.2 AA at minimum. AI-generated UIs routinely lose semantic structure, keyboard navigation, and contrast, and that's before you find out your largest enterprise customer has procurement rules about it.
13. Legal and PII handling. GDPR, privacy policy, data deletion endpoints, lawful basis. Reported Lovable incidents exposed student and enterprise user records, credentials, and financial/status data; broader Escape.tech scans found medical records and IBANs in vibe-coded apps. That's not a bug report, that's a regulator letter.
14. Dev/prod parity and change management. Versioned migrations, code review, distinct environments. The Replit wipe happened because dev and prod were the same database.
Supabase publishes a separate "Vibe Coding Master Checklist" because they know the AI builders that sit on top of them ship apps without these. That checklist exists for a reason.
How this breaks in the wild
The receipts are public, recent, and embarrassingly consistent.
- **CVE-2025-48757** is supplier-disputed in NVD, but the failure mode is real: Matt Palmer and Kody Low's scan found 303 endpoints across 170 Lovable Launched projects with inadequate RLS. The issue was not that the public
anonkey existed. The issue was that RLS did not enforce the business rules behind that key. - The February 2026 Lovable-hosted edtech app exposure was reported by The Register from Taimur Khan's findings: 16 vulnerabilities, six critical, and 18,697 exposed user records.
- The April 2026 Lovable public-project incident affected public project chat history and source code between February 3 and April 20, 2026. Lovable says private projects and Lovable Cloud were not impacted, and that access required a project link.
- Escape.tech reported 5,600+ vibe-coded apps analyzed, with 2,000+ vulnerabilities, 400+ exposed secrets, and 175 PII instances.
- A self-published DEV scan reported 453 critical vulnerabilities across 1,764 apps. Treat it as directional field evidence, not a benchmark.
- Wiz Research reported that one in five organizations it observed had systemic vibe-coding risk across client-side auth logic, exposed API keys, insecure RLS, and unauthenticated internal apps.
The pattern isn't a few unlucky founders. It's structural.
What it costs when you get it wrong
Downtime numbers are messy, and most are enterprise surveys rather than startup benchmarks. ITIC's 2024 survey says hourly downtime exceeds $300,000 for over 90% of mid-size and large enterprises, and 41% put one hour at $1M to over $5M.
Those are enterprise numbers. For a pre-seed startup, the cost is rarely measured in dollars per minute; it's reputational, and the reputational cost compounds. A breach at 100 users is recoverable. The same breach at 100,000 users becomes the story customers hear first. The 18,697 records exposed from one Lovable-hosted app may not bankrupt a company, but they create customer, prospect, and investor questions that do not disappear after a status page update.
"But our MVP doesn't need all that yet"
This is the most common pushback, and it's half-right. You don't need every dimension on day one. You need to know which ones you're skipping, why, and what the trigger is for adding them.
There's a credible version of "minimal production": observability with Sentry and structured logs to a managed service, RLS on every Supabase table with tested policies, secret keys kept out of NEXT_PUBLIC_*, automated daily backups with one tested restore, an alert that pages a real human, and a deployment pipeline that can roll back. That's six dimensions, not 14. In our work, for a simple app, that's usually a two-week hardening sprint.
What's not credible is shipping zero of them and calling the result production-ready. That's the category error.
How we close the gap
We rescue and rebuild vibe-coded apps for a living. The pattern is always the same: someone shipped fast on Lovable or Bolt, got real users, and discovered the day-2 cost: the part the marketing page calls "production-ready" and engineers call "deployed at best." Our Engineering and AI services exist to install the missing 14 dimensions on top of what's already working.
We've been hardening apps to this floor for a decade. Grovs processes 10M+ events daily; that doesn't happen with console.log and a hope. Semaphr manages 500K+ app sessions with real RLS, real backups, and a real on-call rotation behind it. Incasez submits invoices to the Romanian regulator's e-Factura API in under 30 seconds, production there means the regulator's API doesn't time out, every time, at any volume.
The same senior team that hardens your app is the team that stays to grow it. Day one to scale.
If your Lovable MVP has users but you can't honestly say you'd sleep through a viral Saturday. book a call. We'll do a 14-dimension audit and tell you which gaps actually need closing first, in plain English, with the numbers behind each one.
The bar isn't "it deployed." The bar is "I can sleep next to it." Anything else is just running in public.