Your AI Built Website Won't Go Live

Built your business site with Lovable, Bolt, or Cursor? If publishing, login, payments, or real users broke it, this plain-language checklist covers host settings, 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. Publishing might point at the wrong project, an old version, or a host that does not match what the builder used. "Works in preview, blank when live" often means the publish target or host settings, not your design.

Real users, not just you. A client portal or simple software-as-a-service (SaaS) product 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 service keys. AI builders often paste the wrong one into the visible site code or save them in the project folder. 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" on screen but never sends email, or shows a failure every time when setup seemingly completely, 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 server that works on the live site. It could be a security measure, like CORS, or it could be a misconfigured backend, having the wrong or test authentication keys for a 3rd party service as an example.

Payments. Test mode works; but live mode needs live keys, server notification URLs (webhooks) that match your live domain, and secure HTTPS connections. Miss one of those and checkout fails, possibly silently, or orders never confirm.

Phones matter more than scores. Your customers will in all likelihood 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. Host settings and secrets

Environment variables (often shortened to "env vars") are settings your hosting company keeps on their servers instead of in the public website code. That is not perfect security, but it is much safer than baking secrets into the site visitors can see.

Open your live site and use your browser's "view page source" option, or ask someone technical to check, and search for words like sk_live, secret, password, or long random strings. If you find a secret there, assume it is compromised: create a new key in the provider's dashboard and move it to env vars on your host. The one exception is "password" is likely to exist in your own login form. So you might naturally see it once, but if it seems wrong ask someone technical.

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

2. Login: 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 the URL in your browser's address bar and go to it.

You should not see the first user's data. It should show either the second user's data, or some form of error. This isn't a perfect test, but it is a great first step.

Open Web Application Security Project (OWASP) Top 10: A01:2021 Broken Access Control lists this as a top web risk: your server must enforce who can see what, not the page layout alone. AI-generated sites often check login on the page but not on the server requests behind it. This gives anyone with credentials access to all of your data if they are technically minded.

3. Forms, email, and contact flows

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

• Contact form → does email arrive? Check spam.
• Lead capture → does it land in your customer relationship management (CRM) tool, spreadsheet, or other system?

If nothing arrives, your email provider may be blocking sends or routing them to spam, or your form or credentials might not be setup correctly.

If the form only works when you're logged into the builder, but should be accessible to everyone like your contact form, the live server handler (the code that runs when someone submits the form) is not set up or connected correctly.

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.
• Server notifications (webhooks): Stripe notifies your server when a payment succeeds. That notification URL must be your live site address with HTTPS (secure web connection). A URL still pointing at your laptop or the builder's default address means paid orders never update your database, so your system is not able to process or store the order. But you've likely taken the payment already. This can lead to a bad reputation, if not worse.
• Amounts and products: Confirm prices in the live dashboard match what the site shows. If you aren't careful, you might be showing test data and might be under or over charging.

5. Custom domain, secure connection, and publishing

• HTTPS (secure web connection): Browsers expect your site address to start with https://, which means traffic is encrypted. Some hosts set this up automatically; if yours does not, fix it before sharing the link widely. Also check that old insecure http:// addresses redirect to the secure version, and that the page does not load scripts or images over insecure connections (called mixed content). Any content loading outside of https://creates a security issue that can lead to a technically minded person either interfering with your site's content for a network, or possibly even worse such as intercepting information such as login credentials. Any of these circumstances will likely lead to reputational damage or worse.
• DNS (domain name settings): Is your domain pointed at the right host? DNS changes can take hours to propagate. A permanent blank page usually means a domain or hosting misconfiguration which is worth checking before assuming the site itself is broken.
• Same version as preview: Note which platform hosts the site (Vercel, AWS, Digital Ocean, etc.) and confirm all required environment variables and settings are in place on that host, not just in the builder.

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 or less on first visit?

Fix layout breaks and huge unoptimized images before you worry about audit scores. It will improve most audit scores inadvertently anyway.

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.

Who can see what on the server. The Veracode 2025 GenAI Code Security Report tested 100+ large language models (LLMs) and found detectable security flaws from the Open Web Application Security Project (OWASP) Top 10 list in 45% of generated samples. Broken access control and unsafe data handling show up often. The site looks finished because the page hides other users' menus.

Input checks on the server. The browser checks an email format; the server behind the site accepts anything. Bots and bad data can hit your database, trigger unexpected bills, or alter your data through injection attacks.

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

Operational wiring. Email provider, payment notification URLs, scheduled tasks, and backup admin accounts. Skipped because the demo did not need them, or needed different data which makes you assume you're done configuring the 3rd party tool.

A boundary around critical code. Login, payments, and data access get regenerated on every AI prompt. Mark those files as hands-off in your notes so a "quick fix" does not 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 a publishing or domain name system (DNS) issue (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 project folder or visible in page source; you need new keys and a proper server-side setup.
• 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, proper payment integration, server connections, product screens.

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