Apps de constructores con IA: qué corregir antes de usuarios reales

Un constructor de apps con IA como Lovable, Bolt o Base44 puede darte una app funcionando en una tarde. Lo que no te da es la prueba de que la app es segura para usuarios reales y pagos reales. La mayor parte del riesgo está en cuatro lugares: quién puede leer qué datos, qué claves están expuestas, cómo se confirman los pagos y si puedes restaurar un backup.

Soy un ingeniero full-stack sénior brasileño con siete años de experiencia (desde 2019) construyendo productos web y móviles de punta a punta. Esta guía es lo que yo revisaría primero en una app que generó otra persona. No necesitas una auditoría completa para encontrar la mayoría de los problemas, pero sí necesitas mirar antes del lanzamiento, porque corregir las cosas sale más caro cuando ya existen usuarios y pagos reales.

¿Qué construye realmente un constructor de apps con IA por ti?

Un constructor típico genera un frontend (a menudo en React), lo conecta a un servicio de backend (muy a menudo Supabase, para base de datos y login), integra pagos (a menudo Stripe) y aloja el resultado. Tú describes las funcionalidades en lenguaje común y él escribe el código.

Eso es realmente útil para prototipos, herramientas internas y validación temprana. El resultado suele verse terminado: las páginas cargan, los formularios guardan, el login funciona. La brecha está en lo que no puedes ver haciendo clic por la app:

• Reglas sobre qué usuario puede leer o cambiar qué filas.
• Dónde viven los secretos y si terminan en el navegador.
• Qué pasa cuando un evento de pago llega dos veces, tarde o nunca.
• Qué pasa cuando la base de datos se daña o se borra.

El constructor optimiza para una app que funciona en la demo. Producción pregunta qué pasa cuando alguien actúa de mala fe, cuando crece el tráfico o cuando algo falla a mitad de camino. Por eso llamo al código generado un primer borrador: uno bueno para empezar, pero no revisado por nadie que estuviera pensando en fallas.

¿Qué protege el constructor y qué sigue siendo tu responsabilidad?

Aquí la seguridad es una responsabilidad compartida. El constructor protege su propia infraestructura y sus cuentas. Tú, como dueño de la app, eres responsable del comportamiento de tu app: quién puede leer qué datos, qué termina en el navegador, cómo se confirman los pagos y si existen backups.

Un ejemplo público muestra por qué importa esta división. En julio de 2025, investigadores de Wiz descubrieron que Base44, el constructor de apps con IA 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 un día. Fue un problema del lado de la plataforma, y la plataforma lo corrigió. Pero también muestra que no puedes asumir que toda configuración es segura por defecto, y que las apps privadas son tan privadas como las capas que las rodean.

Del otro lado, una regla de datos débil en tu propio proyecto de Supabase no es un bug de la plataforma. Es tu configuración, y nadie la va a corregir si no la revisas. No digo que estas herramientas sean malas. Digo que la línea de responsabilidad es clara, y la mayoría de los fundadores no sabe de qué lado está parado.

¿Qué cuatro revisiones cubren la mayor parte del riesgo antes del lanzamiento?

No necesitas una auditoría de un mes. En mi experiencia, cuatro revisiones enfocadas detectan la mayor parte de lo que importa antes de que lleguen los usuarios reales:

1. Reglas de acceso a datos: ¿un usuario puede leer o editar los datos de otro usuario?
2. Claves expuestas: ¿algún secreto es visible en el navegador o en el repositorio?
3. Confirmación de pagos: ¿la app otorga acceso solo después de que el proveedor de pagos lo confirma, y maneja las repeticiones?
4. Backups: ¿puedes restaurar tus datos, y ya lo probaste?

En mi experiencia, cada una toma horas y no semanas si sabes dónde mirar, aunque varía según la app. Las siguientes cuatro secciones las recorren una por una. Esta es mi regla práctica, no un estándar formal, y no reemplaza una auditoría en serio para apps que manejan datos muy sensibles, como registros de salud o financieros.

¿Quién puede leer qué datos en mi app construida con IA?

Esta es la revisión que hago primero. Con Supabase, el navegador habla directamente con la base de datos, y la row level security (RLS) decide qué puede ver cada usuario con sesión iniciada. Si la RLS está desactivada, o las reglas son demasiado permisivas, cualquiera que tenga la URL pública de tu proyecto y la clave puede consultar las tablas. Las apps construidas con Lovable han mostrado un patrón de reglas de RLS débiles, así que aquí es donde miro antes que nada.

Qué probar

• Abre el panel de Supabase y lista todas las tablas. Confirma que la RLS está habilitada en cada una.
• Lee cada policy. Una regla que dice que cualquiera puede hacer select, insert o update suele ser un resto del desarrollo.
• Crea dos cuentas de prueba. Inicia sesión como el usuario A, copia el ID de un registro del usuario B e intenta leerlo o cambiarlo.
• Prueba sin sesión iniciada. El acceso anónimo debe limitarse a lo que es realmente público.
• Revisa los buckets de storage. Confirma si los archivos subidos son públicos o privados, ya que un bucket puede configurarse como público.

Errores comunes

Policies que solo verifican que el usuario tenga sesión iniciada, no que la fila le pertenezca. Funciones de administrador protegidas solo con ocultar un botón en la interfaz. Tablas con datos personales que cualquier cuenta puede leer. La corrección suele ser un puñado de policies escritas con cuidado, no una reconstrucción. Pídele a la IA del constructor que las escriba si quieres, pero verifica con la prueba de las dos cuentas, porque esa es la prueba que importa.

¿Hay alguna clave secreta expuesta en el navegador?

Todo lo que se envía al navegador es público. Cualquiera puede abrir las herramientas de desarrollador y leerlo. Algunas claves están diseñadas para eso, como la anon key de Supabase (segura solo si la RLS es correcta) y la publishable key de Stripe. Otras nunca deben salir del servidor: la service role key de Supabase, las claves secretas de Stripe, los secretos de webhook y las claves de API de terceros para email, modelos de IA o SMS.

Cómo buscar

• Abre tu app en producción, mira el código fuente de la página y la pestaña de red, y busca palabras como secret, key, token y service_role.
• Busca en tu repositorio de código, incluido su historial, los mismos términos y archivos .env.
• Revisa cualquier llamada desde el frontend directamente a una API de pago. Si la clave está en el navegador, alguien puede usarla y la factura te llega a ti.

Qué hacer si encuentras una

Primero rota la clave, es decir, genera una nueva y revoca la anterior. Quitarla del código no basta, porque puede que ya la hayan copiado. Luego mueve la llamada a una función de servidor o al backend, donde la clave queda como variable de entorno y el navegador solo llama a tu endpoint. Ese endpoint también debe verificar quién hace la solicitud y limitar el uso.

¿Mi app confirma los pagos correctamente?

Aquí es donde fallan los escáneres genéricos, porque se trata de lógica de negocio. Un patrón común en el código generado: cuando el cliente vuelve de la página de checkout de Stripe, la app marca el pedido como pagado basándose en la redirección. Pero una redirección no prueba nada. Alguien puede visitar la URL de éxito directamente, o el cliente puede pagar y cerrar la pestaña antes de volver.

El enfoque confiable es que tu servidor reciba eventos de Stripe (webhooks), verifique su firma con el secreto del webhook y solo entonces otorgue acceso o marque el pedido como pagado.

Qué verificar

• ¿Existe un endpoint de webhook, y verifica la firma?
• ¿El acceso se otorga solo a partir de eventos verificados, y no desde la página de éxito?
• ¿El handler es idempotente? Stripe puede enviar el mismo evento más de una vez, y no debes crear dos pedidos ni acreditar dos veces.
• ¿Qué pasa con los pagos fallidos, los reembolsos, las disputas y las suscripciones canceladas?
• ¿Un usuario puede cambiar el precio o el plan en una solicitud desde el navegador?

Prueba con el modo de prueba de Stripe antes de cobrar cualquier tarjeta real. No voy a profundizar en webhooks aquí, porque merecen su propio recorrido, pero si revisas un solo punto de pagos, que sea este: nunca confíes en que el navegador te diga que un pago se realizó.

¿Tengo backups que realmente pueda restaurar?

Un backup que nunca has restaurado es una esperanza, no un backup. Las apps generadas a menudo corren sobre una sola base de datos con la configuración por defecto, y los fundadores asumen que alguien más se está encargando. En la división de responsabilidad compartida, confirmar los backups es tu trabajo.

Preguntas que responder

• ¿El plan de tu base de datos incluye backups automáticos, y hasta cuándo atrás llegan?
• ¿La recuperación point-in-time está disponible en tu plan, o solo snapshots diarios?
• ¿Los archivos subidos también tienen backup, o solo la base de datos?
• ¿Tienes una copia de tu código fuera del constructor?
• ¿Alguien ha restaurado un backup en un proyecto de prueba separado y confirmado que la app funciona con él?

Piensa también en accidentes, no solo en ataques. Una migración generada o una edición de la IA puede eliminar una columna o sobrescribir datos. Un simulacro de restauración suele ser un ejercicio corto (mi estimación: un par de horas para una app pequeña) y te dice cuánto tardaría la recuperación. Revisa las funciones de backup actuales de tu plan en la documentación del proveedor, ya que cambian con el tiempo y varían según el nivel.

¿Debo corregir el código generado por IA o reescribirlo?

Corrige primero. Trata el código generado como un primer borrador y corrige los problemas de mayor riesgo en el código existente antes de considerar una reescritura. Las reescrituras se sienten limpias, pero tiran a la basura pantallas, flujos y decisiones que funcionan, y retrasan el lanzamiento mientras agregan bugs nuevos.

El orden que yo usaría:

1. Cierra las reglas de datos y rota las claves expuestas.
2. Corrige la confirmación de pagos y haz que los handlers sean idempotentes.
3. Configura backups y prueba una restauración.
4. Pasa el código a GitHub, agrega monitoreo básico de errores y una copia de staging.
5. Después, ordena la estructura donde duele: lógica duplicada, archivos gigantes, queries lentas.

Una reescritura se vuelve razonable cuando el modelo de datos está fundamentalmente mal, cuando cada cambio rompe otra cosa o cuando necesitas capacidades que la estructura generada no soporta. Aun así, yo rescataría lo que funciona, como el schema y las pantallas, en lugar de empezar de cero. Pedirle al constructor que corrija sus propios problemas de seguridad ayuda con lo simple, pero las reglas de datos, las claves y los flujos de pago son justo lo que estas herramientas suelen hacer mal, así que verifica sus respuestas tú mismo o con un segundo par de ojos.

¿Cuándo es mejor quedarse en el constructor de apps con IA?

Irse no siempre es la respuesta. Quedarse suele ser mejor cuando:

• La app es un prototipo o una herramienta interna con unos pocos usuarios de confianza.
• Todavía estás validando la idea y el diseño cambia cada semana.
• No hay pagos y hay pocos datos sensibles.
• Nadie en el equipo podría mantener una base de código y un hosting separados.
• Las cuatro revisiones pasan y los límites del constructor no te están bloqueando.

Migrar tiene costos reales: asumes el hosting, los despliegues, las variables de entorno y el monitoreo. Si nadie puede encargarse de eso, quizá estés cambiando un riesgo manejable por uno nuevo.

Señales de que es hora de irse: necesitas lógica de backend personalizada y el constructor te pone trabas, necesitas ambientes y revisión de código, el precio o los límites ya no te sirven, el rendimiento sufre con tráfico real, o un cliente exige control sobre dónde corre la app. La decisión debe venir de un bloqueo concreto, no de una sensación vaga de que las empresas de verdad usan su propio hosting.

¿Cómo paso mi código a GitHub y a mi propio hosting?

El código construido en Lovable se puede pasar a GitHub y al hosting del propio dueño. Otros constructores tienen sus propias opciones de exportación, así que revisa qué soporta el tuyo antes de planificar.

1. Conecta el proyecto a GitHub con la integración del constructor, para que el repositorio se convierta en la fuente de verdad.
2. Clónalo y ejecútalo localmente. Corrige todo lo que solo funcionaba dentro del constructor.
3. Lista las variables de entorno y guárdalas en la configuración de tu hosting, nunca en el repositorio.
4. Sé dueño de las cuentas de backend. Asegúrate de que las cuentas de Supabase y Stripe te pertenezcan a ti o a tu empresa, no al login personal de un excontratista.
5. Elige el hosting. Un frontend estático o en Next.js funciona en plataformas comunes como Vercel o Netlify, mientras que el código de servidor puede correr como funciones o en un servidor pequeño.
6. Configura una copia de staging con claves de prueba, despliega ahí primero y prueba el login, las reglas de datos y los pagos.
7. Cambia el dominio solo después de que staging pase, y mantén la versión anterior corriendo hasta estar seguro.

Hazlo antes del lanzamiento si puedes. Migrar una app en producción con usuarios que pagan implica migrar datos y evitar sesiones rotas, lo cual es posible pero requiere más cuidado. No prometo nada sobre downtime en ninguna migración, pero un ensayo en staging reduce mucho las sorpresas.

¿Quieres una segunda opinión sobre tu app?

Si construiste algo con una herramienta de IA y no estás seguro de alguna de estas cuatro revisiones, escríbeme a me@filipeeduardo.dev con el link y unas líneas sobre lo que hace, y te diré qué revisaría primero.