Cómo llevar un prototipo de IA a producción

Para llevar un prototipo de IA a producción, cierras la distancia entre «funciona cuando lo pruebo» y «sigue funcionando cuando la usan otras personas». En la práctica eso significa cinco cosas: probar los flujos principales cada vez que cambias algo, controlar quién puede ver y cambiar qué, asegurarte de enterarte de los errores antes que tus usuarios, hacer copias de seguridad de los datos y comprobar que puedes restaurarlas, y mantener la app lo bastante rápida en un móvil. Nada de esto requiere reescribirlo todo: es una lista de comprobación que recorres con la misma IA que creó el prototipo.

Prototipo frente a producción: qué cambia de verdad

Un prototipo tiene un único usuario cuidadoso: tú. Sabes qué botones pulsar, escribes entradas sensatas y, si algo falla, te encoges de hombros y pides a la IA que lo arregle. En producción hay muchos usuarios descuidados, algunos curiosos y, de vez en cuando, alguno hostil. El código no tiene por qué volverse «empresarial»; tiene que manejar las situaciones que un prototipo nunca llega a encontrar.

El resto de esta guía recorre cada fila.

Paso 1: Congela el alcance y anota los flujos principales

Antes de reforzar nada, decide qué es la primera versión. Lista de tres a seis flujos que más importen, por ejemplo «registrarse, crear un proyecto, invitar a un compañero, pagar». Estos flujos serán tu guion de pruebas, los objetivos de tu monitorización y lo que compruebas después de cada cambio.

Lo que no esté en la lista se recorta o se marca claramente como beta. Es mucho más fácil dejar cuatro flujos fiables que catorce.

Paso 2: Prueba como un desconocido y luego hazlo repetible

Los creadores con IA son buenos generando código que funciona en el camino feliz. Los problemas de producción están en los caminos no previstos. Prueba cada flujo principal con:

• Entradas incorrectas: campos obligatorios vacíos, un nombre de 5.000 caracteres, un correo sin @, una cantidad negativa, una fecha pasada.
• Recargas y el botón «atrás»: recarga a mitad del pago; pulsa «atrás» después de enviar un formulario. ¿Se crea algo dos veces?
• Dos pestañas, dos usuarios: inicia sesión con dos cuentas distintas e intenta abrir las páginas del otro cambiando el ID en la URL.
• Lento y pequeño: una pantalla de tamaño móvil y una conexión limitada (las herramientas de desarrollo del navegador pueden simularla).
• Estados vacíos: una cuenta nueva sin datos. Los prototipos suelen construirse con datos de ejemplo y parecen rotos sin ellos.

Después, haz la comprobación repetible. Como mínimo, mantén una lista escrita y ejecútala antes de cada versión. Mejor aún, pide a la IA que escriba pruebas automatizadas para los flujos más importantes:

Añade pruebas automatizadas de extremo a extremo para estos flujos: registro con correo, crear un proyecto, invitar a un segundo usuario y completar un pago en el modo de prueba de Stripe. Añade también pruebas que confirmen que un usuario no puede ver ni editar el proyecto de otro cambiando la URL.

Las pruebas que demuestran que un usuario no puede hacer algo son las que más suelen faltar en los prototipos.

Paso 3: Nociones básicas de seguridad que los prototipos omiten

La mayoría de los problemas de seguridad en apps creadas con IA no son exóticos. Son comprobaciones que faltan. Revisa esta lista y consulta la lista de comprobación de seguridad para apps creadas con IA para ver el detalle:

• Autorización en el servidor. Ocultar un botón no es seguridad. Cada petición que lea o cambie datos debe comprobar, en el servidor, que el usuario que ha iniciado sesión tiene permiso. Si tu app usa una base de datos con reglas por fila, comprueba que están activadas y probadas.
• Secretos fuera del navegador. Las claves de API de pagos, correo o proveedores de IA deben estar en variables de entorno del servidor, nunca en el código del frontend. Si no tienes claro qué significa eso, lee qué son las variables de entorno y los secretos.
• Validación en el servidor. El navegador puede saltarse, así que repite en el servidor cualquier comprobación que importe.
• Inicio de sesión bien hecho. Usa una librería o servicio de autenticación bien probado en lugar de almacenar contraseñas a mano. Nuestra guía sobre cómo añadir inicio de sesión a tu app explica las opciones.
• Límites de peticiones en el inicio de sesión, el registro, el restablecimiento de contraseña y cualquier cosa que envíe correos o llame a una API de pago.
• Errores amables. Los usuarios deben ver «algo ha salido mal»; los detalles van a tus registros, no a la pantalla.
• Rota cualquier clave filtrada. Si una clave real se pegó alguna vez en un chat, un commit o una captura de pantalla, sustitúyela en el proveedor.

Un prompt que cubre mucho terreno a la vez:

Revisa esta app pensando en la seguridad de producción. Comprueba que cada ruta de API verifica que el usuario que ha iniciado sesión es dueño del registro que lee o cambia, que ninguna clave secreta llega al navegador, que las entradas se validan en el servidor y que el inicio de sesión y el restablecimiento de contraseña tienen límite de peticiones. Enumera lo que encuentres antes de cambiar nada.

Pedir primero una lista te permite ver los problemas y decidir el orden, en lugar de recibir un único cambio enorme.

Paso 4: Saber cuándo se rompe: registros y monitorización

En la vista previa ves los errores según aparecen. En producción necesitas que la app te avise. Tres capas, de la más barata a la más útil:

1. Registros del servidor. Asegúrate de que los errores se registran con suficiente contexto para reproducirlos: qué ruta, qué ID de usuario (nunca su contraseña ni su tarjeta) y qué forma tenía la entrada. Pide a la IA que añada registros estructurados si la app solo imprime en la consola.
2. Seguimiento de errores. Un servicio como Sentry u otra herramienta similar captura las excepciones del frontend y del backend, las agrupa y te envía un aviso. Para una app pequeña, los planes gratuitos de estos servicios suelen bastar; consulta los límites actuales en sus webs.
3. Comprobaciones de disponibilidad. Un servicio externo que carga tu página principal y una ruta clave de la API cada pocos minutos y te avisa si fallan. Esto detecta los problemas que impiden que la app registre nada.

Añade un hábito más: después de cada versión, abre la app en vivo y ejecuta tu lista de flujos principales sobre la URL real, no solo sobre la vista previa.

Paso 5: Copias de seguridad y una forma de volver atrás

Hay dos cosas distintas que proteger, y es fácil confundirlas.

• Código. Guarda el proyecto en control de versiones para poder deshacer cualquier cambio. Muchos creadores con IA guardan puntos de control de tus archivos; sincronizar con un repositorio Git te da una copia fuera del creador.
• Datos. Revertir el código no revierte la base de datos. Una migración mala o un botón de borrado con fallos pueden destruir filas que ningún punto de control del código devolverá.

Para los datos, configura copias de seguridad periódicas guardadas en un lugar distinto del alojamiento de la app: para una base de datos Postgres, lo habitual es un pg_dump programado a un almacenamiento separado, y muchos hosts de bases de datos gestionadas ofrecen copias automáticas o recuperación a un punto en el tiempo. Después, haz el paso que la mayoría omite: restaura una copia en una base de datos de pruebas y comprueba que los datos están ahí.

También pide a la IA que haga más seguras las acciones destructivas: un paso de confirmación para los borrados y un «borrado lógico» (marcar las filas como eliminadas en lugar de quitarlas) para todo lo que los usuarios puedan querer recuperar.

Paso 6: Un rendimiento que aguante en el móvil

Los prototipos parecen rápidos porque eres el único usuario y el conjunto de datos es minúsculo. Antes del lanzamiento:

• Carga datos de tamaño real. Pide a la IA que genere unos miles de filas y mira qué páginas se ralentizan. Las listas suelen necesitar paginación, y la base de datos suele necesitar índices en las columnas por las que filtras y ordenas.
• Reduce las imágenes. Las imágenes sobredimensionadas son la causa más habitual de que una página cargue despacio. Pide imágenes redimensionadas y comprimidas, y carga diferida por debajo del pliegue.
• Mide. Ejecuta Lighthouse en las herramientas de desarrollo de Chrome sobre la URL en vivo, en modo móvil. Las Core Web Vitals de Google son un objetivo razonable: Largest Contentful Paint en menos de 2,5 segundos, Interaction to Next Paint de 200 ms o menos, y Cumulative Layout Shift de 0,1 o menos.
• Atención a los retrasos de «despertar». Un alojamiento que se duerme cuando está inactivo ahorra dinero, pero hace más lenta la primera visita tras un periodo de calma. Suele ser un buen compromiso para una app nueva; sé consciente de que ocurre.

La página de proyectos va lenta con 5.000 filas. Añade paginación en el servidor (25 por página), añade índices en la base de datos para las columnas por las que filtramos y ordenamos, y muestra un estado de carga mientras se carga la página siguiente.

Paso 7: Lo básico de operaciones

Unas pocas cosas pequeñas separan una app de afición de una en la que la gente confía:

• Un dominio propio con HTTPS. Consulta cómo conectar un dominio personalizado.
• Correo transaccional desde un dominio verificado para las confirmaciones de registro y los restablecimientos de contraseña, explicado en cómo enviar correos desde tu app.
• Política de privacidad y condiciones que describan lo que recoges realmente. No copies declaraciones de cumplimiento que no hayas conseguido.
• Una vía de soporte, aunque sea una dirección de correo que se revise.
• Claves de prueba y de producción separadas para pagos y correo, y una nota clara de qué entorno usa cada una.

Paso 8: Una entrega ordenada

Tarde o temprano, otra persona trabajará en la app: un freelance, un nuevo cofundador o tú mismo dentro de seis meses. Facilítalo:

• Un README que explique cómo ejecutarla, qué variables de entorno necesita (solo los nombres, nunca los valores) y cómo desplegarla.
• La lista de flujos principales y las pruebas automatizadas.
• Una nota breve de arquitectura: frontend, backend, base de datos, servicios de terceros y dónde está alojado cada uno.
• Lista de accesos: quién tiene acceso de administrador al dominio, al alojamiento, a la base de datos y a las cuentas de pagos y de correo. Pon estas cuentas bajo un correo corporativo, no personal.
• El código en Git, idealmente sincronizado con un repositorio que tú controles. Si quizá cambies de alojamiento más adelante, lee cómo exportar y alojar por tu cuenta una app creada con IA.

La IA puede redactar gran parte de esto por ti:

Escribe un README para este proyecto pensando en un desarrollador que nunca lo ha visto: qué hace la app, la pila tecnológica, cómo ejecutarla en local, cada variable de entorno que lee (solo nombres y finalidad), cómo está organizado el esquema de la base de datos y cómo desplegarla.

Lista de comprobación de preparación para producción

• Flujos principales escritos y probados, incluido «no se puede acceder a los datos de otra persona»
• Autorización y validación en el servidor en cada ruta de datos
• Sin claves secretas en el código del frontend; claves filtradas rotadas
• Límites de peticiones en la autenticación y en cualquier cosa que cueste dinero
• Seguimiento de errores y alertas de disponibilidad apuntando a una bandeja de entrada que revises
• Copias de seguridad de la base de datos fuera del alojamiento de la app, con una restauración de prueba correcta
• Paginación e índices comprobados con datos realistas
• Dominio propio, dominio de envío verificado y política de privacidad
• README y lista de accesos para quien venga después

Hacerlo con Mythex

Si creaste el prototipo en Mythex, la mayoría de estos pasos son prompts dentro del mismo proyecto. Escribe /test y Mythex recorre la vista previa en vivo como un usuario y te informa de los flujos rotos; consulta Pruebas de la app. Las claves se introducen en los secretos del proyecto y no en el chat, cada turno exitoso del agente guarda un punto de control de tus archivos al que puedes volver, y publicar te da una URL en vivo, con el alojamiento y la base de datos facturados desde el mismo saldo de créditos (límites de alojamiento explica cómo se duermen y despiertan apps y bases de datos). Los puntos de control cubren archivos, no filas de la base de datos, así que sigue planificando las copias de seguridad de tus datos. En el plan Pro puedes conectar un dominio propio y exportar el código o sincronizarlo con tu propio repositorio de GitHub para la entrega.

Preguntas