Hice mi app con Lovable, Bolt o Cursor: ¿está lista para clientes?

Puede estarlo, pero que funcione en la vista previa no significa que esté lista para clientes. Antes de cobrar o pedir datos, comprueba que nadie pueda ver los datos de otros usuarios, que no haya claves secretas en el código que descarga cada visitante y que la app funcione bien en el móvil y en una ventana privada. Es una tarde de trabajo, sin saber programar, y la propia IA puede arreglar casi todo lo que encuentres.

Esta guía es para quien ha creado su app hablando con una IA (Lovable, Bolt, Cursor, v0, Replit) y está a punto de compartir el enlace, conectar su dominio o activar los pagos. Es el mejor momento para revisar: todavía no hay datos reales, y arreglar algo cuesta minutos, no un disgusto con un cliente.

Por qué una app puede funcionar bien y no estar lista

Las herramientas de IA están hechas para que lo que pides funcione, y suelen conseguirlo. El problema es que toman el camino más corto. Si una consulta a la base de datos falla por falta de permisos, lo más rápido es abrir la tabla a todo el mundo. Si una función necesita la clave de OpenAI o de Stripe, lo más rápido es dejarla junto al código que la usa. Ninguna de las dos cosas da error: la app funciona, y por eso nadie se entera.

Para seguir esta guía basta con entender dos ideas:

• Tu app tiene una parte pública. Todo lo que se ejecuta en el navegador (las pantallas, los botones y la lógica que hay detrás) se descarga entero en el dispositivo de cada visitante, y cualquiera puede leerlo. Una clave secreta es la contraseña con la que tu app usa un servicio externo, como OpenAI o Stripe. Dejarla ahí es como dejar la llave de la caja pegada en el escaparate.
• La base de datos decide quién ve qué. Muchas apps hechas con Lovable o Bolt guardan sus datos en Supabase, un servicio de bases de datos (Lovable Cloud, la base de datos integrada de Lovable, también funciona sobre Supabase). La app habla con Supabase usando una clave pública, y es normal que esa clave esté a la vista. Lo que protege los datos son unas reglas por tabla llamadas RLS (Row Level Security, «seguridad a nivel de fila»). Dicen, por ejemplo, «cada usuario solo ve sus propios pedidos». Sin esas reglas, quien tenga la clave pública puede leer la tabla entera, y a veces también cambiarla o borrarla.

Nueve comprobaciones antes de abrir la puerta

Hazlas sobre la versión publicada, no sobre la vista previa. Apunta lo que falle; al final tienes un mensaje para que la IA lo arregle.

1. Pruébala como un desconocido. Abre una ventana privada (en Chrome, «Nueva ventana de incógnito»), crea una cuenta nueva con otro correo y usa la app. Si en algún momento ves datos que no son de esa cuenta (pedidos, nombres o mensajes de otros), detente: eso va antes que todo lo demás. Prueba también a cambiar un número en la dirección, por ejemplo de /pedido/124 a /pedido/123. Si se abre el pedido de otra persona, la app no comprueba quién pregunta.

2. Pruébala en el móvil, con datos móviles. Regístrate, inicia sesión, recupera la contraseña y, si cobras, paga. Muchas cosas que van bien en la vista previa fallan en un móvil real o en la versión publicada.

3. Recorre el camino del dinero. Si usas Stripe, haz una compra completa en modo de prueba y comprueba que llega el correo de confirmación y que el pedido aparece donde debe. Cuando pases al modo real, haz una compra pequeña de verdad y reembólsala desde el panel de Stripe.

4. Pasa el escáner de tu herramienta. Lovable hace un análisis rápido (Quick scan) cada vez que abres la ventana de publicación (Publish): revisa las reglas de la base de datos y las dependencias, es decir, el código de terceros que usa tu app. Además, puedes lanzar a mano el análisis profundo (Deep scan), que repasa también el código de la app en busca de claves filtradas, accesos sin control y datos personales expuestos. Lo explica su documentación de seguridad (en inglés). Lanza el profundo antes de abrir la app a clientes y revisa cada aviso, empezando por los más graves. Si trabajas con Bolt o Cursor, usa el mensaje de más abajo.

5. Revisa las tablas de Supabase. Si tienes tu propio proyecto de Supabase, abre su panel y entra en Advisors y luego en Security Advisor: ahí aparecen las tablas sin RLS y otros avisos de seguridad. Cada tabla con datos de usuarios necesita RLS activado y una regla que no sea «todo el mundo puede leerlo todo». Si usas Lovable Cloud, no tienes ese panel: el análisis del paso 4 revisa esas mismas reglas. Lo que se puede comprobar desde fuera lo tienes en la revisión de Supabase.

6. Busca claves secretas. Una clave secreta (la de OpenAI, la secreta de Stripe que empieza por sk_live_, la service_role o la sb_secret_ de Supabase) nunca debe llegar al navegador. Ojo con los nombres: en las apps hechas con Vite, lo habitual en Lovable y Bolt, todo lo que empieza por VITE_ acaba en el código público; en Next.js, lo habitual en v0, todo lo que empieza por NEXT_PUBLIC_. Para buscarlas, usa el mensaje de más abajo o la revisión gratuita del final; si te animas a hacerlo a mano, aquí tienes cómo encontrar claves en el código JavaScript (en inglés). Si una clave secreta se ha publicado alguna vez, no basta con borrarla del código: hay que cambiarla por otra nueva en el panel del servicio, porque alguien pudo copiarla.

7. Mira si hay errores en la consola. En Chrome, abre tu app publicada y pulsa Ctrl + Mayús + J (en Mac, Cmd + Opción + J). Se abre la consola, un panel donde el navegador apunta los fallos de la página. Las líneas en rojo son errores. No hace falta entenderlas: haz una captura y pégasela a la IA. Google lo explica paso a paso en su guía sobre cómo abrir las herramientas para desarrolladores de Chrome.

8. Pon lo legal mínimo. Una política de privacidad que diga qué datos guardas y para qué; unas condiciones de uso si cobras; y un aviso de cookies si usas analítica o píxeles de publicidad. En España, además, el aviso legal, con los datos de quién está detrás de la app. Las reglas cambian según el país: en la Unión Europea se aplica el RGPD (el GDPR, por sus siglas en inglés), y en América Latina cada país tiene su propia ley de protección de datos. Esto no es asesoramiento legal; si vas a tratar datos delicados (de salud o de menores, por ejemplo) o a cobrar directamente con tarjeta, merece la pena consultarlo con un profesional.

9. Conecta tu dominio y prueba el correo. Si usas tu propio dominio, comprueba que la app abre con conexión segura (HTTPS, el candado o el icono de ajustes junto a la dirección), con www y sin www. Regístrate con una cuenta de Gmail y otra de Outlook: si el correo de bienvenida cae en spam, pide a la IA o a tu proveedor de dominio que configure SPF y DMARC, dos registros del dominio que indican qué servidores pueden enviar correo en tu nombre.

El mensaje para que la IA lo revise y lo arregle

Pide cosas concretas. «Hazla segura» suele producir un resumen tranquilizador y pocos cambios reales. Este mensaje funciona en Lovable, Bolt, Cursor o Claude Code; cambia lo que va entre corchetes:

Antes de abrir la app a clientes, revisa estos puntos.
Primero dime qué encuentras en cada uno y qué propones
cambiar; no toques nada hasta que te lo confirme.

1. Busca claves secretas en el código que llega al navegador:
   service_role, sb_secret_, sk_live_, sk- y cualquier clave
   en variables VITE_ o NEXT_PUBLIC_. Mueve cada llamada que
   las necesite a una función de servidor y dime qué claves
   tengo que cambiar en cada servicio.
2. Activa Row Level Security en todas las tablas de Supabase.
   Cada usuario solo puede leer y cambiar sus propias filas
   (user_id = auth.uid()). Solo estas tablas son públicas: [lista].
3. Cada función de servidor debe comprobar quién llama y
   responder 401 si no hay usuario, salvo las que yo diga.
4. Los archivos que suben los usuarios deben ser privados,
   salvo: [lista].
5. Comprueba que un usuario no puede abrir pedidos, perfiles
   o archivos de otro cambiando un id en la dirección.
6. Lista los errores que aparecen en la consola del navegador
   en la versión publicada y corrígelos.

Explícame cada cambio en lenguaje sencillo.

Después, repite las comprobaciones 1, 5, 6 y 7. Un arreglo está hecho cuando la comprobación pasa, no cuando la IA dice que ya está.

Después del lanzamiento: cada cambio es una versión nueva

Una app hecha con IA cambia mucho. Cada mensaje puede reescribir media app, y lo que arreglaste la semana pasada puede volver con la siguiente función: una tabla nueva sin reglas, una clave nueva en el sitio equivocado, una pantalla que deja de cargar en el móvil. La app no te va a avisar.

Dos costumbres ayudan:

• Aprende dónde está el historial de versiones de tu herramienta, para volver a la anterior si una actualización rompe algo. Primero vuelves atrás; después investigas.
• Tras cada cambio importante, repite las comprobaciones 1, 2 y 7. Son cinco minutos.

Si además quieres la revisión general de cualquier web (conexión segura, cookies, formularios, señales de ataque), la tienes en ¿Cómo saber si mi página web es segura?.

Una revisión gratuita, desde fuera

ScanYourSite mira tu app publicada como la vería un desconocido. Escribes la dirección y, en un minuto más o menos, tienes una lista ordenada por gravedad. Es gratis y sin registro. En la versión gratuita, los tres problemas más importantes vienen explicados, con cómo arreglarlos y un mensaje para que tu IA lo haga; Pro los explica todos. También puedes abrir https://scanyoursite.app/es?check=tudominio.com con tu dominio: el enlace solo rellena el campo, y la revisión empieza cuando pulsas el botón.

La revisión gratuita:

• busca claves secretas (de Supabase, OpenAI, Stripe y otros servicios) en el código JavaScript que la página carga al abrirse;
• te dice con qué proyecto de Supabase habla la app;
• revisa el HTTPS, el certificado y las cabeceras de seguridad, que son instrucciones que tu app da al navegador para protegerse;
• abre la página en un navegador real para ver los errores al cargar, el título, la descripción y la vista previa que aparece al compartir el enlace;
• avisa si hay analítica o publicidad funcionando sin ninguna herramienta de consentimiento reconocida (no pulsa el aviso de cookies, así que no puede saber si «Rechazar» de verdad las frena).

No inicia sesión, no envía formularios ni prueba contraseñas.

El plan gratuito vigila una app: la revisa una vez por semana, te manda un resumen semanal por correo y te avisa antes de que caduque el certificado. Con Pro, y solo después de demostrar que el dominio es tuyo, también calcula de forma aproximada cuántas filas de las tablas que consulta tu app podría leer un desconocido con la clave pública, sin leer nunca su contenido, y comprueba si se puede descargar un archivo .env o la carpeta .git, que nunca deberían ser públicos. Pro cuesta 19 dólares o 19 euros al mes, para tres apps: revisión diaria, comprobación cada cinco minutos de que la app responde y una revisión a los pocos minutos de cada versión publicada. Te escribe por Telegram, por correo, o en Slack o Discord solo cuando algo nuevo falla.