Going Live: Dev-to-Prod Migration, Search Console and Performance

Summary

You have built the whole stack: architecture, auth, data, secrets and payments. Now you take it live and make sure the world can find it. Going live is not a single button - it is migrating each service from its development instance to production in a careful order, pointing your domain at the right places through Cloudflare, telling Google your site exists, and making it fast. Do it in the right order and launch day is calm. Do it ad hoc and you get the classic launch-day failure where one missed key takes down logins or billing while customers are watching. This lesson gives you the calm version.

What you will learn

You will learn a safe order for migrating Clerk and Convex from development to production, how to wire your domain and DNS with Cloudflare in front of your app, how to verify your site in Google Search Console and submit your sitemap so you get indexed, and which Lighthouse and Core Web Vitals basics actually matter for speed, SEO and conversion.

Prerequisites

A complete stack from this course - auth, data and payments, all working in development - since going live ties all three together. The Course 1 deploy lesson, because Vercel, DNS and Cloudflare appeared there and this lesson builds on them. And the production setup pieces from the Clerk, Stripe and secrets lessons, which you now bring together.

The problem

Migration is where confident builders get humbled. Each service has its own dev and prod worlds (Clerk instances, Convex deployments, Stripe modes), and switching them in the wrong order or forgetting one key leaves a half-live app where users can sign up but their data vanishes, or they can pay but never get access. Meanwhile, even a perfect launch is invisible if Google does not know your site exists and your pages are slow. Founders pour weeks into building and then fumble the last mile, so the product launches broken or unfindable. This lesson is that last mile, done in a deliberate order.

A safe migration order

Migrate one service at a time and verify each before the next, so if something breaks you know exactly which step caused it. The safe order is: domain and DNS first (so the address exists), then Convex (so data has a home), then Clerk (so auth points at the live domain and the live database), then Stripe (so payments grant access to the now-live system), then deploy with all the live keys in place. After each switch, test the real flow before moving on. The single most common failure is leaving one test key in the deployed environment, so do a final sweep of every environment variable and confirm not a single sk_test, pk_test or test webhook secret survives in production.

• Domain and DNS first: register the domain, point it through Cloudflare at your app and marketing site.
• Convex next: create the production deployment, set its env vars, deploy your schema and functions to it.
• Clerk next: create the production instance, add its DNS records, configure Google OAuth, swap to pk_live / sk_live.
• Stripe last: activate the account, recreate products and prices in live mode, register the live webhook endpoint, swap to live keys.
• Final sweep: confirm zero test keys remain in production env vars, then deploy and test the full signup-to-payment flow live.

Domain, DNS and Cloudflare in front

Your marketing site and your app live at different addresses, usually the bare domain (yoursite.com) for marketing and a subdomain (app.yoursite.com) for the app, exactly as the architecture lesson described. You point both through DNS, and a common, strong pattern is to put Cloudflare in front: manage DNS at Cloudflare, get its free HTTPS and global CDN, and route each name to the right place (Vercel for both surfaces, typically). Remember the Clerk subdomains from lesson 2 - those CNAME records usually want to be DNS-only (grey cloud) rather than proxied, so they do not break the auth TLS handshake. Cloudflare in front gives you speed and basic protection for free, which is why most builders use it. Take care that you are not double-proxying or double-handling HTTPS, the gotcha from Course 1.

; Example DNS layout (real targets come from Vercel / Clerk)
; Type   Name      Value / target            Proxy
CNAME    @         cname.vercel-dns.com      proxied   ; marketing site
CNAME    app       cname.vercel-dns.com      proxied   ; the app
CNAME    clerk     frontend-api.clerk.services  DNS only ; auth - do NOT proxy
CNAME    accounts  accounts.clerk.services      DNS only ; auth - do NOT proxy

Google Search Console and your sitemap

A live site that Google does not know about gets no search traffic. Google Search Console is the free tool that tells Google your site exists, shows how it indexes you, and surfaces problems early. The flow: add your site as a property, verify you own it (the easiest method is usually a DNS TXT record Search Console gives you, which you add at Cloudflare), then submit your sitemap URL. Your sitemap is the machine-readable list of your pages - this project already generates one with the generate:sitemaps script - and submitting it tells Google exactly what to crawl. After that, Search Console becomes your early-warning system: it shows indexing coverage, which queries you appear for, and any crawl errors, so you catch SEO problems before they cost you traffic.

; Verify ownership in Search Console with a TXT record (value comes from Google)
; Type   Name   Value
TXT      @      google-site-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

; Then submit your sitemap URL in the Search Console UI:
; https://yoursite.com/sitemap.xml

Indexing is not instant. After submitting, Google takes days to weeks to crawl and index a new site, and Search Console shows the progress. Submitting the sitemap and fixing any errors it reports is the highest-leverage SEO action you can take at launch.

Lighthouse and the page-speed basics that matter

Lighthouse is the free audit built into Chrome (and runnable in CI) that scores your pages on performance, accessibility, best practices and SEO. Fast pages convert better and rank better - Google uses Core Web Vitals as a ranking signal, and AI crawlers favour fast, clean pages too - so treating speed as part of launch pays off twice. You do not need to chase a perfect 100 on every metric, but you should understand the handful of things that actually move the needle, because most slow sites are slow for the same few reasons. Run Lighthouse on your marketing pages especially, since those are your funnel's front door and where speed matters most.

• Images: the number one culprit. Serve modern formats (WebP/AVIF), size them correctly, and lazy-load below-the-fold images.
• JavaScript: ship less of it. This is exactly why the marketing site uses a content-first framework - fewer scripts, faster pages.
• Largest Contentful Paint (LCP): how fast the main content appears. Optimise your hero image and fonts to improve it.
• Cumulative Layout Shift (CLS): things jumping around as the page loads. Reserve space for images and ads so nothing shifts.
• Fonts: load them efficiently and avoid invisible-text flashes. Self-hosting and preloading help.
• Caching and the CDN: Cloudflare in front already serves static assets fast worldwide - lean on it.

Typical mistakes

The launch-day classics: leaving a test key in production so logins or payments silently fail; migrating services in a tangled order so you cannot tell what broke; proxying Clerk's auth subdomains through Cloudflare and breaking the TLS handshake; forgetting to register the live Stripe webhook endpoint, so production payments never grant access; never verifying the site in Search Console or submitting the sitemap, so the launch is invisible to Google; and shipping heavy, unoptimised images that tank Lighthouse and conversion. Every one is prevented by the ordered checklist and a final environment-variable sweep.

Business ROI

The last mile is where all your building either pays off or quietly fails. A clean migration means launch day is boring instead of an outage in front of your first customers. Search Console and the sitemap are the difference between a product that compounds traffic over months and one that nobody ever finds. And page speed is a direct lever on both conversion and ranking - faster pages literally make more money and rank higher, every single day they are live. For a founder, getting the last mile right protects the entire investment of building the product in the first place.

Checklist

You have completed Course 3 when all of these are true on the live product.

• Clerk, Convex and Stripe are all on production, and zero test keys remain in production env vars.
• Your domain serves the marketing site and app over HTTPS, with Cloudflare in front and Clerk subdomains DNS-only.
• Your site is verified in Google Search Console and your sitemap is submitted.
• Lighthouse on your marketing pages is healthy, with images and JavaScript optimised.

Resources

Keep the Clerk and Convex production-deployment guides, the Stripe go-live checklist, and Google Search Console open during launch - each is current where this course defers to docs. Run Lighthouse from Chrome DevTools or your CI on every marketing page. The Course 1 deploy lesson is your reference for Vercel, DNS and Cloudflare basics. You can now build and launch a complete, paid product end to end.

Your task

Take a project from this course live, even a small one. Migrate Clerk and Convex to production in the safe order, point your domain through Cloudflare, do the final env-var sweep to kill every test key, verify the site in Search Console and submit the sitemap, then run Lighthouse on your homepage and fix the two biggest issues it reports. Doing the full last mile once turns launch from a scary unknown into a routine checklist for every product you build after this.

Next lesson

You can now build and launch a real, paid product end to end: architecture, auth, data, secrets, payments and a clean go-live. Course 4 moves beyond a single app into automation and agentic systems - n8n and workflow tools, browser automation, sandboxes, and building your own AI tools that run work for you while you sleep.