Repaso y práctica

Puntos clave

• Publicar es un flujo de trabajo, no un momento: desplegar, observar, corregir, repetir — y haz que revertir sea algo que ya has probado una vez.
• Ejecuta la lista de verificación previa al lanzamiento antes de anunciar nada, y deja que la IA verifique cada elemento en lugar de confiar en tu memoria.
• Deja que la medición guíe la optimización — un informe de Lighthouse le gana a una corazonada sobre qué "se siente lento" siempre.
• Los secretos viven en la configuración de producción, nunca en el repositorio; .env está en gitignore y .env.example se mantiene actualizado.
• La primera versión es una hipótesis; los usuarios reales son el experimento, así que itera con correcciones pequeñas y rápidas.

Ponlo en práctica

Toma una app que hayas desplegado (o despliega una pequeña ahora mismo) y recorre la lista de verificación previa al lanzamiento completa contra ella, línea por línea. Por cada casilla que no puedas marcar honestamente, pégale el elemento fallido a la IA y pide el cambio más pequeño que cierre la brecha. Termina haciendo clic en un enlace profundo del sitio en vivo — no solo la página de inicio — para confirmar que producción se comporta como en desarrollo.

Prompt del 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.