From Preview Link to Production Domain for an AI-Built App

A preview link is a comfortable place to build. The platform picked the domain, issued the certificate and filled in most of the configuration. Moving to your own domain removes that cushion, and AI-built apps tend to break in the same handful of places when it happens. This guide goes through the move in the order that avoids most surprises, with commands to confirm each step actually worked.

Before you touch DNS

Start by making a list of everything that currently knows about the preview URL. This is the step people skip, and it is the source of most post-launch bugs.

1. Auth redirect URLs. Supabase, Firebase and most auth providers keep an allow-list of URLs they will redirect to after sign-in or email confirmation. In Supabase this lives in the Authentication URL settings as the Site URL and additional Redirect URLs.
2. OAuth apps. If users sign in with Google, GitHub or similar, the provider's console has authorised origins and callback URLs that must include the new domain.
3. Webhooks. Payment providers and other services post events to a URL you registered. Those endpoints need to move too.
4. Hard-coded URLs in code. Search for the preview hostname:

grep -rn "lovable.app\|netlify.app\|vercel.app\|bolt.new\|localhost:" src/ supabase/ 2>/dev/null

Replace anything you find with an environment variable such as SITE_URL, so the next domain change is a configuration change rather than a code change.

5. Environment variables. Confirm which variables the production deployment needs and that each one is set in the hosting provider's dashboard for the production environment, not only for previews.

Step 1: Point the domain at your host

Your hosting provider will tell you which records to create. The usual pattern:

• For a subdomain such as www.example.com or app.example.com, a CNAME record pointing at the host's target name.
• For the apex domain example.com, which cannot normally be a CNAME, either an A record to the IP address the host provides, or an ALIAS/ANAME/flattened record if your DNS provider supports it.

Lower the TTL on existing records a day before switching if you can, so mistakes propagate out quickly. After creating the records, check them from your machine:

dig +short www.example.com CNAME
dig +short example.com A

The answers should match what the host asked for. If they show old values, you are probably seeing cached data; wait for the TTL to expire rather than changing the records again.

Step 2: Confirm HTTPS and pick one canonical host

Most hosts issue a certificate automatically once DNS resolves to them. Verify it, and verify that every variant ends up on a single canonical address:

curl -sI http://example.com | grep -i "^location"
curl -sI https://example.com | grep -i "^location"
curl -sI https://www.example.com | head -1

You want plain HTTP to redirect to HTTPS, and either the apex or www to redirect to the other with a permanent redirect. Pick one and stick with it; it affects cookies, auth redirects and search indexing.

Step 3: Fix single-page app routing

Many AI builders generate single-page apps. On the preview, deep links like /dashboard/settings work because the platform is configured to serve index.html for unknown paths. On a new host, the same URL may return a 404 on refresh. On Netlify, a _redirects file in the published folder containing /* /index.html 200 handles this; on Vercel, a rewrite in vercel.json does the same job. Test by loading a deep link directly in a new tab, not by clicking through from the home page.

Step 4: Run a production smoke test

With the domain live, walk through the critical flows in a fresh private window, in this order:

1. Load the home page and two deep links directly.
2. Sign up with a new email and complete confirmation; check the confirmation link points at the new domain.
3. Sign in with each OAuth provider.
4. Complete one test-mode payment and confirm the webhook updated your database.
5. Trigger any outbound email and check links inside it.
6. Open the browser console and look for blocked requests or mixed-content warnings.

Keep the preview deployment available for a few days as a fallback, but update anything that still references it.

If this list surfaces problems you would rather hand off, deployment and domain setup is a common short engagement for freelance developers, and you can find people who finish apps built with tools like Lovable, Bolt or Replit on workli.tech among other places. Share your checklist results with them; knowing exactly which step fails is most of the diagnosis.

A domain move is mostly bookkeeping, not engineering. The apps that launch cleanly are the ones where someone listed every place the old URL lived before changing DNS, then tested from the outside afterwards. Do both, and the switch becomes a quiet afternoon rather than a weekend of firefighting.