Lista de verificación de preparación para producción para apps creadas con IA: una hoja de puntuación

Qué significa "listo para producción" para apps construidas por IA

Los prototipos creados con IA son excelentes para mostrar algo rápidamente, pero a menudo fallan la primera vez que llegan usuarios reales. La razón habitual es sencilla: los prototipos se hacen para lucir bien, no para sobrevivir entradas desordenadas, días de red malos, tráfico inesperado o atacantes curiosos.

"Listo para producción" significa que la app puede ejecutarse de forma segura y predecible para personas reales, con datos reales y en condiciones reales. No significa perfecta ni completa en funciones. Significa que puedes lanzar sin contener la respiración cada vez que alguien se registra, paga o recarga la página.

Esta hoja de puntuación se centra en cuatro no negociables:

• Seguridad: los secretos y los datos de usuarios permanecen protegidos.
• Observabilidad: puedes ver qué falló y por qué.
• Integridad de datos: tu base de datos permanece correcta incluso cuando los usuarios hacen cosas raras.
• Desplegabilidad: puedes enviar actualizaciones sin caos.

Lo que esto no cubre: si la idea es buena, si la UX tiene sentido o si la app es rápida bajo carga alta. Tampoco reemplaza una revisión completa de seguridad para industrias reguladas. Trátalo como un mínimo práctico para llevar una base de código generada por IA de "demo" a "segura para ejecutar".

Cuando puntúes cada ítem, sé estricto:

• Pass: puedes demostrar que está en marcha.
• Risky: funciona en el camino feliz, pero hay lagunas que aparecerán en producción.
• Fail: falta o es inseguro. No lances hasta que esté arreglado.

Si heredaste un prototipo desordenado de herramientas como Bolt, v0, Cursor, Lovable o Replit, esto también es una buena forma de empezar: identifica primero lo que es inseguro o poco fiable, luego arregla los problemas de mayor riesgo antes de añadir más funciones.

Cómo usar esta hoja de puntuación (paso a paso)

Empieza escogiendo un entorno objetivo para juzgar. Si tienes staging que refleja producción, úsalo. Si no, usa producción, pero ejecuta las comprobaciones en un momento tranquilo y evita cambios arriesgados.

Establece una línea base para que tus respuestas coincidan con la realidad. Escribe cómo es lo "normal": cuántos usuarios esperas en la semana uno, qué datos importan más (pagos, perfiles, contenido) y qué picos podrían ocurrir (un post de lanzamiento, una campaña de email). Una app de chat para 20 testers tiene necesidades diferentes a un flujo de pago que maneja dinero real.

Realiza las comprobaciones en este orden:

1. Elige el entorno y congela la versión que estás evaluando (commit, build o tag de release).
2. Haz seguridad primero, luego observabilidad, luego integridad de datos y por último desplegabilidad.
3. Para cada comprobación, captura evidencia: un valor de configuración, una línea de log, una captura de pantalla de un ajuste o la salida exacta de un comando.
4. Puntúa cada ítem como Pass, Risky o Fail según lo que puedas probar, no según lo que asumas.
5. Para y arregla cualquier cosa marcada como Fail antes de puntuar los ítems "agradables de tener".

La evidencia importa porque las apps creadas con IA a menudo parecen bien hasta que una configuración falta rompe el login o expone un secreto. Si no puedes mostrar la prueba en 30 segundos, trátalo como Risky.

Un ejemplo práctico: vas a lanzar un prototipo hecho en Cursor y desplegado rápido. Confirmas que los secretos están almacenados solo en variables de entorno (Pass), pero no hay logs de solicitudes ni seguimiento de errores (Fail). Eso significa que envías a producción a ciegas cuando los usuarios informan "no funciona".

No negociables de seguridad (maneras rápidas de verificar)

La seguridad es la parte que no puedes parchear después. Trátalas como bloqueos de lanzamiento: los secretos no están expuestos, la autenticación se maneja de forma segura, los permisos son mínimos, las entradas están validadas y las dependencias no están llenas de agujeros conocidos.

Comprobaciones rápidas que la mayoría de equipos puede hacer en menos de una hora:

• Escanea el repo buscando secretos: busca API_KEY, SECRET, TOKEN, PRIVATE_KEY y valores largos que parezcan aleatorios. Si encuentras uno, asume que está comprometido y gíralo.
• Confirma que las contraseñas no están almacenadas directamente: el código debe hashear contraseñas (no "encriptarlas") y nunca registrarlas en logs. En producción, las cookies de sesión deben usar configuraciones seguras.
• Prueba endpoints de escritura con entradas malas: prueba comillas, cadenas largas y tipos inesperados en formularios de crear/actualizar. Si la app se cae o almacena datos raros, necesitas validación de entrada y consultas más seguras.
• Revisa el principio de mínimo privilegio: no uses un usuario administrador de la base de datos para peticiones normales y limita los tokens de API a lo que la app necesita.
• Ejecuta un escaneo de dependencias: usa la herramienta de auditoría estándar de tu gestor de paquetes y anota problemas altos o críticos, especialmente alrededor de auth, templating y controladores de base de datos.

Un fallo común: un prototipo usa una sola variable de entorno como DATABASE_URL, luego alguien la copia en un archivo de configuración "para que funcione" y lo comitea. Ahora cualquiera con acceso al repo tiene control total de la base de datos. La solución no es solo borrar el archivo. Rotas credenciales, vuelves a mover secretos a variables de entorno del servidor y reduces permisos para que credenciales filtradas no puedan eliminar tablas.

Comprobaciones rápidas de auth, secretos e inyección

Los problemas de autenticación son una de las principales razones por las que una app creada con IA se ve bien en demo pero falla en uso real.

Empieza con una prueba de extremo a extremo: inicia sesión, recarga la página y luego reinicia completamente la app (o redeploya) y prueba otra vez. Si la app te desconecta al recargar, pierde el estado de sesión tras un reinicio o se queda en un bucle de redirección, probablemente tengas problemas de almacenamiento de tokens, cookies o callbacks.

Luego revisa el control de acceso. No basta con que la UI oculte botones. Confirma que el servidor también bloquea acciones. Una prueba rápida es abrir un registro que debería ser privado (el proyecto de otro usuario, una factura, una página de admin) y ver si puedes verlo o editarlo cambiando un ID en la URL o en la petición.

Los secretos son otra victoria rápida. Si ves claves API, URLs de base de datos o secretos de proveedores de auth dentro del repo, archivos de config o código del cliente, trátalo como una emergencia. Deben vivir en variables de entorno del servidor y el cliente solo debe recibir claves públicas pensadas para el navegador.

Barrido de cinco minutos:

• El login sigue funcionando tras recargar y después de un reinicio completo (sin sesiones rotas).
• Usuarios no administradores no pueden acceder a rutas de admin, aunque escriban la URL.
• No hay modo debug, usuarios de prueba ni flags de bypass "temporales" activados.
• Los secretos no están en código, logs ni bundles front-end (solo variables de entorno).
• No hay SQL crudo construido con interpolación de cadenas. Las consultas están parametrizadas.

Para el riesgo de inyección, busca consultas crudas y cláusulas WHERE construidas con cadenas. Si no estás seguro, trátalo como Risky hasta que puedas señalar consultas parametrizadas y validación de entradas.

No negociables de observabilidad (para depurar en producción)

Cuando algo falla en producción, necesitas respuestas rápidas: qué falló, a quién afectó y con qué frecuencia. Para apps creadas con IA, esto importa aún más porque el código puede verse bien en demo pero fallar bajo tráfico real o datos reales.

Lo básico es simple: puedes ver errores (con detalles), ver latencia (qué es lento) y ver eventos clave (qué hacen los usuarios y los jobs en background).

Maneras rápidas de verificar (sin ser un experto)

Ejecuta estas comprobaciones en staging o justo después de un deploy:

• Provoca un error conocido y confirma que se captura con traza de pila. Ejemplo: llama a un endpoint con entrada inválida. Deberías ver un informe de error claro que incluya dónde ocurrió.
• Revisa logs buscando IDs de petición y contexto básico. Elige una petición y asegúrate de poder seguirla de principio a fin usando un request ID. Los logs también deberían incluir la ruta o el nombre del job, más contexto de usuario o sesión.
• Confirma que existen tres métricas básicas: uptime, latencia y tasa de errores. No necesitas dashboards sofisticados. Necesitas poder contestar: "¿Estamos arriba?", "¿Estamos lentos?", "¿Estamos fallando?"
• Verifica que hay alertas para caídas y jobs fallidos. Provoca un job que falle (o rómpelo temporalmente) y confirma que alguien es notificado rápido.
• Prueba un recorrido real de usuario y confirma que aparecen eventos clave. Por ejemplo: registro, login, completar la acción principal. Debes poder ver dónde los usuarios abandonan.

Un ejemplo concreto: los usuarios informan "los pagos a veces no funcionan". Sin IDs de petición y seguimiento de errores, estás adivinando. Con ellos, puedes encontrar las peticiones fallidas, ver el mensaje de error y saber si es un timeout, una clave API mala o un bug lógico.

No negociables de integridad de datos (protege tu base de datos)

Si tus datos están equivocados, todo lo construido encima falla: facturación, informes, permisos y la confianza del usuario. Las apps hechas con IA a menudo parecen bien en demos pero fallan en uso real porque la base de datos carece de guardarraíles básicos.

El objetivo: los registros permanecen correctos, consistentes entre tablas y recuperables tras errores.

Comprobaciones rápidas de integridad que puedes verificar hoy

• Existen constraints donde importan: confirma que las tablas clave tienen restricciones únicas (emails, IDs externos) y claves foráneas (órdenes pertenecen a un usuario). Un signo rápido de problema son filas duplicadas que nunca deberían duplicarse.
• Las migraciones están rastreadas y son repetibles: puedes reconstruir la base de datos desde cero usando solo migraciones. Si alguien dice "ejecuta este SQL ad-hoc en prod", es Risky.
• Las copias de seguridad son reales y la restauración funciona: una copia de seguridad que nunca se ha restaurado es una conjetura. Haz una restauración de prueba en un entorno descartable y confirma que la app arranca y lee los datos esperados.
• Las escrituras son seguras ante reintentos: si un cliente reintenta una petición (común en redes lentas), la app no debe crear duplicados. Busca endpoints que creen registros sin una clave de idempotencia estable o una restricción única.
• Las eliminaciones son seguras: no borres permanentemente registros necesarios para auditoría, facturación o soporte a menos que tengas un plan de retención claro.

Ejemplo pequeño

Un endpoint "Crear suscripción" inserta una fila nueva cada vez que se llama. En pruebas está bien. En producción, un proveedor de pagos reintenta un webhook y obtienes dos suscripciones activas para un usuario. Una solución simple es una restricción única en (user_id, provider_subscription_id) más lógica de update-on-conflict.

No negociables de desplegabilidad (¿puedes lanzar con fiabilidad?)

Si no puedes desplegar la misma app dos veces y obtener el mismo resultado, no está lista para producción. Las apps creadas con IA a menudo solo funcionan en la máquina del creador porque la compilación es frágil, la configuración está oculta y los pasos de despliegue viven en la cabeza de alguien.

Una app desplegable tiene builds predecibles, configuración segura y despliegues repetibles. Eso significa un paso de build limpio que siempre funciona, un paso de inicio claro que se ejecuta en el entorno objetivo y cero secretos incrustados en el repo o archivos empaquetados.

Una comprobación de cordura rápida es un inicio en frío desde cero (máquina nueva, contenedor nuevo o un checkout limpio). Deberías poder:

• Un comando para instalar y compilar
• Un comando para iniciar la app
• El mismo resultado cada vez

Si ese flujo simple falla, el siguiente despliegue también fallará.

Comprobaciones rápidas de verificación

La configuración debe ser explícita. Debe haber un documento corto o README que liste las variables de entorno necesarias, cuáles son opcionales y valores por defecto seguros para desarrollo local. Si no puedes responder "¿qué variables necesita esto en producción?" en 2 minutos, el despliegue se convertirá en conjeturas.

Los fallos de arranque deben ser visibles. Una migración fallida, una variable de entorno faltante o un servidor caído debe aparecer claramente en logs, y la app debería exponer una comprobación de salud básica para decir si está lista o atascada.

Finalmente, verifica que la app funciona tras el despliegue: carga la página principal, confirma que los assets estáticos se cargan (CSS, JS, imágenes) y llama a unos endpoints API críticos. Un fallo común en apps de IA es una URL hardcodeada a localhost o una base path faltante que solo aparece tras el despliegue.

Comprobaciones adicionales: rendimiento, fiabilidad y cumplimiento básico

Una vez los ítems centrales estén sólidos, estos complementos deciden si la app da confianza desde el día uno.

Conceptos básicos de rendimiento (lo suficientemente rápido para usuarios reales)

Empieza desde la vista del usuario: navega por las pantallas más lentas con una conexión normal. Si regularmente esperas más de un par de segundos, los usuarios se irán.

Cronometra tres cosas: la carga de la primera página, la acción más lenta (a menudo búsqueda o checkout) y un inicio en frío tras inactividad. Si algo llega a timeouts o retrasos aleatorios, busca respuestas API enormes, paginación faltante y consultas que escanean tablas completas.

Conceptos básicos de fiabilidad (falla de forma segura y luego se recupera)

Muchas apps creadas con IA fallan de forma brusca y confusa: una dependencia inestable tumba todo, o un usuario puede spamear peticiones y derribar el servidor. Apunta a fallos gráciles: errores claros, reintentos seguros y sin corrupción de datos.

Un conjunto pequeño de comprobaciones:

• Provoca un fallo a propósito (desactiva una dependencia o usa entrada mala) y confirma que la app muestra un mensaje claro y registra el error.
• Confirma que los reintentos están limitados (sin loops infinitos) y que hay timeouts en llamadas externas.
• Añade rate limiting básico en login y endpoints clave para que un bot no te inunde.
• Verifica que los jobs en background son idempotentes (ejecutarlos dos veces no duplica cargos ni registros).
• Ten un plan de rollback simple si una release rompe algo.

El cumplimiento es "según se necesite", pero no lo ignores si manejas datos personales. Debe saberse: qué PII almacenamos, dónde, por cuánto tiempo y quién puede verlo. Si necesitas trazabilidad, confirma que eventos clave (logins, cambios de permisos, pagos) se registran sin almacenar secretos.

Hoja de puntuación imprimible: comprobaciones rápidas y puntuación

Usa esto como una lista rápida de preparación para producción. El objetivo no es un número perfecto. Es un sí/no claro sobre qué bloquea el lanzamiento.

Puntuación (0 a 2 por área)

• 0 = Fail: falta, es desconocido o claramente inseguro.
• 1 = Risky: parcialmente en su lugar, pero quedan lagunas.
• 2 = Pass: en su sitio, repetible y respaldado por evidencia.

Marca un área como Pass solo si obtuvo 2.

Comprobaciones rápidas pass/fail (una línea cada una)

• Seguridad: los secretos no están en el repo, las entradas están validadas y se bloquean inyecciones comunes.
• Observabilidad: los errores se capturan con contexto, las acciones clave son rastreables y puedes encontrar fallos rápido.
• Integridad de datos: existen migraciones, se usan constraints donde conviene y las acciones destructivas están protegidas.
• Desplegabilidad: un comando o pipeline despliega, la configuración depende del entorno y hay posibilidad de rollback.

Registra evidencia a medida que avanzas. Para cada comprobación escribe (1) dónde la verificaste, (2) qué viste y (3) el título de una captura o snippet que puedas encontrar después. Ejemplo: "Secrets: revisado uso de .env y escaneo de repo, encontrado API key en config.ts, mover a env var."

Convierte la hoja de puntuación en una lista de arreglos de 1 semana ordenando el trabajo así: primero todo lo que puntuó 0, luego lo que bloquea despliegues, luego lo que impide depuración.

Trampas comunes en apps creadas con IA

La parte más difícil es que a menudo parecen terminadas antes de ser seguras, estables o fáciles de desplegar. Un prototipo puede sentirse hecho porque la UI carga y el demo del camino feliz funciona. La producción falla en los detalles aburridos: configuraciones, casos límite y cómo se comporta la app con usuarios reales.

Trampas que aparecen repetidamente:

• "Funciona en mi máquina" equivale a desplegable. Comprobación rápida: ¿puede un entorno limpio (nuevo laptop o CI) ejecutarlo usando solo un README y variables de entorno, sin pasos manuales?
• Ajustes de depuración publicados en internet. Comprobación rápida: busca debug=true, CORS permisivo como * y cuentas admin de marcador en config.
• Cambios de esquema sin migraciones. Comprobación rápida: ¿hay una carpeta de migraciones y un proceso estándar de migración?
• Sin monitorización hasta que los usuarios se quejan. Comprobación rápida: ¿puedes responder "qué falló?" solo con logs, sin reproducir localmente?
• Arreglar síntomas en lugar de la estructura. Comprobación rápida: ¿ves parches repetidos y lógica duplicada en varios archivos?

Un escenario rápido: un fundador hace una demo impecable de una app construida en Lovable. El día del lanzamiento, los registros fallan porque no se configuró la URL de callback de auth en producción, y la app registra cuerpos completos de petición (incluyendo tokens) en consola. La solución no es solo "cambiar la URL" o "ocultar logs". Es endurecer manejo de config, almacenamiento de secretos y paridad entre entornos para que la app se comporte igual en dev, staging y prod.

Ejemplo: puntuar un prototipo real antes del lanzamiento

Un fundador trae una app de marketplace construida con Bolt y terminada en Replit. El demo se ve genial: los usuarios pueden registrarse, crear anuncios y pagar. Quieren lanzar a clientes reales, así que corren una hoja de puntuación rápida antes de gastar en anuncios.

Lo que falla primero casi nunca es la UI. Es lo oculto: casos límite de login, secretos en el repo, escrituras inseguras en la base de datos y un despliegue que solo funciona en la máquina del creador.

Así puede quedar la hoja de puntuación tras 30 minutos:

• Seguridad: 0/2 (Fail) - Se cometió un archivo .env con API keys y una búsqueda construye SQL con concatenación de cadenas.
• Observabilidad: 0/2 (Fail) - Los errores se ven en la consola del navegador, pero el servidor no tiene logs estructurados ni request IDs.
• Integridad de datos: 1/2 (Risky) - Borrar un usuario deja anuncios huérfanos; no hay claves foráneas en relaciones clave.
• Desplegabilidad: 1/2 (Risky) - Se puede desplegar, pero los pasos de build son manuales y las variables de entorno no están documentadas.

No arreglan todo a la vez. Arreglan primero lo que puede filtrar datos o romper pagos:

• Eliminar secretos expuestos, girar claves y añadir un escáner de secretos
• Reemplazar consultas inseguras por consultas parametrizadas y validar entradas
• Reforzar cookies de auth, añadir límites básicos de tasa y ajustar permisos
• Añadir logs mínimos (errores más eventos clave) y una comprobación de salud simple

Tras un par de días, la app se lanza con menos sorpresas: los registros de altas dejan de disparar tasas de error, los pagos fallidos son rastreables y los despliegues son repetibles.

Próximos pasos: arregla las lagunas antes de lanzar

Trata los resultados de la hoja de puntuación como un plan, no un veredicto. Ordena cada falla en tres cubos: riesgos que pueden exponer usuarios (seguridad), riesgos que pueden corromper datos (integridad) y riesgos que pueden romper releases (desplegabilidad). Arregla esos primero, aunque retrase funciones agradables.

Una forma simple de convertir fallos en acción es escribir cada uno como: "Problema -> impacto en el usuario -> arreglo -> responsable -> fecha de envío." Si no puedes explicar el impacto en una frase, probablemente no sea prioridad alta todavía.

Orden sugerido de prioridades:

• Parar el sangrado: secretos expuestos, auth rota, riesgos de inyección, subidas de archivos inseguras
• Seguridad de datos: constraints faltantes, migraciones débiles, sin backups, eliminaciones riesgosas
• Operabilidad: sin logs, sin seguimiento de errores, sin comprobaciones de salud
• Seguridad en releases: sin staging, sin plan de rollback, builds dependientes de config local
• Limpieza: refactors, tests, estilo de código

Sabe cuándo dejar de parchear. Si cada arreglo crea dos bugs nuevos, la arquitectura está enmarañada o la app no tiene límites claros (UI, API, datos), a menudo es más barato un refactor o reconstrucción que semanas de juego del gato y el ratón.

Si prefieres no depurar esto solo, FixMyMess (fixmymess.ai) se especializa en tomar prototipos generados por IA rotos y hacerlos seguros para producción, incluyendo diagnóstico de la base de código, reparación de auth y lógica, endurecimiento de seguridad, refactorización y preparación para despliegue. Una auditoría rápida también puede darte una lista clara Pass/Risky/Fail para saber qué arreglar primero.