Lovable Built My App — Now What? How to Actually Launch the Project It Just Handed You

Lovable built my app — so why isn't it live yet?

Lovable built your app — now what? The honest reframe: it is not prompt-to-product, it is prompt-to-project. What you have is a real, running codebase, not a live product your users can reach. Lovable gets you to a working project in minutes; turning that project into a launched product is a separate, well-understood set of steps. This guide walks all of them.

The confusion is built into the demo. The editor preview looks like a finished website, so it is natural to assume you are done. But that preview runs inside Lovable's sandbox — it is not deployed at your domain, its environment variables are supplied by the editor, and no outside user can reach it. The app is real and yours; it simply has not been launched yet.

Think of it the way a developer would: Lovable generated your scaffold in minutes instead of weeks. That is the genuinely hard part it removed. What remains is the same launch checklist every web app has always had — and the good news is it is finite, predictable, and walkable in an afternoon for a small app.

What does 'prompt-to-project, not prompt-to-product' actually mean?

Prompt-to-project means Lovable hands you the thing engineers used to spend weeks scaffolding: a real React front end, a Supabase database, auth wiring, and a working preview. What it does not hand you is a product — something deployed at your domain, with environment variables set, payments that record, and data that real users cannot read from each other. The project is the start line.

This distinction matters because it tells you where the remaining work is. A project is code that runs in a controlled environment. A product is that code deployed reliably, secured against real users, connected to real services, and reachable at a URL you control. Lovable is exceptional at the first and deliberately leaves the second to you — which is correct, because launch decisions are yours to own.

The reason this trips people up is that the gap is invisible in a demo. Everything that separates a project from a product — a misconfigured security rule, an unset deploy variable, an unverified webhook — looks identical to a working app right up until a real user hits it. Naming the gap is the first step to crossing it deliberately instead of being surprised by it.

What does it actually take to launch a Lovable app?

To actually launch, you cross five gaps every Lovable app shares: a custom domain, a real deploy, environment variables on the host, working authentication, and payments that record. We call these The 5 Production Gaps. The preview hides all five because the editor sandbox fills them in for you. Crossing them is what turns a project into a live product people can pay for.

None of these five is hard in isolation — the trouble is that the preview makes all five look already solved. You only discover an unset variable, an open security rule, or a dead webhook once the app is deployed and a real user does something the sandbox never tested. Walking the list deliberately, before launch, is how you avoid finding out the hard way.

Related: The 5 Production Gaps in depth · Common Lovable deployment errors

How do I connect a domain and deploy my Lovable app?

Connect a custom domain and trigger a real deploy. In Lovable, open the publish or deploy panel, point your domain's DNS at the host, and wait for SSL to provision. The catch beginners miss: the editor preview is not your live site. Publishing is a distinct action, and your custom domain often sits in a stuck pending state until DNS and SSL both resolve correctly.

1. In the Lovable editor, open the publish/deploy panel and trigger a publish — this creates your live build, separate from the editor preview.
2. Confirm the published build loads at its default URL before touching DNS. If the default URL works, deployment itself is fine.
3. Add your custom domain in the domain settings and copy the DNS records Lovable gives you (usually an A or CNAME record).
4. Add those records at your domain registrar (GoDaddy, Namecheap, Cloudflare, etc.) and save. DNS changes can take minutes to a few hours to propagate.
5. Wait for the domain status to flip from pending to active and for SSL to provision — your site should load over HTTPS with no certificate warning.
6. Load the live URL in a fresh incognito window to confirm a real visitor — not just you, logged into the editor — can reach it.

Related: Custom domain stuck pending — what to check

Why does my app work in the preview but break after deploy?

Set every environment variable on your host, not just in the editor. This is the single most common launch failure: keys like VITE_SUPABASE_URL work in the Lovable preview but vanish when you deploy, because the editor and the deployed runtime are separate environments. If your live app throws supabaseUrl is required while the preview works fine, an unset host variable is almost always why.

The mechanism is simple once you see it. During development, Lovable injects your secrets into the preview for you. When you publish, that injection does not automatically carry over to the deployed runtime — you have to add the same keys to the host's environment settings. Skip that and the app builds successfully but crashes on first load because the Supabase client initialises with no URL.

The fix is mechanical, not mysterious. Copy every variable your app reads at runtime — at minimum VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY, plus any Stripe or third-party keys — into the host's environment panel, then redeploy. Anything prefixed VITE_ is read at build time, so a fresh deploy after adding them is required for the change to take effect.

Related: Why env vars vanish on deploy

Do I need to do anything special for auth, data security, and payments?

Verify auth and payments end to end before you call it launched. Auth that logs in cleanly in the preview can still leak data if Row Level Security is misconfigured — any user reading every user's rows. Payments are worse: Stripe checkout can succeed while your app never records the sale, because the webhook that confirms it was never verified or never fired. Test both on the real deploy.

Security is the gap that hurts most because it is silent. Lovable can ship a Supabase database with Row Level Security wide open, meaning a logged-in user could query every other user's data. There is no error, no broken screen — the app looks perfect right up until someone notices they can see records that are not theirs. Verify your RLS policies on the live deploy, not in the demo.

Payments fail the same quiet way. A Stripe checkout can charge a customer and return success while your app never learns the payment happened, because the confirming webhook was misconfigured or never reached your endpoint. The result: the customer pays, your database does not update, and you ship nothing. Trigger a real test payment on the deployed build and confirm the webhook returns a 200 before you go live.

Related: Lovable RLS and auth best practices · Stripe webhook not firing — how to fix

When should I bring in help to launch instead of doing it solo?

Bring in help when a gap is structural, not cosmetic — misconfigured RLS, a deploy that works locally but 404s in production, a webhook that silently never fires, or env vars you cannot get to stick. These are the launch blockers that prompt iteration cannot safely unwind, and they are exactly where a senior engineer is fastest. You keep full ownership of your code and data throughout.

There is a clear line between a launch step and a launch blocker. Steps — publishing, pointing DNS, adding host variables, testing a payment — are well-defined and most founders can do them with a checklist. Blockers are when one of those steps fails for a reason the interface does not explain, and re-prompting Lovable cannot help because the problem lives in DNS, in a security policy, or in an external webhook config.

A good launch handoff is cheap insurance: a specialist reads your actual source files, crosses the failing gap without burning prompt credits, and leaves you with a working deploy plus a plain-English explanation of what was wrong. If you would rather own the code on your own infrastructure long term, the same engineer can also migrate the project to your own Supabase or host as part of getting you live.

Related: Hire a Lovable expert to launch · Migrate to your own Supabase or host