Your AI Built Website Won't Go Live

Built your business site with Lovable, Bolt, or Cursor? If deploy, login, payments, or real users broke it, this plain-language checklist covers env setup, security basics, and reliability before you hire help.

Published June 2026 by Batteries Included

The preview in Lovable, Bolt, or Cursor looks great. You click deploy, attach your domain, or send the link to a customer, and something fails. Blank page, login loop, form that never arrives, Stripe stuck in test mode, or "it worked yesterday and today it's broken."

You're not doing it wrong. Builder previews run in a controlled sandbox. A live site on a real URL with real visitors runs in a different world. This checklist is for small business owners and founders who can ship a demo but need plain language on what to fix before the site is actually safe to run.

Demo vs. live site: what actually changes

In the builder, you're usually logged in as the creator, using test data, on the tool's default hosting. None of that guarantees the same behavior on your custom domain with strangers visiting.

Real URLs and hosting. Deploy might point at the wrong project, an old build, or a host that doesn't match what the builder used. "Works in preview, blank in production" often means the deploy target or environment config, not your design.

Real users, not just you. A client portal or simple SaaS built with Supabase or Firebase only stays private if access rules are set up and tested. Log in as one user, then try to open another user's page by changing the link. If you can see their data, the site isn't ready.

Secrets and keys. Some keys are meant to be public (like a Stripe publishable key on the checkout page). Others must never appear in the browser: payment secret keys, admin tokens, email API keys. AI builders often paste the wrong one into the front end or commit them to the repo. Scans of thousands of AI built apps in production have found hundreds of exposed credentials, per OX Security's summary of Escape.tech findings.

Forms and email. A contact form that shows "success" in the UI but never sends email is one of the most common gaps. Same for newsletter signups and "book a call" flows. The happy path works in the demo because it wasn't wired into a publicly accessible backend.

Payments. Test mode works; live mode needs live keys, webhook URLs that match your deployed domain, and HTTPS. Miss one of those and checkout fails silently or orders never confirm.

Phones matter more than scores. Your customers will open the site on a phone. You don't need a perfect Lighthouse report. You need readable text, tappable buttons, and pages that load without hanging on mobile data.

Minimum go-live checklist

Work through these in order. You don't have to fix everything in one sitting; start with anything that could leak data, lose money, or expose secrets.

1. Environment variables and secrets

Environment variables (often shortened to "env vars") are settings your host keeps locally, which is significantly more private than on the client site! Although, this isn’t perfect security, it is a big upgrade from sticking secrets in the client.

Open your live site in the browser, view page source (or use dev tools), and search for words like sk_live, secret, password, or long random strings. If you find a secret there, assume it's compromised: rotate the key in the provider's dashboard and move it to env vars on the host.

For Supabase or Firebase on the web: learn which key is safe in the browser and which is server-only. Row Level Security (RLS) on Supabase means database rules that say "user A can only read user A's rows." If RLS is off or never tested with two accounts, your app is a shared spreadsheet with a login screen.

2. Auth: can user A see user B's data?

If your site has login (client portal, member area, admin dashboard), verify isolation:

• Create two test accounts.
• Log in as the first. Copy any URL that shows private content.
• Log out, log in as the second. Paste that URL. You should not see the first user's data.

OWASP Top 10: A01:2021 Broken Access Control lists this as a top web risk: the server must enforce who can see what, not the UI alone. AI-generated sites often check login on the page but not on the API.

3. Forms, email, and contact flows

Submit every form on the live domain (not the just the builder preview):

• Contact form → does email arrive? Check spam.
• Lead capture → does it land in your CRM or sheet?
• otherwise email providers may block you, or sending your email to the spam-folder.

If the form only works when you're logged into the builder, the production API route or serverless function isn't correctly created, configured, or connected.

4. Payments (if you take money)

• Test vs live: Stripe (and similar) have test keys and live keys. Live checkout needs live keys and often a completed business verification.
• Webhooks: Stripe notifies your server when a payment succeeds. The webhook URL must be your production URL with HTTPS. A webhook still pointing at localhost or the builder's default URL means paid orders never update your database.
• Amounts and products: Confirm prices in the live dashboard match what the site shows.

5. Custom domain, HTTPS, and deploy

• HTTPS: Browsers expect https://. Browsers expect a trustworthy connection secured by a validated certificate. This leads to HTTPS protocol usage instead of HTTP. Although, installing a certificate and configuring HTTPS is important, so is shutting off HTTP or otherwise redirecting it to upgrade to HTTPS. Also of note: mixed content (page is HTTPS but loads scripts, CSS, or other content over HTTP) breaks features and looks untrustworthy as well.
• DNS: Domain pointed at the right host? Domain Name System Propagation can take hours, but a permanent blank page could be one of a handful of obtuse things, however no matter the cause, the effect is the same: presenting an empty page doesn’t look good and it isn’t useful.
• Same build as preview: Note which platform hosts the site (Vercel, AWS, Digital Ocean, etc.) and ensure that all required Environment Variables (or other secrets) are in place properly and that all requirements are installed.

6. Mobile layout and basic performance

On your phone on cellular (not office Wi‑Fi):

• Can you read headlines without zooming?
• Do buttons work on first tap?
• Does the hero image load in a few seconds?

Fix layout breaks and huge unoptimized images before you worry about audit scores.

What AI built web projects tend to skip

This matches what we see on inherited Lovable, Bolt, and Cursor sites, and lines up with published research on AI-generated code.

Access control on the server. The Veracode 2025 GenAI Code Security Report tested 100+ LLMs and found detectable OWASP Top 10 issues in 45% of generated samples; broken access control and injection flaws show up often in web stacks (JavaScript, SQL, XSS). The site looks finished because the UI hides other users' menus.

Server-side validation. The browser checks an email format; the API accepts anything. Bots and bad data hit your database, trigger unexpected bills, or even copy out or alter your data by SQL Injection attacks.

Error messages that help. Users see a spinner forever or "Error" with no next step. Production needs clear copy: session expired, payment failed, try again.

Operational wiring. Email provider, webhook endpoints, cron jobs, and backup admin accounts. Skipped because the demo didn't need them.

A boundary around critical code. Auth, payments, and data access get regenerated on every AI prompt. Mark those files as hands-off in your notes so a "quick fix" doesn't rewrite who can see what.

When you can fix it yourself vs. when to get help

Reasonable to DIY if:

• Marketing site only: no login, no payments, no customer data beyond a contact form.
• Problems are clearly deploy or DNS (blank page, wrong domain) and your host's docs are understandable.
• You can test with two accounts and you're confident in your authentication setup and that your isolation works as expected.

Get help if:

• Clients need to be able to log in and you can either see other user’s data, or even simply can’t prove it’s impossible.
• Live payments, subscriptions, or stored payment methods are involved.
• Secrets were in the repo or in page source; you need rotation and a proper server-side layout.
• Forms or email never worked in production and you're out of patience with dashboards.
• The scope is a product (dashboard, internal tool, multi-role SaaS), not a brochure site.

That maps to our web packages on Web development:

• Site Review + Scope (2–3 business days): site exists or you have a brief; need a ballpark and plan.
• Marketing Site Build (2–4 weeks): marketing site must go live properly (SEO, mobile, deploy).
• Full-Stack Web App Sprint (2–6 weeks): login, payments, API, product UI.

Larger or unclear scope → Discovery Roadmap after you've seen packages. Backend-heavy auth or API problems → Secure APIs and Backend.