Vercel preview URLs are deceptively easy to ignore. Every PR ships one, you glance at it for a second, you merge. The problem: previews diverge from prod in subtle ways and nobody notices until customers do.
Treat the preview as a production rehearsal
A preview is a real deploy on real infrastructure. It runs the build the way production will. It executes the middleware production will. It serves the images production will.
So a serious workflow looks like:
- The preview URL gets posted in the PR — but also opened, scrolled, clicked.
- Hard-refresh the page; check the network tab for unexpected 4xx/5xx.
- Run Lighthouse against it (Vercel exposes this in the deployment view).
- Walk through the user journey for the feature, not just the new component.
The preview environment is not staging
A common mistake is treating preview as staging. It isn't — every PR gets its
own deploy with its own URL. If you want one durable place that always points
at "what we plan to ship," create a staging branch and let Vercel auto-deploy
it. That's where integrations, env vars, and stakeholder review live.
Promotion, not re-build
When you merge to main, Vercel promotes the existing build to production
— it doesn't rebuild. That means whatever you tested in the preview is byte-
identical to what ships. Use this. If the preview is broken, do not merge.
Env vars are the silent killer
The number-one source of "worked in preview, broke in prod" is environment variables scoped to the wrong environment. Audit:
- Which env vars are set for
Production,Preview,Development? - Are there any "preview only" debug vars that prod doesn't have?
- Does your
vercel env pullgive your local the right slice?
If preview discipline becomes a habit, you stop deploying surprises.