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 lo usan otras personas». En la práctica son cinco cosas: probar los flujos principales cada vez que cambias algo, controlar quién puede ver y modificar cada cosa, asegurarte de enterarte de los errores antes de que te lo digan tus usuarios, hacer copias de seguridad de los datos y demostrar que puedes restaurarlos, y mantener la app lo bastante rápida en el móvil. Nada de esto exige reescribirlo todo: es una lista de comprobación que se trabaja 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 razonables y, si algo se rompe, te encoges de hombros y pides a la IA que lo arregle. La producción tiene muchos usuarios descuidados, algunos curiosos y, de vez en cuando, uno hostil. El código no necesita volverse «empresarial»; necesita gestionar las situaciones que un prototipo nunca llega a encontrar.

El resto de la guía recorre cada fila.

Paso 1: Congela el alcance y anota los flujos principales

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

Todo lo que no esté en la lista se recorta o se etiqueta claramente como beta. Es mucho más fácil hacer fiables cuatro flujos que catorce.

Paso 2: Prueba como un desconocido y después hazlo repetible

Los creadores con IA son buenos generando código que funciona en el camino feliz. Los problemas de producción viven 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 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 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 se construyen a menudo con datos de muestra y parecen rotos sin ellos.

Después, haz que la comprobación sea 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 que más importan:

Añade pruebas automatizadas de extremo a extremo para estos flujos: registro con correo, crear un proyecto, invitar a un segundo usuario y completar el pago en el modo de pruebas 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: Seguridad básica 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. Repasa esta lista, y consulta la lista completa de seguridad para apps creadas con IA:

• Autorización en el servidor. Ocultar un botón no es seguridad. Cada petición que lea o modifique datos debe comprobar, en el servidor, que el usuario con sesión iniciada 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 front-end. Si no tienes claro qué significa, 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 probado en lugar de almacenar contraseñas por tu cuenta. 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 secreto filtrado. Si alguna vez se pegó una clave real en un chat, un commit o una captura de pantalla, sustitúyela en el proveedor.

Un prompt que cubre bastante terreno de una vez:

Revisa esta app para producción desde el punto de vista de la seguridad. Comprueba que cada ruta de la API verifica que el usuario conectado es dueño del registro que lee o modifica, 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. Haz una lista de 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 falla: registros y monitorización

En la vista previa ves los errores según ocurren. 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 contexto suficiente 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 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 front-end y del back-end, 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 de inicio y una ruta clave de la API cada pocos minutos y te avisa si fallan. 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 la lista de flujos principales en la URL real, no solo en 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 un control de versiones para poder deshacer cualquier cambio. Muchos creadores con IA guardan puntos de restauración de tus archivos; sincronizar con un repositorio Git te da una copia fuera del propio creador.
• Datos. Volver atrás en el código no devuelve la base de datos a su estado anterior. Una migración mala o un botón de borrado con fallos pueden destruir filas que ningún punto de restauración del código recuperará.

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

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

Paso 6: Rendimiento que aguanta en el móvil

Los prototipos parecen rápidos porque tú 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 demasiado grandes son la causa más habitual de que una página cargue lenta. 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 sensato: 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.
• Vigila los retrasos de «despertar». Un alojamiento que se duerme cuando no hay actividad ahorra dinero, pero hace que la primera visita tras un periodo de calma sea más lenta. Para una app nueva suele ser un buen equilibrio; solo debes saber 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 propio.
• Correo transaccional desde un dominio verificado para confirmaciones de registro y restablecimientos de contraseña, explicado en cómo enviar correos desde tu app.
• Política de privacidad y condiciones que describan lo que recoges de verdad. No copies afirmaciones de cumplimiento que no hayas conseguido.
• Una vía de soporte: aunque sea una dirección de correo que alguien 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: Un traspaso ordenado

Tarde o temprano alguien más trabajará en la app: un freelance, un nuevo socio o tú dentro de seis meses. Hazlo fácil:

• Un README que explique cómo ejecutarla, qué variables de entorno necesita (solo nombres, nunca valores) y cómo desplegarla.
• La lista de flujos principales y las pruebas automatizadas.
• Una nota breve de arquitectura: front-end, back-end, 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 pago y de correo. Pon estas cuentas bajo un correo corporativo, no personal.
• El código en Git, idealmente sincronizado con un repositorio que sea tuyo. Si puedes cambiar de alojamiento más adelante, lee cómo exportar y alojar por tu cuenta una app creada con IA.

La IA puede redactar buena parte de esto por ti:

Escribe un README para este proyecto pensado para 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 para producción

• Flujos principales escritos y probados, incluido «no se puede acceder a los datos de otro»
• Autorización y validación en el servidor en cada ruta de datos
• Sin claves secretas en el código del front-end; las filtradas, rotadas
• Límites de peticiones en la autenticación y en todo lo que cueste dinero
• Seguimiento de errores y alertas de disponibilidad enviadas a una bandeja 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 recorrerá la vista previa en directo como un usuario y te dirá qué flujos fallan; consulta App Testing. Las claves se introducen en los secretos del proyecto y no en el chat; cada turno del agente que termina bien guarda un punto de restauración de tus archivos al que puedes volver; y publicar te da una URL en vivo con alojamiento, cobrado desde el mismo saldo de créditos que la base de datos (los límites de alojamiento explican cómo se duermen y despiertan las apps y las bases de datos). Los puntos de restauración cubren archivos, no filas de la base de datos, así que sigue planificando tus copias de seguridad de datos. En el plan Pro puedes conectar un dominio propio y exportar el código o sincronizarlo con tu propio repositorio de GitHub para el traspaso.

Preguntas