Deploying to Vercel is usually the easy part. You connect your GitHub repository, click deploy, and get a URL. The hard part is everything around it: the settings that work fine on your laptop and quietly break in production.
This checklist covers the problems that come up most often on a first launch of a Next.js app with Supabase. Run through it before you send the link to anyone, ideally the day before you plan to share it.
Environment variables
Your app reads keys and URLs from environment variables. Locally they live in a .env.local file. Vercel never sees that file (and shouldn’t, since it isn’t in Git), so you have to add each value in the project settings yourself.
- Every variable in .env.local is also set in Vercel, spelled exactly the same. One typo in a name is enough to break sign-in.
- Each variable is assigned to the right environments: Production, Preview, or both.
- Only values meant for the browser start with NEXT_PUBLIC_. Secret keys never do, because that prefix ships the value to every visitor.
- Production uses production values. If you use Stripe or Polar, that means live keys in Production, test keys everywhere else, and a deliberate decision about when you switch.
- You redeployed after changing variables. Existing deployments don’t pick up new values on their own.
Domain
- The domain is added in your Vercel project’s domain settings.
- The DNS records Vercel shows you are added at your registrar, exactly as shown.
- Vercel lists the domain as valid and HTTPS works. DNS changes can take time to spread, so do this early rather than on launch morning.
- You’ve picked either www or the bare domain as the main address, and the other one redirects to it.
Auth redirects
This is the one that catches almost everyone. Sign-in works locally, then fails in production because the auth system still thinks your app lives at localhost.
- In Supabase’s Authentication URL settings, the Site URL is your production domain, not localhost.
- Your production domain is in the list of allowed redirect URLs. Add your Vercel preview URLs too if you test sign-in on previews.
- Confirmation and password-reset emails link to production. Send yourself one and click it to be sure.
- If you offer Google or another sign-in provider, that provider’s console has the callback URL Supabase’s docs tell you to use.
Payments, if you charge
- The webhook endpoint in the Stripe or Polar dashboard points at your production URL.
- The webhook signing secret saved in Vercel belongs to the production endpoint, not the one you used for local testing.
- You’ve run a full purchase in test mode on a preview deployment, including what happens when a card is declined.
The smoke test
A smoke test is a quick run through the critical path on the real production URL, the way a real user would experience it. Use a private browser window so nothing cached or already signed in hides a problem.
- Load the home page on a laptop and on your phone.
- Sign up with a brand-new email address. Confirm the email arrives and the link works.
- Complete the core flow from your PRD, start to finish.
- Sign out and sign back in. Your data should still be there.
- Run the two-browser test: a second account must not be able to see the first account’s data.
- Do one thing that should fail, like submitting an empty form, and check that the error makes sense.
- If you charge, make one real purchase at your lowest price, then refund it.
The first few hours after
Keep Vercel’s logs open and look for errors as the first visitors arrive. Watch new sign-ups appear in Supabase. Real users will find paths you never tested, and that’s normal. It’s the reason to launch to a small group first and widen once the obvious problems are fixed.
Write down every issue you see in the first day, even the small ones. Fix the ones that block the core flow immediately and batch the rest for your next build block.
In the 30-Day Build & Launch Sprint you run this checklist against your own app with help on hand, but the list above is enough to get you safely to a public URL on your own.