Hice mi app con IA (Lovable, Bolt, Cursor): cómo saber si está lista para usarla en serio

Empecemos por lo que no es

Esta guía no es una advertencia contra construir con inteligencia artificial. Todo lo contrario: herramientas como Lovable, Bolt o Cursor cambiaron para siempre la velocidad a la que una idea se convierte en algo que se puede tocar. Lo que antes era un proyecto de meses hoy puede ser un fin de semana entusiasta.

A eso se le llama vibe coding: describir en palabras lo que quieres y dejar que la IA escriba el código. Funciona, y funciona sorprendentemente bien. El punto de esta guía es otro, más acotado y más útil: cómo saber si la app que armaste está lista para recibir clientes reales, con sus datos, sus pagos y sus expectativas.

Porque hay una diferencia entre una app que funciona y una app que aguanta. La primera pasa la demo. La segunda pasa el martes a las once de la mañana, con doscientas personas usándola a la vez y alguien curioso probando qué pasa si cambia un número en la dirección de la página.

Lo que la IA hace bien (y rápido)

Conviene reconocerlo con precisión, porque es mucho. La IA es excelente en todo lo que se ve y se prueba haciendo clic: pantallas, formularios, navegación, diseño responsivo para móvil y escritorio, flujos de registro, listados con filtros. Si algo no funciona, lo notas enseguida y se lo pides de nuevo.

También es muy buena conectando piezas estándar: una base de datos en la nube, un inicio de sesión con correo, un servicio de envío de mensajes. En pocas horas tienes un producto que parece terminado.

Y ahí está justamente el detalle: parece terminado. Lo que la IA resuelve con menos cuidado es lo que no se ve en pantalla, porque nadie lo pide y ninguna demo lo revela.

Los agujeros típicos: datos expuestos, claves a la vista, permisos abiertos

Después de revisar muchas apps de este tipo, los problemas se repiten con una regularidad casi cómica. Son cuatro.

La base de datos que confía en todo el mundo. Muchas de estas apps usan bases de datos en la nube que se consultan directamente desde el navegador. Eso es perfectamente seguro siempre que cada tabla tenga reglas que digan quién puede leer y escribir qué. Servicios como Supabase ofrecen para eso la seguridad a nivel de fila (documentación de Supabase) y Firebase sus reglas de seguridad (documentación de Firebase). Si esas reglas no están activadas, o están escritas como “cualquier usuario con sesión puede leer todo”, cualquier cliente puede ver los datos de todos los demás.

Las claves a la vista. Para conectarse con servicios de pago, de correo o de inteligencia artificial, la app necesita claves secretas. Si esas claves quedaron en el código que se descarga el navegador, cualquiera con un poco de curiosidad puede copiarlas y usarlas a tu nombre. La factura, por supuesto, te llega a ti.

Los permisos que solo existen en la pantalla. La app esconde el botón de “administrador” a quien no lo es. Muy bien. Pero si el servidor no verifica ese permiso por su cuenta, basta con llamar a la función directamente para saltarse la pantalla. Esconder un botón no es lo mismo que cerrar una puerta.

Los formularios sin límites. Un formulario de contacto o de registro sin control de frecuencia puede recibir miles de envíos automáticos en minutos, y cada uno puede disparar un correo o una consulta que cuesta dinero.

Ninguno de estos problemas es nuevo: figuran desde hace años en la lista de riesgos de seguridad más conocida del rubro, el Top 10 de OWASP (OWASP). Lo nuevo es la velocidad: hoy se puede llegar a producción con ellos intactos en una sola tarde.

Las preguntas para saber si tu app aguanta clientes reales

No necesitas saber programar para hacerte estas preguntas. Sí necesitas respuestas concretas, idealmente comprobadas y no supuestas.

1. ¿Qué datos guarda la app y de quién son? Nombres, correos, documentos, historiales, pagos. Cuanto más sensible el dato, más alta la vara.
2. ¿Un usuario puede ver o modificar datos de otro? Se prueba con dos cuentas de prueba: una intenta leer lo de la otra.
3. ¿Qué pasa si alguien consulta la base de datos sin iniciar sesión? Debería no ver nada.
4. ¿Dónde están las claves secretas? La respuesta correcta es “en el servidor”, nunca “en el código de la página”.
5. ¿Quién puede hacer las acciones importantes? Borrar, aprobar, cobrar, exportar. Cada una tiene que verificarse del lado del servidor.
6. ¿Cuánta gente aguanta al mismo tiempo? No se adivina: se mide con una prueba de carga que simula usuarios simultáneos.
7. ¿Qué pasa cuando algo falla? Si hay copias de seguridad, si alguien recibe un aviso, si el error se puede rastrear.
8. ¿Cumple lo que la ley pide para esos datos? En Latinoamérica y en España existen normas de protección de datos personales, y una política de privacidad escrita a las apuradas no reemplaza las medidas reales.

Si a varias de estas preguntas la respuesta honesta es “no sé”, la app no está lista para clientes reales. Todavía.

Cuándo alcanza con ajustes y cuándo hay que rehacer

La buena noticia es que la mayoría de las apps hechas con IA se pueden rescatar. Si la estructura de los datos tiene sentido, lo habitual es cerrar permisos, mover las claves al servidor, agregar verificaciones donde faltan y medir el rendimiento. Es trabajo fino, no una demolición.

Rehacer conviene en menos casos, pero existen. Cuando la base de datos no refleja cómo funciona el negocio y cada función nueva exige un parche. Cuando arreglar una cosa rompe otra, una y otra vez. Cuando la app creció tanto a fuerza de pedidos sueltos que ya nadie, ni siquiera la IA, entiende cómo encajan las piezas. En esos casos, lo construido no se pierde: se convierte en el mejor documento de requisitos que podrías tener, porque muestra exactamente qué quieres.

La decisión entre ajustar y rehacer se toma después de revisar, nunca antes. Cualquiera que te diga lo contrario sin haber mirado el código está adivinando.

Cómo lo resolvemos en Adrede

Trabajamos todos los días con este mismo tipo de herramientas, así que conocemos bien sus virtudes y sus puntos ciegos. Cuando llega una app hecha con IA, la tratamos con el mismo método de seis fases que usamos para cualquier plataforma.

Aterrizar: entendemos qué hace la app, para quién y qué datos toca. Documentar: dejamos por escrito cómo está armada y qué encontramos, en un lenguaje que puedas leer sin traductor. Realizar: cerramos lo que está abierto y completamos lo que falta, sin tirar lo que funciona. Endurecer: la app pasa por una auditoría de seguridad con una lista de verificación completa y por una prueba de carga que mide cuánto aguanta de verdad. Demostrar: te mostramos las pruebas, no solo las conclusiones: el intento de leer datos ajenos que antes funcionaba y ahora falla, el número de usuarios simultáneos que soporta. Evolucionar: acompañamos la app después del lanzamiento, porque una app con clientes reales nunca está terminada.

El trabajo se cotiza por escrito, por etapas: primero un diagnóstico acotado, y después solo lo que ese diagnóstico justifique.

Tu app ya hizo lo más difícil

Pasar de la idea a algo que funciona es el salto que la mayoría nunca da. Si ya lo diste, lo que falta es menos épico y más importante: asegurarte de que lo que construiste cuide a las personas que van a confiar en ello.

Si quieres una segunda mirada antes de abrirle la puerta a tus clientes, en Adrede la hacemos con gusto. Y si después de revisarla resulta que ya estaba lista, también te lo vamos a decir.