Checklist de lanzamiento para apps construidas con IA: 5 revisiones

Un buen checklist de lanzamiento para una app construida con IA se reduce a cuatro revisiones antes de que lleguen los usuarios reales: quién puede leer qué datos, qué claves están expuestas en el navegador, si los pagos se confirman en el servidor y si puedes restaurar un backup. Dos pasos más, una prueba de carga básica y un despliegue por etapas, mantienen el lanzamiento tranquilo.

Soy un ingeniero sénior brasileño, y este es el orden en que hago estas revisiones cuando analizo una app generada con Lovable, Bolt, Base44 o herramientas similares. Nada de esto requiere una auditoría completa. Unas pocas revisiones enfocadas encuentran la mayor parte del riesgo, y corregir problemas sale más caro una vez que hay usuarios reales y pagos en el sistema.

¿Qué debe cumplirse antes de lanzar una app construida con IA?

Antes del lanzamiento, cinco afirmaciones deben ser ciertas, y deberías poder demostrar cada una en lugar de creerla:

1. Un usuario no puede leer ni modificar los datos de otro usuario.
2. Ninguna clave secreta llega al navegador.
3. Un pedido se marca como pagado solo después de que el servidor confirma el pago.
4. Has restaurado un backup al menos una vez, con éxito.
5. La app funciona con más de una persona usándola al mismo tiempo.

La lista es corta por el modelo de responsabilidad compartida. El constructor y el proveedor de base de datos protegen sus servidores y cuentas. No saben cuáles son tus reglas de negocio. Quién puede ver una factura, qué precio es válido, cuándo un pedido cuenta como pagado: eso es comportamiento de tu app, así que te toca a ti verificarlo.

Las herramientas de IA son buenas para hacer que las pantallas funcionen. Son más débiles en las partes invisibles, y esas son justamente las partes que cubren las revisiones de abajo.

¿Las reglas de acceso a datos están probadas con una segunda cuenta?

Esta es la revisión que nunca me saltaría. Si tu app usa Supabase, el acceso se controla con políticas de row level security (RLS). Las apps construidas con Lovable han mostrado un patrón de reglas de RLS débiles, así que no supongas que las tuyas están bien solo porque la app se ve bien cuando la usas.

Cómo probarlo en 15 minutos

1. Crea dos cuentas de usuario normales, A y B, en navegadores separados.
2. Como A, crea un registro: un pedido, un documento, una nota de perfil.
3. Como B, intenta abrir el registro de A por su URL o ID. Debería fallar.
4. Abre las herramientas de desarrollador del navegador como B, encuentra la solicitud a la API que hace la app y cambia el ID o el filtro por el de A. No debería devolver nada.
5. Cierra sesión por completo y repite la solicitud. El acceso anónimo debería rechazarse para todo lo que sea privado.

Revisa también que RLS esté realmente habilitado en todas las tablas, no solo en las que recuerdas. Una tabla sin RLS y con la clave pública en el navegador la puede leer cualquiera que mire. Presta atención a las políticas que dicen algo como “permitir si el usuario inició sesión” sin vincular la fila a ese usuario.

El caso de Base44 de julio de 2025 es un recordatorio útil. Investigadores de Wiz descubrieron que alguien podía registrarse en apps que debían ser privadas usando solo el ID de la app, y se corrigió en menos de un día. La plataforma corrigió su parte rápido, pero la lección para los dueños es confirmar, desde afuera, que tu app privada es realmente privada.

¿Hay alguna clave expuesta en el navegador?

Todo lo que llega al navegador es público. Abre el sitio, revisa el JavaScript que carga la página y la pestaña de red, y observa lo que se envía.

Algunas claves están pensadas para ser públicas: la anon key de Supabase, la publishable key de Stripe. Solo son seguras si tus reglas de datos son correctas, y por eso la revisión anterior va primero. Otras claves nunca deben aparecer ahí:

• La service role key de Supabase (se salta RLS por completo)
• La secret key de Stripe y el secreto de firma del webhook
• Cualquier clave de API de terceros que te cobre por llamada, como un proveedor de modelos de IA o un servicio de email

Qué hacer si encuentras una

Primero rótala y después corrige el código. Quitar una clave del código no sirve si ya se sirvió a los visitantes o se subió a un repositorio, porque debe tratarse como filtrada. Mueve la llamada que la necesita a una función de servidor o a una ruta de backend, y guarda el secreto en variables de entorno del lado del servidor.

Si el código está en GitHub, busca también en el historial del repositorio. Una clave borrada la semana pasada sigue en los commits antiguos.

¿El pago se confirma en el servidor?

Un patrón común en código generado por IA es redirigir al usuario a Stripe Checkout y, cuando vuelve a una página de “éxito”, marcar el pedido como pagado. Cualquiera que adivine la URL puede llegar a esa página, y se omite por completo si el usuario cierra la pestaña después de pagar.

El enfoque confiable es que Stripe notifique a tu servidor mediante un webhook, y que tu servidor verifique la firma del evento antes de cambiar cualquier cosa. Solo entonces el pedido debe quedar como pagado.

Prueba estos casos:

• Abre la URL de éxito directamente sin pagar. El pedido debe seguir sin pagar.
• Paga y cierra la pestaña antes de la redirección. El pedido igual debe quedar como pagado.
• Reenvía el mismo evento de webhook dos veces. No deberías terminar con dos pedidos ni dos entregas.
• Comprueba que el monto y el producto vengan de tu servidor, no de valores que envió el navegador. Un usuario no debería poder editar un precio en una solicitud.

Aquí es donde los escáneres de seguridad genéricos suelen quedarse cortos, porque los pedidos duplicados y la lógica de webhooks son lógica de negocio, no patrones de vulnerabilidad conocidos. Los detalles de los webhooks merecen su propia guía, así que aquí solo cubro la pregunta a nivel de lanzamiento: ¿decide el servidor o el navegador?

¿Puedes restaurar un backup?

Tener los backups activados no es lo mismo que tener un backup que puedas restaurar. Muchos fundadores descubren la diferencia en medio de un incidente.

Haz un simulacro antes del lanzamiento:

1. Averigua qué respalda realmente el plan de tu base de datos y con qué frecuencia. Consulta la documentación actual del proveedor, porque esto varía según el plan.
2. Restaura un backup en un proyecto separado y vacío.
3. Abre la copia restaurada y comprueba que los datos recientes estén ahí y que la app pueda conectarse a ella.
4. Anota los pasos y cuánto tiempo tomó.

Decide también dónde vive tu código. El código construido en Lovable se puede llevar a GitHub y a tu propio hosting, lo que te da una copia que controlas tú. Si mañana suspendieran tu cuenta en el constructor, ¿podrías seguir haciendo deploy? Si la respuesta es no, resuélvelo antes del lanzamiento. Los archivos subidos, como imágenes y documentos, a menudo se almacenan aparte de la base de datos, así que confirma que también estén cubiertos.

¿La app aguantará tráfico real?

No necesitas una prueba de carga grande. Necesitas encontrar las fallas obvias. Los usuarios reales hacen cosas que tu demo nunca hizo: abren muchas pestañas, recargan una y otra vez y llegan todos al mismo tiempo después de que envías un email.

Revisiones simples que encuentran la mayoría de los problemas:

• Usa una herramienta de carga gratuita para simular unas cuantas decenas de usuarios concurrentes en tus flujos principales: registro, login, la página de listado principal y el checkout.
• Vigila la base de datos. Las páginas que cargan todas las filas de una tabla y filtran en el navegador se vuelven lentas a medida que crecen los datos.
• Busca índices faltantes en las columnas por las que filtras u ordenas.
• Revisa los límites de solicitudes en el login, en el restablecimiento de contraseña y en cualquier endpoint que envíe emails o llame a una API de pago. Sin límites, un solo script puede disparar tu factura.
• Confirma los límites del plan de tu hosting y de tu base de datos. Los planes gratuitos a menudo se pausan o se limitan.

Configura también el seguimiento de errores y un monitoreo básico de disponibilidad. Si algo se rompe a las 2 de la mañana, quieres enterarte por una alerta, no por un cliente.

¿Cómo abrir la app a los primeros usuarios de forma segura?

Lanza por etapas. Un grupo pequeño expone los problemas mientras el daño todavía es pequeño.

1. Entornos separados. Mantén separados los datos de prueba y los datos reales, y usa el modo de prueba de Stripe hasta el final.
2. Invita a un grupo pequeño. Empieza con un grupo pequeño de personas con las que puedas hablar directamente; como regla general, unas pocas decenas como máximo.
3. Revisa los primeros pagos a mano. Compara cada pago de Stripe con el pedido correspondiente en tu base de datos.
4. Ten un rollback. Debes saber cómo volver rápido a la versión anterior y quién lo hace.
5. Amplía gradualmente. Expande solo después de unos días sin sorpresas.

Quedarse en el constructor a veces es la decisión correcta, sobre todo para una herramienta interna o una app pequeña con datos de bajo riesgo. Las revisiones de arriba aplican en cualquier caso. Y si una revisión falla, corrige primero el problema específico en el código existente. Una reescritura rara vez es el primer paso.

¿Quieres una segunda opinión?

Si estás por lanzar una app construida con IA, escríbeme a me@filipeeduardo.dev con el enlace y una breve descripción, y con gusto te digo qué revisaría primero.