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

Los builders asistidos por IA como Lovable, Cursor, Claude Code, Bolt, v0 y Replit pueden acortar el camino a un producto clicable. Es progreso real, pero "la demo funciona" no demuestra que "los usuarios puedan confiar en esto." La preparación para producción es un cuerpo separado de evidencia cuyo alcance depende de arquitectura, datos, amenazas, regulación y daño potencial. Esta es nuestra primera revisión al llevar un prototipo a producción.

Nada de esto es un ataque a las herramientas, y su nombre no decide si un sistema puede operar en producción. Lovable y Replit documentan despliegues productivos; Lovable también documenta sincronización con GitHub, revisión de seguridad y almacenamiento backend de secretos. Verifica plan y arquitectura exactos. La checklist mapea controles que requieren evidencia tanto si el código se generó como si se escribió a mano.

Construiste un prototipo con una IDE de IA?

Reserva una Revisión de Production-Readiness

¿Qué significa "producción" de verdad?

Una demo puede aportar evidencia de que la idea y la interacción funcionan. La preparación para producción consiste en definir objetivos de servicio y riesgo y reunir evidencia de que el sistema los cumple. No es una garantía universal ni una certificación única.

Autorización. Identidades autenticadas y permisos en un punto confiable de aplicación para cada acción y objeto protegido.
Integridad y recuperación. Transacciones donde hagan falta, cambios versionados, objetivos de recuperación, backups protegidos y restauración más reconciliación probadas.
Fiabilidad. Capacidad, gestión de fallos, dependencias, seguridad del despliegue y recuperación alineadas con objetivos explícitos.
Seguridad. Credenciales confidenciales fuera de clientes no confiables, límites validados, componentes mantenidos y controles derivados de amenazas.
Observabilidad. Logs, métricas, trazas, alertas y retención adecuados para los fallos e investigaciones del equipo.
Soporte. Propiedad, runbooks, escalado y contexto de auditoría suficiente para explicar lo ocurrido sin adivinar.

Un prototipo puede mostrar comportamiento útil sin aportar evidencia para todas estas áreas. Por eso la demo es una entrada para decidir preparación, no la meta.

Paso 1: ¿cómo blindas la auth y el acceso a datos?

Una pantalla de login demuestra autenticación, no autorización. Para cada acción y objeto protegido, prueba que otro usuario, tenant, rol o identificador recibe una denegación. Ocultar en cliente puede mejorar la UX, pero OWASP dice que no debe decidir el acceso.

Aplica autorización en una capa de servicio confiable que controle la acción o los datos. Puede ser una API, gateway, función serverless o política de base de datos, no solo un servidor tradicional. Centraliza el aislamiento por tenant y fila y prueba acceso cruzado. Row-level security puede ayudar, pero necesita políticas correctas y verificación.

Paso 2: ¿puedes operar y recuperar la capa de datos?

No migres un servicio de datos solo porque se conectó mediante una herramienta de prototipo. Lovable documenta backends gestionados y Lovable Cloud; Replit recomienda servicios persistentes porque el sistema de archivos publicado no lo es. Conserva un servicio si propiedad, acceso, capacidad, retención, exportación, borrado, backup y recuperación cumplen tus requisitos.

Versiona cambios de esquema cuando la plataforma admita migraciones y define objetivos de recuperación para bases, objetos, identidad, secretos e infraestructura. Activa backups o controles point-in-time y prueba restauración y reconciliación. Supabase documenta que el backup de base no incluye objetos de Storage ni toda configuración, así que prueba el alcance completo.

Paso 3: Secrets y entornos

Clasifica credenciales antes de moverlas. Identificadores públicos y claves publicables pueden estar diseñados para clientes no confiables; claves API privilegiadas, credenciales, material de firma y bearer tokens son confidenciales. Guarda valores confidenciales en el almacén backend o gestor aprobado, aplica mínimo privilegio y mantenlos fuera de bundles, logs, builds, prompts e historial.

Separa desarrollo, test o staging y producción según riesgo, con credenciales y datos aislados. Los entornos Test y Live de Lovable no están disponibles para nuevos proyectos Cloud, así que confirma la función o establece separación mediante backend y entrega. Trata credenciales confidenciales expuestas como comprometidas, revócalas o rótalas y revisa tokens, logs y cachés posteriores. El esfuerzo varía.

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

Un host integrado no es automáticamente inadecuado para producción. Lovable documenta publicación permanente, dominios, acceso, seguridad y despliegue externo por GitHub; Replit documenta Autoscale y Reserved VM. Verifica capacidad, regiones, almacenamiento persistente, red, identidad de despliegue, entornos, dominio, backups, rollback o forward recovery, soporte, portabilidad y objetivos. Migra solo si la plataforma no cumple.

Automatiza build, test, aprobación y despliegue según riesgo. Prueba un release fallido y la recuperación elegida, sin prometer un tiempo de recuperación que no hayas medido. Añade logs, métricas, trazas, error tracking, checks, alertas y runbooks. Protege también observabilidad, pues los logs pueden contener valores sensibles.

Paso 5: ¿cuándo conservas el código generado y cuándo reconstruyes?

No todo el código generado hay que tirarlo, y no todo merece la pena conservarlo. Evalúa dónde están los problemas: algunas brechas se corrigen de forma local, mientras que otras cruzan los límites del modelo de datos, la seguridad o el despliegue y requieren una sustitución más amplia.

Conserva el cimiento cuando modelo de datos, límites, dependencias, mantenibilidad, testabilidad y despliegue puedan cumplir los objetivos con cambios proporcionales. Reconstruye o sustituye una capa cuando corregirla genere más riesgo de migración, remediación duplicada o coste operativo que un reemplazo controlado. Decide con evidencia de repositorio y arquitectura, mapa de dependencias, plan de migración, pruebas de aceptación, rollback y coste de ciclo de vida.

"Un prototipo es evidencia valiosa, no prueba de production-readiness. Conserva lo que cumple los objetivos, sustituye lo que no y decide por arquitectura y tests, no por el nombre de la herramienta."

¿Cuánto tarda y cuánto cuesta?

No existe duración ni precio universal defendible. El alcance depende de arquitectura, calidad de código y dependencias, migración, tests, sensibilidad, pagos, integraciones, regulación, exposición y objetivos. Una herramienta interna y un producto público con pagos o datos personales requieren evidencia y remedios distintos.

Revisamos repositorio, arquitectura desplegada, flujos, configuración y evidencia antes de estimar. El primer resultado debe indicar si es menos arriesgado endurecer, sustituir una parte o reconstruir el núcleo, con supuestos y aceptación visibles. La versión detallada es nuestro servicio de QA; los fallos están en QA para código generado por IA.

Reflexiones finales

Un prototipo rápido es evidencia valiosa, pero producción es una decisión separada y basada en riesgo. No conserves ni sustituyas una capa por el nombre del builder. Verifica autorización, recuperación, secretos confidenciales, entornos, seguridad de despliegue, observabilidad, soporte y plan exacto.

Registra evidencia y objetivos pendientes y decide entre hardening, sustitución parcial o reconstrucción. Usa revisión independiente cuando haya datos sensibles, dinero, acciones privilegiadas o resultados críticos, y repite al cambiar arquitectura o proveedor.