Recapitulação e Prática

Principais aprendizados

• Entregar é um fluxo de trabalho, não um momento: faça deploy, observe, corrija, repita — e transforme o rollback em algo que você já testou uma vez.
• Rode a checklist pré-lançamento antes de anunciar qualquer coisa, e peça para a IA verificar cada item em vez de confiar na sua memória.
• Deixe a medição guiar a otimização — um relatório do Lighthouse vence um palpite sobre o que "parece lento" todas as vezes.
• Segredos vivem na configuração de produção, nunca no repositório; .env está no gitignore e .env.example permanece atualizado.
• A primeira versão é uma hipótese; usuários reais são o experimento, então itere em correções pequenas e rápidas.

Coloque em prática

Pegue um app que você já entregou (ou entregue um pequeno agora) e rode a checklist pré-lançamento completa contra ele, linha por linha. Para cada caixa que você não consegue marcar honestamente, cole o item que falhou para a IA e peça a menor mudança que fecha a lacuna. Termine clicando em um link profundo no site ao vivo — não apenas na página inicial — para confirmar que a produção se comporta como o dev.

Prompt do capítulo

Here is my deployed app and its stack: [describe app + hosting + services].
Act as my launch reviewer. Walk this pre-launch checklist item by item
and, for each, tell me how to verify it on the LIVE site (not in dev):
- production URL loads over valid HTTPS on the custom domain
- all secrets set in production; none committed to the repo
- core happy path (sign-up, login, main action) works in production
- payments tested end-to-end including the webhook (if any)
- error tracking and uptime monitoring are live
- I can roll back, and have tested it once
- mobile layout works on a real phone
- database backups are enabled
For every item that fails, give me the SMALLEST change that fixes it.
Do not assume anything passes — make me prove each one.