Bolt.new app compliance checklist — what gets skipped in the rush

Bolt.new's WebContainer model is impressive engineering — you watch the app build, test, and deploy from a browser tab. The compliance issues are similar to Lovable's, plus two Bolt-specific patterns: staging URLs leaking before consent flows exist, and "Continue" iterations silently regressing earlier fixes.

What Bolt.new ships by default

Bolt's prompt-to-app produces React + Vite (occasionally Next.js), deployed to a `bolt.new` preview URL or pushed to Netlify with one click. Default output looks polished — which makes the compliance gaps less obvious. Two patterns specific to Bolt:

• Bolt's instant-deploy means lots of staging URLs leak into the wild before consent banners or auth gates are added. By the time you'd think to lock them down, they've been crawled.
• Bolt's "Continue" iteration mid-build doesn't always preserve earlier compliance edits — labels you added on iteration 3 can vanish on iteration 5. Re-scan after every significant Continue cycle.

The 7 things to check on a Bolt.new app

1. Form labels and accessibility

Same pattern as every other prompt-to-app tool: placeholders, no real labels, no aria-* fallback. WCAG 2.2 §1.3.1 violation. Real `<label htmlFor>` is the fix.

2. Color contrast on default palettes

Bolt's color choices tend toward Vercel-style cool grays. Check against WCAG 2.2 §1.4.3 minimums. The lighter end of any default palette usually fails.

3. Tracking pixels before consent

Bolt usually adds Google Analytics if your prompt mentions analytics, social sharing, or marketing — and the snippet goes in the root layout. ePrivacy 5(3) violation for any EU user. Same fix as Lovable: gate behind consent or switch to cookieless first-party analytics.

4. Public Bolt URLs crawled before you're ready

Bolt's preview URLs are publicly accessible from creation. ADA-lawsuit scanners and ad-tech compliance bots crawl new subdomains aggressively. The exposure window is days, not weeks. Move to a private subdomain or your own custom domain before sharing the URL anywhere.

5. Secrets in vite.config.ts and import.meta.env

Bolt's Vite-based projects use `import.meta.env.VITE_*` for env vars. Any env var with the `VITE_` prefix is exposed to the client bundle. If Bolt wrote your Stripe / Supabase / OpenAI integration, audit every `VITE_*` var; anything secret needs to be moved to a server-side route.

6. License contamination in AI-generated dependencies

Same as every AI tool: occasional reproduction of GPL or AGPL training data, no header attached. Bundle scan after each major iteration.

7. AI-generated copy that overclaims

Privacy policy, terms, marketing claims, alt text. Bolt's output is good but not legally vetted. Read every line. Anything that says "complies with" or "is certified" needs to be either true or removed.

How to fix all of these

Run Comply Code on your bolt.new URL or your deployed Netlify URL — catches items 1, 2, 3, 5, and 6 automatically. Items 4 and 7 are a manual check. Then re-scan after every major Bolt iteration: Bolt's "Continue" can regress fixes silently, and you want a snapshot before each major change.