Constructor de apps no-code con IA: cuándo quedarse y cuándo irse

Un constructor de apps no-code con IA como Lovable, Bolt o Base44 es un buen lugar para quedarse mientras tu app es un prototipo, una herramienta interna o un producto pequeño con reglas simples. Deberías irte, o al menos sacar el código, cuando necesites control sobre las reglas de datos, los pagos, el rendimiento, el hosting o las personas que pueden cambiar el código.

Soy un ingeniero brasileño y no tengo ningún interés en qué herramienta uses. Lo que sigue es cómo decidiría yo, con base en mi experiencia como ingeniero, incluida la migración de una plataforma en producción. Trata el código generado por IA como un primer borrador: corrige lo que existe antes de pensar en una reescritura.

¿Qué hace bien un constructor de apps no-code con IA?

Estas herramientas son fuertes para pasar de una idea a algo clicable en horas. Generan pantallas, formularios, tablas básicas de base de datos y flujos de login simples rápidamente. Para fundadores que están validando demanda, esa velocidad vale mucho.

Funcionan bien para:

• Prototipos y demos para inversionistas o primeros clientes.
• Dashboards internos que usa un puñado de personas de confianza.
• Landing pages con un registro simple o una lista de espera.
• Herramientas pequeñas en las que un error cuesta poco y los datos no son sensibles.

Donde suelen ser más débiles es en las partes que requieren criterio: quién puede leer qué fila, qué claves son seguras en el navegador, cómo se confirma un pago y qué pasa con tráfico real. Esas son las áreas en las que las herramientas suelen equivocarse.

¿Cuándo es mejor quedarse en el constructor?

Quedarse es la mejor decisión más seguido de lo que a los ingenieros les gusta admitir. Una migración cuesta tiempo, y el tiempo dedicado a migrar es tiempo que no dedicas a aprender de los usuarios.

Yo me quedaría cuando:

• Todavía no has demostrado que alguien quiere el producto.
• La app guarda pocos datos personales y no recibe pagos.
• Una persona no técnica la edita y ese flujo le funciona.
• La plataforma se encarga del hosting y no tienes a nadie que mantenga servidores.
• Las cuatro revisiones básicas pasan: tus reglas de datos son correctas, no hay claves secretas en el navegador, los pagos se confirman en el servidor y existen backups.

Recuerda la división de responsabilidad compartida. El constructor protege su infraestructura y sus cuentas. Tú eres responsable de quién puede leer qué datos, de las claves en el navegador, de la confirmación de pagos y de los backups. Esa responsabilidad no se va si te vas, y no desaparece si te quedas.

Un ejemplo público: en julio de 2025, investigadores de Wiz descubrieron que Base44, propiedad de Wix, permitía que un atacante se registrara en apps que debían ser privadas usando solo el ID de la app. Se corrigió en menos de un día. Eso muestra el lado de la plataforma resuelto rápidamente. También muestra por qué deberías saber qué expone tu propia app.

¿Qué señales muestran que ya te quedó chico?

Estas son las señales que busco. Una sola rara vez basta. Dos o tres juntas suelen significar que es momento de planear una migración.

• Usuarios reales y dinero real. Recibes pagos o guardas datos que a la gente le molestaría ver filtrados.
• Reglas que no puedes expresar. Necesitas una lógica de acceso que el constructor sigue haciendo mal, como row level security en Supabase. Las apps construidas con Lovable han mostrado un patrón de reglas de RLS débiles.
• Ciclos de corrección. Cada prompt para corregir un bug rompe otra funcionalidad.
• Lenta con tráfico. Las páginas o las consultas se vuelven lentas cuando más de unas pocas personas usan la app.
• Los ingenieros no pueden trabajar en ella. Un desarrollador que contratas quiere pull requests normales, code review, staging y tests.
• Preguntas de compliance o de clientes. Los compradores preguntan dónde están los datos y quién puede acceder a ellos.

Es tentador pedirle al constructor con IA que arregle esto, pero las reglas de datos, las claves y los flujos de pago son justo lo que las herramientas suelen hacer mal. Un escáner genérico también pasa por alto lógica de negocio como los webhooks de Stripe y los pedidos duplicados, así que una revisión humana de esos flujos importa.

¿Qué hace falta para llevar el código a GitHub y a tu propio hosting?

El código construido en Lovable se puede llevar a GitHub y a tu propio hosting. Los pasos generales son parecidos para otros constructores, aunque las opciones de exportación varían, así que revisa qué admite el tuyo.

1. Conecta o exporta el repositorio. Lleva el código completo a GitHub, en una cuenta que sea de tu empresa.
2. Haz un inventario de todo lo que está fuera del código. Lista la base de datos, la configuración de autenticación, los buckets de almacenamiento, las variables de entorno, el proveedor de email y los webhooks de terceros.
3. Rota los secretos. Da por expuesta cualquier clave que haya pasado por el navegador o por el historial del chat, y reemplázala.
4. Configura el hosting y un pipeline. Despliega en un host que controles, con entornos separados de staging y producción.
5. Revisa las reglas de datos. Prueba las políticas de acceso intentando leer los datos de otros usuarios.
6. Verifica los pagos. Confirma los pedidos a partir de eventos firmados del lado del servidor, no de la redirección del navegador.
7. Haz un backup y prueba una restauración. Un backup que nunca restauraste es una suposición.
8. Haz el cambio. Cambia el DNS o el tráfico cuando staging se comporte como producción.

La base de datos suele ser la parte más difícil. Si usas Supabase, puedes mantenerlo como backend y migrar solo el frontend, lo que reduce mucho el riesgo.

¿Cuánto cuesta salir del constructor en tiempo y riesgo?

No voy a inventar un precio, porque depende del tamaño de la app, del volumen de datos y de qué tan desordenado esté el código generado. Lo que sí puedo decir es cómo suele comportarse el costo.

• La mayor parte del riesgo se encuentra con unas pocas revisiones enfocadas, no con una auditoría completa.
• El costo de corregir crece después de que llegan usuarios reales y pagos, porque cada cambio pasa a tocar datos en producción.
• Una reescritura cuesta más que corregir las partes de mayor riesgo del código existente, así que empieza por las correcciones.

Lideré la migración completa de una plataforma de postulación automática a empleos, en producción, de un stack legado a uno nuevo mientras los usuarios seguían usándola. La lección que me llevé: el código rara vez es la parte difícil. Lo difícil es mover los datos, mantener el comportamiento idéntico y tener un camino de vuelta si algo sale mal. Planea ejecutar ambos en paralelo, prueba con datos realistas y conserva el sistema anterior hasta que el nuevo demuestre que funciona. No puedo prometer un plazo fijo para tu app, porque eso depende de lo que encuentres en el inventario.

Estas son mis reglas prácticas, no cifras medidas.

¿Puedes migrar una parte de la app y dejar el resto en el constructor?

Sí, y a menudo es el término medio sensato. No necesitas elegir entre todo o nada.

Divisiones comunes que yo consideraría:

• Migrar primero los pagos. Pon el manejo de Stripe en un servidor pequeño que controles y deja las pantallas en el constructor.
• Mantener Supabase, migrar el frontend. Tus datos se quedan donde están mientras la interfaz vive en GitHub y en tu hosting.
• Sacar los jobs pesados. Ejecuta las tareas lentas o programadas en un servicio aparte.
• Mantener el panel de administración. Las herramientas internas pueden quedarse en el constructor mucho después de que la app pública haya migrado.

El costo es la complejidad. Dos sistemas significan dos lugares que monitorear y proteger. Anota quién es responsable de cada pieza, para que nada quede en medio.

¿Quieres una segunda opinión?

Si estás decidiendo si quedarte o migrar, escribe a me@filipeeduardo.dev con el link y una descripción breve, y te diré qué revisaría primero.