Lovable, Bolt, v0 & friends: what to check before you go live
Fast to a working app — now a quick pre-flight
Lovable, Bolt, v0 and the rest are genuinely good at what they do: they take you from idea to a working, deployed app in an afternoon. That is the whole point, and it is great. None of this is a critique of those tools. It is just that any fast path to production benefits from a short pre-flight check, the same way a pilot runs a checklist on a perfectly good plane. Here is the friendly version.
1. Keys belong on the server
The most common thing to confirm: are your API keys — for payments, AI, email, your database — used from the browser or from the server? If a key is in the client-side code, it ships in the bundle and anyone can read it. Move third-party calls behind your own backend endpoint, and keep only publishable or scoped keys in the frontend.
2. Database access rules are set
Many builder stacks lean on a hosted database with row-level security or access rules. The default is sometimes wide open so things 'just work' during development. Before launch, confirm those rules actually restrict who can read and write what. An open table is the kind of thing that is fine in a demo and not fine in production.
3. Security headers are present
Generated apps rarely set security headers for you, so they are usually just absent. A quick win is to add the basics — Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options. Most of them are one line each, and they switch on browser protections you otherwise leave off.
4. No stray files in the public folder
When you iterate fast, it is easy to leave things behind: a .env copied into a public directory, a .git folder deployed, a config.json with real values, a database dump from testing. Confirm none of these are reachable at a public URL. The fix is usually to move them out of whatever folder gets served.
5. HTTPS everywhere, no mixed content
Most hosts give you HTTPS by default, which is great — just check that nothing on the page still loads over plain http://, and that HSTS is on so browsers stick to the secure connection.
A short list, honestly
Notice what this is not: a fifty-point audit or a reason to distrust your tooling. It is five things, most of them one-time fixes, that cover the gaps that actually show up on freshly shipped apps. Run them once and you have closed the common ones.
Let a scan do the checklist
The hard part is that you cannot eyeball most of this — keys hide in bundles, headers are invisible, exposed files live at URLs you would not think to try. An automated scan walks your live site the way a bot would and reports exactly what it finds. Scan your site before you announce it.