What Lovable and Bolt don't set up for you

Lovable and Bolt do a lot for you. You describe an app, and you get a working frontend, a database, sign-in, hosting with HTTPS and a public URL. Both now run security checks before you publish. That’s a lot of plumbing you no longer have to think about.

This guide is about the gap between “it works” and “it’s ready for strangers on the internet”. None of it is a criticism of either tool. Some of it can’t be set up by default, because it depends on your business, your visitors and what you’ve added since. Patch doesn’t mind which tool built a site. Patch minds what it loads at 3am.

What they do set up

Here’s what each platform’s own docs say it handles, as of October 2026.

Lovable

• Stack. New projects use TanStack Start, which renders pages on the server. It became the default for new projects on 13 May 2026 (22 June 2026 for Enterprise). Older projects use React and Vite, which render in the browser. Lovable serves pre-rendered copies of those older apps to verified search engines and social preview bots.
• Backend. Lovable Cloud gives you a database, authentication, storage and edge functions. Its docs say it “utilizes Supabase’s open-source foundation”. You can also connect your own Supabase project.
• Hosting. Publishing gives you a lovable.app address, with HTTPS set up automatically, including on custom domains.
• Security checks. A Quick scan runs when you publish. It looks at database access rules, known vulnerable npm packages and exposed MCP servers. A Deep scan, which you start yourself, reviews application code for things like access control flaws, abusable endpoints, injection risks, leaked secrets and payment logic. Admins can block publishing while critical issues are open. Lovable’s security docs say plainly that these tools “do not replace a thorough security review”.
• Analytics. Visitor analytics are on by default for published apps.

Bolt

• Stack. Bolt chooses a JavaScript framework when you start, such as React or Vue, unless you ask for a specific one.
• Backend and hosting. Bolt Cloud covers hosting on a bolt.host address, custom domains on paid plans, a database, sign-in, edge functions, file storage and Stripe payments. You can connect Supabase instead if you prefer.
• Security checks. Every plan gets a database security check. It looks for missing row level security and access policies that are too open, using the same checks as Supabase’s Security Advisor. Paid plans can run a full project security audit from the Publish menu. It reviews code and database, covering data access, sign-in, secrets reaching the browser and visitor input, and fixes what it can.
• Analytics. Built-in analytics are available on paid hosting plans.

That’s a solid starting point. Use those scans. They can see inside your project in a way an outside scanner can’t.

What isn’t set up for you by default

Legal pages that match your site

The security tools in both sets of docs are about code, databases and dependencies. They don’t cover cookie consent, privacy policies or terms of service. That’s reasonable. Only you know who your business is, what you do with people’s data and where your visitors are.

So you’ll need to write, or carefully check, a privacy policy. If you take payments for a subscription, you’ll also need subscription terms that explain renewal and cancellation. Some countries, Germany among them, also expect a legal notice page called an Impressum.

Consent for what you add later

Bolt’s docs explain how to paste in Google Analytics or Matomo tracking code. That’s easy, and it usually means the script runs on every page load, before a visitor has agreed to anything. The same goes for chat widgets, session replay tools and ad pixels you add with a prompt.

The built-in analytics need a look too. Lovable’s are on by default. Its docs say it doesn’t build visitor profiles, but they don’t say how a session is recognised. Find out what it stores in the browser and mention it in your policy. Our guide to whether a vibe-coded site needs a cookie banner goes through the UK, EU and US rules.

Access rules that match what you meant

Both platforms flag missing row level security. A scan can’t tell what you intended, though. Bolt’s docs are honest about this. If your app has no sign-in, Bolt may write policies that let any visitor read, add, change or delete data. The resulting warning is only acceptable if you’re comfortable with every visitor being able to do that.

Supabase’s docs say a publishable (or legacy anon) key “only reaches what Row Level Security allows”. A secret key bypasses every policy and must never be in the browser. Read our Supabase row level security explainer and ask, table by table: who should be able to read this, and who should be able to change it?

Security headers

Neither platform’s hosting pages say anything about security headers such as Content-Security-Policy, X-Frame-Options or Strict-Transport-Security. Check what your live site actually sends. Security headers in 10 minutes walks through it.

Search engines and link previews

Lovable’s docs say older React and Vite projects send the browser “a mostly empty page” and build the content with JavaScript. Verified search engines get a pre-rendered copy, but other tools see very little. Bolt apps vary with the framework chosen. If your site is a browser-rendered app, check what it looks like without JavaScript and whether your meta tags are there. SEO for single-page apps covers the fixes.

Accessibility

None of the scans described cover accessibility. Check alt text, colour contrast and form labels. Generated designs can look lovely and still have pale grey text on a white background.

After launch

Every prompt can change your site. Bolt’s docs note that security fixes can change things you didn’t want changed, and that rolling back to an earlier version also removes the fixes. A site that passed every check on Monday can have a new tracker by Thursday.

What you still need to check

Before launch, and again after big changes:

• Run the platform’s own security scan or audit, and read the findings.
• For every table, decide who can read and who can write. Check the policies say the same.
• Confirm no secret or service key is in the browser. Look in the page source and the network tab.
• Open the site in a private window and list every third-party request before you click anything.
• If anything there needs consent, add a banner that actually blocks it until people agree.
• Write a privacy policy that names the services you found. The privacy policy checklist helps.
• Check security headers, meta tags and what the site looks like without JavaScript.
• Check contrast, alt text and form labels.

Where ShipPatrol fits

ShipPatrol looks at your live site from the outside, the way a visitor would. It doesn’t replace the platform scans. They can read your code and database settings. We see what your site does once it’s on the internet.

• Legal and policy matching. We record the services your site really loads, then read your privacy policy and flag where the two disagree.
• Consent behaviour from the UK, EU and US. We load the site from each region and see what fires before anyone clicks, after “reject” and after “accept”.
• Security from the outside. We look for exposed keys, missing headers and exposed files. Anything beyond what a normal visitor’s browser does, like testing your database rules with your public key, only runs after you’ve verified you own the site.
• Monitoring. With Patrol, sites are re-scanned on a timer and when you deploy, and you get an email when something new turns up.

We’ll tell you what we found and which guidance it relates to. We won’t tell you your site is legally fine, because a scanner can’t know that. This isn’t legal advice.

See ShipPatrol for Lovable or ShipPatrol for Bolt for the platform-specific checks, or browse every check.

Check yours

Run a free scan on your published site. It shows your score and every finding’s title, and gives you the detail on the top three.