back_to_blog

2026-08-22 · 9 min read

Taking a Lovable prototype to production (auth, email, deploy)

What actually has to happen between a Lovable preview and a URL you can send to real users: auth, email verification, env vars, and Vercel.

A Lovable preview is a demo. Production is a URL that stays up when someone from your waitlist clicks “Sign up” at midnight. The gap is almost always authentication, email delivery, environment secrets, and hosting — not more screens.

#1. Freeze the one journey that must work

Before polishing animations, write down the path that proves the product: sign up → verify email → land in an empty dashboard → create one object → see only your own data. Everything else is backlog. Founders who skip this ship a beautiful shell with a broken first session.

#2. Auth that survives a hard refresh

  • Supabase Auth with email/password or OAuth — pick one primary path for the MVP.
  • Confirm the session is restored on reload (Lovable + supabase-js client configured with the project URL and anon key).
  • Protect routes: unauthenticated users bounce to login; authenticated users never hit an empty auth gate that loops.

#3. Email verification that actually sends

Default Supabase email is fine for early tests and then hits rate limits or spam folders. For anything you show clients, connect a custom SMTP (Resend, etc.) in Supabase Auth settings and test the full verify link on a phone that is not already logged in.

Checklist I run before launch:
[ ] Sign up with a fresh inbox
[ ] Click verify on a different device
[ ] Password reset works
[ ] OAuth callback URL matches production domain
[ ] RLS enabled on every user table

#4. Env vars and secrets

Put NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY (or the Lovable equivalents) in the host’s environment — never commit service-role keys. Stripe secret keys and webhook secrets stay server-side. If the MVP charges money, wire test mode first, then flip live keys only after a successful test checkout.

#5. Deploy somewhere boring

I usually ship Lovable-derived apps on Vercel with a custom domain. Connect GitHub, set env vars, trigger a production deploy, then hit the production URL for the same auth checklist — preview URLs lie about OAuth callbacks and cookie domains.

  • Add the production site URL to Supabase Auth redirect allow-list.
  • Confirm HTTPS and that www vs apex matches your canonical host.
  • Hand over: GitHub access, env list (names only in docs), schema notes, and “what breaks if X”.

#What I ship as a Lovable AI MVP

When clients hire me for idea-to-live scope, the deliverable is that production URL plus ownership of the repo — not another preview. If the prototype already exists but auth or deploy is on fire, that is rescue work on the Lovable Developer page. Same stack; different starting point.