Lovable, Bolt, v0, Replit y Cursor: hasta dónde te llevan y dónde te dejan solo

Lovable: la web completa más rápida, con el stack que ellos eligen

Lovable saca muy bien la app web clásica de producto: registro, panel, formularios, tablas, pagos. Su documentación es clara con el stack: los proyectos creados desde el 13 de mayo de 2026 usan TanStack Start con renderizado en servidor (los anteriores, React + Vite) y una base de datos PostgreSQL, sea su backend integrado (Lovable Cloud) o Supabase. No hay elección de framework ni de base de datos.

Han trabajado la seguridad: al abrir el diálogo de publicar lanzan un escaneo rápido que revisa las políticas de seguridad a nivel de fila (RLS) y las dependencias, y hay un escaneo profundo opcional. Es un buen paso. Pero un escáner detecta políticas que faltan; no sabe si «el jefe de obra solo ve su obra» es la regla correcta de tu negocio. Eso lo tienes que escribir y probar tú.

• Dónde se queda corta: móvil nativo. Lo dice su propia FAQ: Lovable genera aplicaciones web y no proyectos React Native. Para las tiendas propone una PWA o envolver la web con Capacitor, fuera de Lovable.
• Qué añadir a mano: tests de los permisos y de los flujos críticos que vivan en el repositorio, y el empaquetado móvil si lo necesitas. La sincronización con GitHub (y Bitbucket) te deja sacar el código cuando toque.

Bolt: flexible en el front, todo JavaScript detrás

Bolt corre en el navegador y admite cualquier framework de JavaScript en el frontend, con Node.js en el backend. Su documentación avisa de que PHP o Python no son compatibles. Con Bolt Cloud tienes base de datos, autenticación (correo y Google), hosting y dominios sin salir de la herramienta.

Es de las pocas que hace móvil de verdad desde el principio: se integra con Expo y genera apps React Native. Con dos condiciones que conviene leer antes de empezar. La primera: tienes que decir «mobile app» en el primer prompt, porque un proyecto web no se pasa fácilmente a móvil. La segunda: Bolt no compila ni firma la app. Para publicar, su guía te pide descargar el código, instalar la CLI de Expo (EAS) en tu ordenador y tener tus cuentas de desarrollador de Apple y de Google.

• Saca bien: prototipos web en el framework que prefieras y apps móviles sencillas en Expo.
• Qué añadir a mano: el proceso de build y firma, la configuración de las tiendas y un backend aparte si tu lógica pide Python u otro lenguaje.

v0: la mejor interfaz, si vives en el mundo Vercel

v0 nació generando interfaces y se nota: es donde mejor salen pantallas cuidadas en React. Hoy hace también aplicaciones completas: usa Next.js por defecto, con server actions y rutas de API para el backend, e integraciones de un clic con Supabase, Neon, Upstash y Vercel Blob. Importa repositorios de GitHub, trabaja con pull requests y publica en Vercel.

Su propia guía de apps completas recomienda ir por capas: primero la interfaz, luego los datos, luego la autenticación «para que cada usuario solo vea lo suyo». Es buen consejo, y deja claro dónde está el trabajo: la capa de permisos la pides tú y la compruebas tú. Una variable con el prefijo NEXT_PUBLIC_ acaba en el navegador; si ahí metes una clave secreta, la publicas.

• Saca bien: webs y paneles con mucha interfaz, sobre Next.js y Vercel.
• Dónde se queda corta: no es una herramienta de móvil nativo ni de tiendas.

Replit: el entorno entero, con el App Store a un botón

Replit es lo más parecido a un ordenador en la nube con un agente dentro. Trae PostgreSQL gestionado y su propio sistema de login, Replit Auth, que el agente configura con un prompt. Desde enero de 2026 el agente hace apps móviles con React Native y Expo, con vista previa en simulador o en tu móvil.

Es la que más lejos llega hacia las tiendas: construye y envía a TestFlight y de ahí al App Store, sin Xcode, con tu cuenta de Apple Developer. Pero ojo al detalle: a fecha de hoy su documentación dice literalmente que publicar en Google Play todavía no está soportado. Si tu público usa Android, ese tramo te toca a ti.

• Saca bien: prototipos completos con backend propio y apps de iPhone que quieres en TestFlight cuanto antes.
• Qué añadir a mano: Google Play, y cualquier módulo nativo que no esté en el SDK de Expo (la propia documentación avisa de que Expo Go no los admite todos).

Cursor: llega donde llegues tú

Cursor no tiene techo de stack: Flutter, Kotlin, Swift, Python, lo que sea. Su agente edita varios ficheros y ejecuta comandos, y tiene un revisor automático (Bugbot) que comenta las pull requests en GitHub señalando fallos y problemas de seguridad. Es la herramienta con la que se puede llegar más lejos, incluida una app nativa publicada.

El precio es otro: no te da servidor, base de datos, hosting ni tiendas. Y hace lo que le pides. Si no le pides tests de permisos, no los hay. Si no sabes que Google Play vuelve a firmar tu app y que el login con Google necesita esa huella, Cursor tampoco te lo va a recordar. Multiplica a quien ya sabe; a quien no sabe, le deja avanzar más rápido hacia el mismo muro.

Lo que ninguna te pone sola

Cambia la herramienta, no cambia la lista. Esto es lo que revisamos en cualquier proyecto antes de dejarlo entrar a producción:

• Permisos escritos y probados: con la clave pública y sin sesión, una consulta a datos ajenos vuelve vacía. Con sesión de otro usuario, también.
• Secretos solo en el servidor, y rotados si alguna vez estuvieron en el navegador.
• Tests de lo que te cuesta clientes: registro, login, pago, permisos. En el repositorio y ejecutándose en cada cambio.
• Informe de errores (Crashlytics, Sentry o similar) para enterarte antes que tu usuario.
• Móvil: build de release probada en un teléfono real, firma y huellas registradas, y en Google Play con cuenta personal, la prueba cerrada de 12 testers durante 14 días.