Fiz deploy de mais de 20 projetos na Vercel nos últimos dois anos. Sites de portfólio, dashboards SaaS, demos para clientes, ferramentas com IA e utilitários internos. A DX da Vercel é excepcional, mas há lições de produção que a documentação de primeiros passos não cobre.
Lição 1: Deploys de preview são seu ambiente de QA. Cada pull request recebe uma URL exclusiva. Compartilho essas URLs com clientes para revisão antes do merge em main. O ciclo de feedback passa de 'deploy → cliente testa → registra bug → eu corrijo → novo deploy' para 'URL de preview → cliente revisa → aprova → merge'. Para projetos voltados a clientes, só esse workflow já justifica o plano Vercel Pro.
Lição 2: Variáveis de ambiente exigem disciplina. Uso uma convenção de nomes: prefixo NEXT_PUBLIC_ para variáveis do cliente, sem prefixo para segredos exclusivos do servidor. Cada projeto tem um.env.example commitado no repositório com valores de exemplo e comentários explicando cada variável. Quando um colega de equipe (ou eu no futuro) configura o projeto, copia.env.example para.env.local e preenche os valores. Sem adivinhação, sem mensagens no Slack perguntando 'qual é a URL do Supabase?'
As integrações Vercel Analytics e Speed Insights dão LCP, FID e CLS reais, segmentados por dispositivo, navegador e geografia. Encontrei um site com LCP de 4,2s no celular no Brasil por causa de um hero image não otimizado: as métricas de desktop pareciam boas.
Um monorepo com Turborepo compartilha a biblioteca de componentes, mas os builds cresceram porque a Vercel reconstruía todos os projetos a cada push. A correção é Root Directory nas configurações do projeto mais um Ignored Build Step que pula projetos sem alterações.
Lição 5: O suporte a monorepos com Turborepo é poderoso, mas exige disciplina na configuração. Tentei consolidar três projetos de clientes em um único monorepo. A biblioteca compartilhada de componentes funcionou muito bem, mas os tempos de build aumentaram porque a Vercel reconstruía todos os projetos a cada push. A correção: configurar Root Directory nas configurações do projeto na Vercel e usar o comando Ignored Build Step para pular rebuilds de projetos sem alterações.
O ciclo completo é: push para GitHub, deploy de preview na Vercel, testar na URL de preview, merge em main, deploy de produção, verificar a URL e habilitar Analytics. Menos de dez minutos do código pronto ao ar.
O padrão de deploy que uso em cada novo projeto: push para o GitHub → Vercel faz deploy automático do preview → teste na URL de preview → merge em main → Vercel faz deploy automático de produção → verificação da URL de produção → habilitar Analytics. Tempo total do código concluído até entrar no ar: menos de 10 minutos. Essa velocidade é o motivo de eu continuar voltando à Vercel, apesar da experiência com AWS, GCP e Cloudflare.
Referência: documentação da Vercel sobre preview deployments.