Del Prototipo en Lovable y Cursor a Producción: La Checklist de Migración

Una IDE de IA como Lovable, Cursor, Claude Code, Bolt, v0 o Replit te lleva a un producto clicable en días. Eso es progreso real, y también es la parte fácil. La distancia entre "la demo funciona" y "los usuarios reales pueden confiar en esto" es un proyecto aparte, con su propio alcance, y fingir lo contrario es justo como se tuercen los lanzamientos. Esta es la checklist que aplicamos cuando un prototipo tiene que volverse production-grade.

Nada de esto es un ataque a las herramientas. Así empezamos nosotros también. Es un mapa del trabajo que no ocurre solo, para que puedas planificarlo en vez de descubrirlo durante un incidente.

Qué significa "producción" de verdad

Una demo prueba la idea. Producción carga el peso. La diferencia no es pulido, es un conjunto de garantías que nadie ve hasta que faltan.

• Auth que aguanta. Cuentas reales, sesiones reales y una regla dura: que un usuario no pueda llegar a los datos de otro.
• Integridad de datos. Escrituras que o se completan o revierten limpio, y un store en el que confías que seguirá correcto el mes que viene.
• Uptime. Un deploy que sobrevive a un reinicio, a un pico de tráfico y a un mal release sin un rescate manual.
• Seguridad. Sin keys en el navegador, sin endpoints abiertos, sin ninguna dependencia que no hayas mirado.
• Observabilidad. Cuando algo se rompe a las 2 de la mañana, te enteras por una herramienta, no por un cliente.
• Soporte. Una forma de responder "qué pasó con mi pedido" sin adivinar.

Un prototipo puede saltarse cada uno de estos puntos y aun así demostrar perfecto. Por eso justamente la demo no es la meta.

Paso 1: Blinda la auth y el acceso a datos

Es lo primero que revisamos y lo más habitual que está mal. Las IDEs de IA son muy buenas construyendo una pantalla de login y muy malas haciendo cumplir lo que pasa después del login. El frontend esconde el botón, pero la API sigue respondiendo a cualquiera que pregunte.

Cada comprobación de acceso tiene que vivir en el servidor. Saca la autorización del cliente por completo y aplícala donde se leen y se escriben los datos. Si tu producto es multi-tenant, aísla por tenant o por fila, de modo que una cuenta no pueda consultar físicamente los registros de otra, idealmente en la capa de base de datos en vez de en lógica de app que tienes que acordarte de añadir en cada endpoint. Un check de frontend es una comodidad de UX. No es seguridad, y nunca lo fue.

Paso 2: Sé dueño de tu capa de datos

Muchas herramientas de prototipo te dan un store de datos compartido o desechable, cómodo, para que arranques. Estupendo para una demo y un error para producción. No controlas sus backups, ni sus límites, ni su vida útil, y "se reiniciaron los datos" no es una frase que quieras decirle a un usuario que paga.

Múdate a una base de datos managed real que sea tuya, Postgres en la mayoría de los casos. Pon tu esquema bajo migraciones versionadas, para que los cambios sean repetibles y revisables en vez de clicados en un dashboard. Activa backups automáticos y prueba de verdad una restauración una vez, porque un backup que nunca has restaurado es una esperanza, no un backup. Suele ser el paso menos glamuroso y el que te ahorra el peor día.

Paso 3: Secrets y entornos

Los prototipos filtran keys. La herramienta mete una API key inline para que el ejemplo corra, y acaba en el bundle de cliente o en el historial del repo, donde cualquiera la lee. El primer trabajo aquí es sacar todos los secrets del cliente y ponerlos en el servidor, detrás de tu propio backend.

Luego separa tus entornos. Dev, staging y producción deberían tener sus propias keys y sus propios datos, para que un test nunca toque a un cliente real y un error en staging no le cobre a nadie. Y rota todo lo que alguna vez quedó expuesto. Una key que estuvo en código de cliente o en un commit público está comprometida, tengas o no pruebas de que se usó. Rotarla cuesta una hora. Asumir que no pasa nada puede costar mucho más.

Paso 4: Hosting, CI/CD, rollbacks, observabilidad

El host de prototipo que venía con tu IDE de IA está hecho para mostrar, no para operar. Múdate a un setup de deployment real antes de depender de él. Eso significa una pipeline que construye y despliega en un push, una forma de volver a la última versión buena en segundos, y un paso de staging para que los cambios se vean antes de que los vean los usuarios.

Después, ponle ojos. Error tracking que te avisa cuando algo lanza una excepción, monitoreo básico de uptime y suficiente logging para responder "qué pasó" después del hecho. El objetivo es simple: deberías enterarte de un problema por tu tooling, no por un mensaje enfadado. Sin esta capa vuelas a ciegas, y la primera señal de problema es un usuario que ya se fue.

Paso 5: La decisión de mantener o reconstruir

No todo el código generado hay que tirarlo, y no todo merece la pena conservarlo. La respuesta honesta es que depende de dónde vivan los problemas. Los huecos de superficie son baratos de cerrar encima de lo que ya tienes. Los de cimiento no.

Conserva el cimiento cuando el modelo de datos es sólido, la estructura es legible y los huecos son los predecibles de arriba: auth, validación, manejo de errores, secrets. Esos son arreglos aditivos sobre una base decente. Reconstruye el núcleo cuando el modelo de datos está mal de una forma de la que depende todo lo demás, o cuando el mismo patrón roto está copiado por toda la base de código, de modo que cada arreglo hay que hacerlo cien veces. Parchear un cimiento que hay que volver a verter es la forma más cara de ahorrar dinero, y lo decimos en la primera llamada en vez de cobrarte el rodeo largo.

"El prototipo nunca fue el proyecto. Llegar a una demo es un trabajo y llegar a producción es otro, y el segundo no se abarata porque el primero fuera rápido."

Cuánto tarda y cuánto cuesta

Por experiencia, una pasada enfocada de hardening sobre un prototipo típico construido con IA lleva de una a tres semanas. Eso es un rango, no un presupuesto, y se mueve por dos razones: cuánto dinero real o datos sensibles toca el producto, y hasta dónde corrió la herramienta sin que nadie la guiara. Una herramienta interna de solo lectura cae en el extremo corto. Un producto que acepta pagos y guarda datos personales cae en el extremo largo y puede necesitar más.

Lo que no haremos es darte un número preciso antes de haber mirado. Quien cotiza una cifra fija para una base de código que no ha visto está adivinando, y la adivinanza siempre es optimista. Lo dimensionamos tras un primer vistazo, y si la respuesta honesta es "reconstruir el núcleo", lo oyes primero, no en la semana tres. La versión detallada de este trabajo es nuestro servicio de QA de software, y los modos de fallo detrás están en QA para código generado por IA.