La checklist de production-readiness para vibe-code

Si construiste algo con Lovable, Cursor, Claude Code, Bolt, v0 o Replit y usuarios reales están a punto de tocarlo, corre esto primero. Es una checklist independiente, ordenada por la frecuencia con que muerde cada punto, que puedes recorrer tú mismo antes de llamar a nadie. Una regla: una casilla solo cuenta cuando el servidor la impone, no la pantalla.

Esto no es un golpe al vibe-coding. Así empezamos nosotros también. Es un mapa del trabajo que no ocurre solo, para que encuentres las brechas del código generado por IA antes de que lo haga un incidente.

¿Cómo sé si mi app vibe-coded está lista para producción?

Recorre los diez checks de abajo en orden. Cada uno es una pregunta con una condición de aprobado. Si no puedes responder que sí con evidencia, no está hecho. Los tres primeros son los que se convierten en incidentes, así que no los saltes.

La checklist

1. Autorización en el servidor. Para cada endpoint y cada lectura de datos, ¿confirma el servidor quién pregunta y si tiene permiso? Una comprobación en el frontend no cuenta. Aprobado: cambia un ID de usuario en una petición y confirma que recibes una denegación, no los datos de otro.
2. Aislamiento por tenant y por fila. Si la app es multi-tenant, ¿puede una cuenta alcanzar físicamente los registros de otra? Aprobado: el aislamiento se impone en la capa de base de datos o de consulta, no en lógica de app que tienes que acordarte de añadir en cada endpoint.
3. Sin secretos en el cliente. ¿Hay claves de API, URLs de base de datos o tokens en el bundle del cliente o en el historial del repo? Aprobado: un escaneo del bundle y del historial de git está limpio, y todo lo alguna vez expuesto se ha rotado.
4. Validación de entrada en cada punto de entrada. ¿Rechaza cada formulario y endpoint la entrada malformada, sobredimensionada y hostil de forma limpia? Aprobado: lanzarle basura devuelve un error limpio, no un crash ni una absorción silenciosa.
5. Rutas de fallo cubiertas. Cuando una llamada externa expira, falla o devuelve vacío, ¿degrada la app con gracia? Aprobado: fuerza el fallo de cada llamada externa y confirma que la pantalla no queda en blanco con una excepción no manejada.
6. Consultas que escalan. ¿Hay llamadas a base de datos dentro de un render, o tablas enteras cargadas para contar filas? Aprobado: perfilado con volúmenes de datos realistas, con consultas N+1 y lecturas sin límite eliminadas.
7. Concurrencia e idempotencia. ¿Dos clics crean dos pedidos, o dos peticiones paralelas pasan ambas una comprobación de saldo? Aprobado: todo lo que escribe dinero o estado es idempotente y maneja peticiones duplicadas y paralelas.
8. Capa de datos propia con backups. ¿Están los datos en una base de datos gestionada que controlas, con migraciones bajo control de versiones y backups automáticos? Aprobado: has restaurado un backup al menos una vez. Un backup que nunca has restaurado es una esperanza.
9. Dependencias y licencias revisadas. ¿Carga algún paquete una vulnerabilidad conocida o una licencia que prohíba tu uso comercial? Aprobado: un escaneo de dependencias y licencias está limpio o exonerado conscientemente.
10. Existe una suite de regresión. ¿Hay tests para que el próximo cambio, escrito por IA o no, no pueda romper en silencio lo que funciona? Aprobado: una suite corre en cada cambio. Mira el desarrollo guiado por tests para entender por qué importa más, no menos, cuando un modelo escribe el código.

"Un modelo escribe el código que pediste y nada de lo que olvidaste pedir. Esta checklist es todo lo que olvidaste pedir, en el orden en que tiende a doler."

¿Qué puntos bloquean un lanzamiento?

No los diez son iguales. Ordena tus fallos en tres cubos para arreglar lo correcto primero en vez de congelarte ante la lista entera.

• Bloqueante. Todo lo que expone datos de clientes, pierde dinero o corrompe estado: puntos 1, 2, 3 y 7. No esperan. El lanzamiento espera por ellos.
• Alto. Riesgo real que aún no ha mordido: puntos 4, 5, 6 y una CVE conocida del 9. Arreglar antes de crecer hacia él.
• Limpieza. Real pero sobrevivible: validación fina en entradas de bajo riesgo, tests ausentes en código estable, el resto de 8 y 10. Vale la pena, seguro de programar.

El punto del reparto es honestidad sobre la urgencia. No disfraces un punto de limpieza como bloqueante, y no dejes que un bloqueante real se esconda en una lista larga.

¿No puedo pedirle a la IA que lo arregle?

En parte. Un modelo añade con gusto una comprobación de validación o envuelve una llamada en manejo de errores en cuanto señalas el sitio. Lo que no puede es decidir dónde mirar. No tiene modelo de tu deuda técnica ni instinto para el caso límite que un usuario real toca el día dos. Encontrar las brechas es trabajo humano. Cerrarlas es cada vez más trabajo compartido. Así exactamente lo hacemos.

¿Cuánto cuesta despejar la lista entera?

Eso depende de qué falle y cuánto dinero o datos sensibles toque el producto. Desglosamos los rangos de esfuerzo típicos y a dónde va el tiempo en cuánto cuesta dejar lista para producción una app vibe-coded. La versión corta: la auditoría que recorre esta checklist es la parte barata, y te dice el tamaño del hardening antes de comprometerte. Esta es la puerta de entrada de nuestro servicio de aseguramiento de calidad de software.