What breaks when a Lovable app meets real scale

Lovable (the rebranded GPT Engineer) turns plain-English prompts into full-stack TypeScript and React apps, with an optional Supabase backend wired in. It reached roughly $100M ARR in about eight months with a team of around 45 — a number worth sitting with, because it tells you how badly founders wanted this. The promise is direct: skip the React boilerplate, the schema design, the deploy config, and get a working product in front of users this week.

We picked it because it's the single most common starting point we see in rescue conversations. Founders arrive having shipped something genuinely useful in days. Then they try to grow it, and the questions change from "can we build this" to "why is this falling over."

Credit where it's due, because there's a lot.

The time-to-first-working-thing is real, not a party trick. For validation, that speed is a legitimate competitive advantage — you learn whether anyone wants the thing before you've spent $15k on a freelancer. The generated code is real React and TypeScript you can own and export, not a locked no-drag-and-drop cage. Agent Mode handling its own exploration and debugging is a sensible direction. And wiring Supabase in by default removes the single most common reason prototypes never get a backend at all.

If your goal is "prove the idea is worth building properly," Lovable is a good call. We tell founders this directly. The trouble starts when "prove it" silently becomes "run it."

Here's where the trade-offs land on the user — and they land hardest exactly when the product starts working.

The Technical Cliff

The demo produces a frontend. Production needs infrastructure: row-level security policies, environment variables, real auth flows, a deploy pipeline that doesn't break on the third push. That work gets handed back to a founder who chose Lovable specifically to avoid it. The magic evaporates at the exact moment the product gets traction.

The backend coupling

The tight default binding to Supabase is a gift on day one and a constraint by month three. Once your data model, your access rules, and your AI calls all assume that one wiring, moving any piece of it becomes a project in itself.

The credit treadmill

Pricing is credit-based, and you spend credits fixing the model's own mistakes. Founders describe burning a week's budget re-prompting the same bug the AI swore it had solved. "Cheap development" turns into expensive operational experimentation with an unpredictable monthly number — the worst kind of cost when you're managing runway.

Security you can't see

AI generates functional code. Functional is not the same as secure. In 2026 Lovable took public criticism after users found a permissions issue that could expose project information under certain conditions — a specific instance of the general vibe-coding risk: nobody senior reviewed the auth model, so nobody caught it. For anything touching user data, payments, or PII, that's not a quirk. It's the whole risk.

None of this means the tool is bad. It means the tool is a prototyper, and the market keeps using prototypes as products.

This is how we'd take that same Lovable app to production. The principle: keep everything Lovable did well, replace only what doesn't survive contact with real users. We don't throw away the frontend — we own it and harden everything under it.

1. Extract and own the code

First move is taking the generated code out of the credit loop and into a real repo with version control, so fixes are diffs and reviews, not re-prompts you pay for.

2. Put a real boundary on the backend

We keep Supabase where it earns its place but stop letting the frontend talk to it raw. A thin API/edge layer gives us one place to enforce auth, rate limits, and validation — and the option to move pieces to dedicated Postgres later without a rewrite.

3. Write the security the demo skipped

Explicit row-level security on every table, real session handling, secrets out of the client, and an actual permissions model reviewed by someone who's shipped one before.

4. Isolate the AI feature

Any model call moves behind its own service with input/output validation, a fallback path, and an eval gate so a model change can't silently degrade the product. Here's how we'd think about model choice:

5. Wrap it in observability and CI

Error tracking, basic load testing, and a deploy pipeline that catches the third-push breakage before users do.

What we'd cut, and how we'd ship it.

Twelve months out, Lovable is going to keep winning the part it owns — getting a real product on screen faster than anything else. We expect the prototyping gap to keep narrowing and the production gap to stay roughly where it is, because secure auth, sane data architecture, and cost discipline aren't prompt problems. They're judgment problems.

So the honest verdict: build your first version in Lovable. Validate fast, spend little, learn everything. Then, the moment real users show up, treat the output as a sharp first draft — not a foundation. The founders who get burned are the ones who never made that switch.

That switch is most of what we do.