I've deployed over 20 projects on Vercel across the last two years. Portfolio sites, SaaS dashboards, client demos, AI-powered tools, and internal utilities. Vercel's DX is exceptional, but there are production lessons that the getting-started docs don't cover.
Lesson 1: Preview deployments are your QA environment. Every pull request gets a unique URL. I share these URLs with clients for review before merging to main. The feedback loop drops from 'deploy → client tests → files bug → I fix → redeploy' to 'preview URL → client reviews → approves → merge.' For client-facing projects, this workflow alone justifies the Vercel Pro plan.
Lesson 2: Environment variables need discipline. I use a naming convention: NEXT_PUBLIC_ prefix for client-side variables, no prefix for server-only secrets. Every project has a .env.example committed to the repo with placeholder values and comments explaining each variable. When a teammate (or future me) sets up the project, they copy .env.example to .env.local and fill in the values. No guessing, no Slack messages asking 'what's the Supabase URL?'
Lesson 3: Edge functions and serverless functions have different cold start profiles. For API routes that need to respond in under 200ms (WhatsApp webhook endpoints, for example), I use Edge Runtime. For routes that need Node.js APIs (file system access, heavy computation), I use the default serverless runtime and accept the occasional cold start. Knowing which runtime to choose per route is a meaningful performance decision.
Lesson 4: The Vercel Analytics and Speed Insights integrations are worth enabling on every project. They give you real-user metrics (LCP, FID, CLS) segmented by device, browser, and geography. I discovered that one portfolio site had a 4.2-second LCP on mobile in Brazil due to an unoptimized hero image — the desktop metrics looked fine, but 70% of visitors were on mobile. Vercel Analytics surfaced this in the first week.
Lesson 5: Monorepo support with Turborepo is powerful but requires setup discipline. I tried consolidating three client projects into a single monorepo. The shared component library worked beautifully, but build times increased because Vercel was rebuilding all projects on every push. The fix: configure Root Directory in Vercel project settings and use the Ignored Build Step command to skip rebuilds for unchanged projects.
Lesson 6: Custom domains with Vercel are straightforward, but DNS propagation still catches people. I always set up the domain 24 hours before the client launch date. For projects still in development, I use the .vercel.app subdomain. When the client is ready to go live, I add their custom domain and the SSL certificate provisions automatically.
The deployment pattern I use for every new project: push to GitHub → Vercel auto-deploys preview → test on preview URL → merge to main → Vercel auto-deploys production → verify production URL → enable Analytics. Total time from code complete to live: under 10 minutes. That speed is why I keep coming back to Vercel despite having experience with AWS, GCP, and Cloudflare.