The Lovable-to-production checklist

A Lovable project that looks perfect in the preview can still embarrass you on launch day: a contact form that posts into the void, a www subdomain that will not resolve, analytics that were never installed. None of these are hard problems. They are just easy to forget, because Lovable's preview hides them all.

This is the checklist we run before pointing a real domain at a Lovable-built site. Work through the eight items in order. Most take a minute or two.

1. Pick your export path deliberately

Lovable gives you two ways to get the project out: push to GitHub, or download a ZIP.

• GitHub gives you a connected repo that Lovable keeps updating as you edit. Choose this if you plan to keep iterating, because it unlocks automatic redeploys later (item 8).
• ZIP is a one-off snapshot. Fine for a site that is genuinely finished, but every future Lovable edit means downloading and uploading again.

Decide now, not after launch. Switching later works but costs you a re-setup.

2. Confirm the build actually builds

Lovable projects are Vite-based React apps. If you took the ZIP route, verify the build on your machine before uploading anything:

npm install
npm run build

You want a clean exit and a dist/ folder. If the build fails locally it will fail everywhere, and it is far easier to debug now than mid-launch. On the GitHub route, VibeDeploy detects Vite and runs the build for you, so this item becomes "check that the first deploy log is green".

3. Give every form a real destination

This is the single most common post-launch surprise. Lovable happily generates a beautiful contact form, but a static export has no server to receive the submission. Two working setups:

• Supabase or another external API. If Lovable wired the form to Supabase, that keeps working after export, because the browser talks to Supabase directly. Test one real submission from the deployed site, not the preview.
• VibeDeploy forms relay. For plain contact forms with no backend, enable the forms relay in your site settings and point the form at your site's relay endpoint. Submissions arrive in your mailbox by email. No server, no third-party form SaaS.

Whichever you use, submit the form once from the live site and confirm the message actually arrives. "The form looks fine" is not a test.

4. Install analytics before launch, not after

Traffic from launch day is the traffic you most want to see, and it is unrecoverable. VibeDeploy shows per-site traffic in the dashboard out of the box. If you want your own tooling on top, add the snippet to the Lovable project now and redeploy, so day one is measured.

5. Stage the DNS change

Get the boring parts of DNS ready before you flip anything:

• Add the domain in your VibeDeploy site settings and note the records it asks for: an A record for the apex, a CNAME for www pointing at proxy.vibedeploy.be.
• Check the current TTL on any existing records at your registrar. A long TTL means slow propagation, so lower it ahead of time if you are migrating a domain that is already in use.
• If you also set a custom domain inside Lovable at some point, remove it there. Two hosts fighting over one domain produces exactly the intermittent weirdness you would expect.

6. Verify SSL end to end

Once DNS resolves, VibeDeploy issues a Let's Encrypt certificate automatically, usually within a minute. Then check three URLs in a fresh browser tab: https://example.com, https://www.example.com, and one deep link like https://example.com/about. The deep link matters because it confirms SPA routing survives on the host, not just the homepage. While you are there, scan the browser console for mixed-content warnings: Lovable occasionally emits http:// asset references, and a search-and-replace to https:// fixes them.

7. Know your rollback story

Before launch is the right moment to ask "what happens when a deploy goes wrong?", because the answer should never be improvised at 23:00. On VibeDeploy every deploy is a snapshot, and previous versions stay restorable for up to 30 days on paid plans. Find the restore button in the dashboard now, so that a bad Lovable regeneration is a one-click rollback rather than an incident.

You can also use staging as the buffer in front of production: deploy changes to a staging copy of the site first, click through it, and only then promote to the live domain. For client work this doubles as the review link you send before go-live.

8. Close the redeploy loop

The site will change next week, so make next week's deploy free:

• GitHub route: connect the repo in VibeDeploy's site settings. Every Lovable edit that pushes to GitHub redeploys automatically. Nothing to remember.
• ZIP route: export the deploy guide from your dashboard and keep it with the project. Paste it into Claude, ChatGPT, or Cursor and the AI can redeploy the build straight to the API after each change, which beats manually re-uploading a ZIP forever.

The launch itself

If all eight boxes are ticked, launch is anticlimactic: flip the DNS records, watch the certificate provision, submit the form once more, and check that analytics registers your visit. Total cost to try the whole flow is zero, because the 14-day trial includes a custom domain, no card required; afterwards plans start at 15 euro per month including VAT.

For the tool-specific details, the export options, and the comparison with hosting on Lovable itself, see the full Lovable deploy guide. For the quick version of just the domain setup, we covered that in Deploy a Lovable site to a custom domain in 5 minutes.