Vibecoders rompiendo producción

Índice

Tienes la aplicación terminada y el dedo encima del botón de publicar. Esta es la lista que repaso yo antes de darle, y está ordenada por lo que más duele si te lo saltas.

No es una lista de buenas prácticas para algún día: son doce comprobaciones concretas, cada una con lo que hay que mirar y cómo se mira. Al final tienes un prompt que se lo pega a tu agente y te devuelve el repaso entero hecho sobre tu código.

1. Prueba los flujos críticos de punta a punta

Un flujo crítico es el que, si se rompe, tu aplicación no sirve para nada: entrar, hacer lo que promete y, si cobras, pagar. Probarlo de punta a punta significa recorrerlo entero como lo haría alguien que llega de cero, no comprobar que cada pieza funciona por separado.

Y hazlo en un ordenador que no sea el tuyo, o al menos en una ventana de incógnito y con otra cuenta. Casi todo lo que se cae el día del lanzamiento funcionaba perfectamente en la máquina de quien lo escribió, porque ahí ya estaba la sesión abierta, la caché caliente y los datos de siempre.

2. Testea login, registro y recuperación

Son cuatro caminos, no uno: registrarse con un correo que jamás ha entrado, iniciar sesión, cerrarla y volver a entrar, y recuperar la contraseña. El cuarto es el que se rompe siempre, porque es el único que depende de que un correo salga de tu servidor y llegue a otro sitio de verdad.

Comprueba también lo aburrido: que el enlace de recuperación caduque, que se pueda usar una sola vez y que cerrar sesión invalide la sesión en el servidor y no solo borre una cookie del navegador. Y prueba el registro con un correo que ya existe: eso tiene que decir algo claro, no reventar.

3. Revisa los roles y los permisos

Si tu aplicación tiene más de un tipo de usuario, tienes una tabla que probar: cada ruta por cada rol. Y hay una casilla que se salta casi todo el mundo, que es un usuario normal escribiendo a mano la dirección del panel de administración. Que el enlace no se le enseñe no significa que no pueda entrar.

Lo importante es dónde se comprueba. Esconder un botón en el navegador no es un permiso: es maquillaje. El permiso se comprueba en el servidor, en cada petición, y si no está ahí, no está. Prueba también qué pasa cuando a alguien le quitas el rol mientras tiene la sesión abierta.

4. Comprueba las variables de entorno

Tu portátil tiene un .env que se ha ido llenando durante semanas y del que ya no te acuerdas entero. Producción no tiene nada de eso hasta que lo pones a mano, variable por variable, y basta con que falte una para que la aplicación arranque a medias y falle en el sitio más raro.

Haz que no arranque si le falta una obligatoria. Es una comprobación al principio del proceso que corta el despliegue con un mensaje claro, y te ahorra enterarte por un error 500 a las tres de la mañana. Repasa también que las claves sean las de verdad y no las de prueba: sk_test y sk_live se parecen mucho a las once de la noche.

5. Ni una clave publicada, en ningún sitio

Las claves van en el gestor de variables de tu hosting y en ningún otro sitio. El .env en .gitignore, un .env.example con los nombres y sin los valores, y se acabó. Esto lo sabe todo el mundo y sigue siendo por donde entran, porque el problema no es la clave que escribes: es la que se cuela sin que la escribas.

Los tres sitios donde se cuela: en lo que llega al navegador, porque cualquier variable que viaje al cliente es pública por definición; en los registros del despliegue, que imprimen entornos enteros; y en la captura del panel que subes a redes. Y si ya se publicó, no se borra: se rota. Lo que entra en el historial de Git se queda en el historial de Git.

6. Prueba pagos y webhooks de verdad

El cobro no acaba en la pasarela: acaba cuando tu servidor recibe el aviso, comprueba que viene de quien dice y le da acceso al usuario. Ese aviso es el webhook, y es la pieza que nadie prueba porque en local no llega solo. Hay que reenviárselo con la herramienta de la pasarela, y hay que verificar la firma siempre.

Prueba los tres casos, no solo el bueno: el pago que sale bien, el que la tarjeta rechaza y el aviso que llega dos veces. Las pasarelas reintentan cuando no les respondes rápido, así que si tu código no es idempotente le vas a dar dos meses de acceso, o a cobrarle dos veces. Y haz al menos un cobro real de un euro antes de abrir.

7. Testea los errores, la carga y el vacío

Toda pantalla que pide datos tiene cuatro estados y tú solo has mirado uno. Está la que carga, la que tiene datos, la que no tiene ninguno y la que ha fallado. La de datos es la única que ves mientras desarrollas, porque tu base de datos lleva meses llena y tu red es instantánea.

La vacía es la más importante de todas: es la primera que ve cada usuario nuevo. Si dice «no hay nada», estás desperdiciando el mejor momento para decirle qué hacer. Y el error tiene que ofrecer una salida —reintentar, volver— en vez de dejar a alguien mirando una pantalla en blanco. Prueba la carga con la red estrangulada desde el navegador.

8. Revisa el móvil de verdad

Lo has construido en un portátil y lo van a abrir en 390 píxeles de ancho, sobre todo si llegas desde redes sociales. No basta con estrechar la ventana del navegador: hay cosas que solo se ven en un teléfono real, como el teclado tapando el campo que estás rellenando o el área que de verdad se puede pulsar con el pulgar.

Mira lo que siempre se rompe: tablas anchas que sacan una barra horizontal en toda la página, botones pegados al borde inferior donde vive la barra del navegador, textos que se salen y modales que no se pueden cerrar. Y ábrelo en Safari de iPhone, que sigue siendo el que se comporta distinto.

9. Elimina el modo depuración, los mocks y lo de prueba

Toda aplicación construida con prisa tiene su cementerio: la ruta /test que montaste para salir del paso, el usuario «Juan Pérez» con precio de un euro, el console.log que imprime el objeto entero del usuario y, el peor de todos, la bandera que se salta el login «solo mientras desarrollo».

No lo busques de memoria, búscalo con el buscador del editor: TODO, FIXME, test, mock, dummy, localhost, console.log. Y apaga el modo depuración en producción, porque un error detallado en pantalla le cuenta a quien está mirando cómo está montada tu aplicación por dentro.

10. Activa los registros y el aviso de errores

Si no tienes nada puesto, tu sistema de avisos es que un usuario se moleste en escribirte. Y la mayoría no escribe: cierra la pestaña y no vuelve. Necesitas dos cosas, y las dos tienen plan gratis: registros que puedas leer y una herramienta que capture los errores con su traza y te avise.

Que el aviso llegue a donde tú miras, sea el correo o Slack. Y cuando guardes el error, guarda con él qué usuario era y qué estaba haciendo, pero sin meter dentro contraseñas ni tokens, que es exactamente el punto cinco de esta lista repitiéndose por la puerta de atrás.

11. Configura las copias de seguridad

Automáticas, diarias y guardadas en otro sitio, no junto a la base de datos que puede caerse con ella. Casi todos los servicios gestionados las traen puestas, pero «venir puestas» y «funcionar» son cosas distintas hasta que lo compruebas tú.

Y aquí está lo que casi nadie hace: restaurar una, una sola vez, con el cronómetro en la mano. Hasta que no lo haces no sabes las dos cosas que hay que saber antes de necesitarlo, que son cuánto dato puedes llegar a perder y cuánto tardas en volver a estar en pie.

12. Ten preparada la vuelta atrás

Vas a desplegar algo que rompe la aplicación. No es pesimismo, es estadística. La diferencia entre un susto de dos minutos y una tarde infernal es si volver a la versión anterior es un botón que ya sabes dónde está o algo que buscas por primera vez mientras la gente se queja.

Averigua hoy cómo se vuelve atrás en tu hosting y pruébalo una vez con la aplicación funcionando. Si además tienes migraciones de base de datos, comprueba que la versión anterior sigue funcionando con el esquema nuevo, porque el código vuelve atrás en un clic y los datos no.

13. Que lo compruebe la máquina: los pre-commits

Todo lo de arriba depende de que te acuerdes, y no te vas a acordar. Un hook de pre-commit es un script que Git ejecuta antes de dejarte guardar el cambio, y si falla, no hay commit. Es la diferencia entre una lista que lees y una lista que se cumple sola.

En proyectos de Node lo habitual es Husky, que en su versión 9 se instala con un comando y deja los hooks en una carpeta .husky que sí se sube al repositorio, así que le llegan a todo el que clone. Se empareja casi siempre con lint-staged, que es lo que hace que las comprobaciones corran solo sobre los ficheros que has tocado y no sobre el proyecto entero.

La alternativa que más se está moviendo es lefthook: es un binario de Go, no depende de Node, se configura en un YAML y corre las tareas en paralelo, que en proyectos grandes se nota. Pide un lefthook install la primera vez, porque no se engancha solo al instalar dependencias. Y si tu proyecto mezcla lenguajes, pre-commit sigue siendo el que mejor lo lleva.

Lo importante no es cuál elijas, es qué metes dentro. En el pre-commit va lo que tarda segundos: formato, linter sobre lo tocado, los tipos si compensa, y una búsqueda de claves y de console.log. Los tests y el build enteros van en el pre-push o en CI. Si el pre-commit tarda medio minuto, tu equipo descubre --no-verify en dos días y ya no te protege de nada.

No lo repases de memoria: pásaselo a tu agente

Doce puntos no se recuerdan a las once de la noche con ganas de publicar. Por eso está el botón de aquí abajo: es esta lista entera convertida en un encargo que tu agente entiende.

Lo pegas en Claude Code, en Cursor o en el que uses, y te devuelve un informe punto por punto, con el fichero y la línea, ordenado de más grave a menos y sin tocar nada hasta que tú lo digas. Y lo que salga en rojo ya sabes dónde mirarlo, porque está más arriba.