Security for apps built in Lovable, Bolt, v0, and Replit

The gap between prototype and product

Tools like Lovable, Bolt, v0, and Replit make the MVP work fast. The problem appears at the boundary between "works in the demo" and "holds real customers": server-side authorization, per-customer isolation, input validation, and control over what the AI can do usually get left for later — and "later" arrives with the first paying customer.

The tool is not the problem. The problem is shipping a real flow (login, billing, data) without reviewing the boundary the generator did not design for you.

What to review first

Regardless of the tool, the same flows concentrate the risk.

• Server-side authorization, not just screens hidden in the front-end.
• Per-customer isolation on every read and write.
• Keys and secrets kept out of the client code/bundle.
• Input and upload validation on the backend.
• Database access rules (e.g. Supabase RLS) actually enabled.

Common default pitfalls

Generators optimize for "runs", not "resists". It is common to ship with a permissive database policy, an endpoint with no owner check, a key exposed in the front-end, and an unverified webhook. None of these are the tool’s fault — they are the part nobody reviewed.

How to stop guessing

You do not need to rewrite everything. You need to walk the real flows with a playbook that forces the AI to review access, data, checkout, and uploads — and flag what to fix now. That is what the RET Promptbook is for: a first paid review before more users enter the risk.