Lovable vs Bolt vs v0: comparativa honesta por criterios de uso real

Lovable, Bolt y v0 hacen lo mismo de cerca y cosas distintas de lejos: las tres convierten instrucciones escritas en una aplicación web que funciona. La diferencia que importa no es cuál genera pantallas más bonitas, sino qué control te deja sobre el código, qué backend trae puesto y qué pasa el día que tu equipo tiene que seguir trabajando fuera de la herramienta.

Esta comparativa está hecha desde ese ángulo. No hay ganadora. Hay tres herramientas buenas para escenarios distintos, y un cuarto escenario donde ninguna es la respuesta.

Tabla comparativa

Todas las filas salen de la documentación oficial de cada herramienta, enlazada más abajo, consultada en septiembre de 2026. Los precios cambian a menudo: aquí se describe el modelo de cobro, no la tarifa del mes.

Lovable: la aplicación entera desde la conversación

Su documentación (consultada en septiembre de 2026) la define como una plataforma de desarrollo full-stack con IA para construir, iterar y desplegar aplicaciones web en lenguaje natural, con código real detrás. Genera frontend, backend, base de datos, autenticación e integraciones en el mismo sitio.

Qué genera. Proyectos estándar de Vite y React. Lo dice su guía de despliegue y propiedad del código (consultada en septiembre de 2026), que además afirma “You own your code” y que puedes clonar el repositorio, modificarlo fuera y desplegarlo en tu infraestructura o autoalojarlo sin restricciones.

Qué control te deja. Bastante, con un matiz de plan: según su documentación del editor de código (consultada en septiembre de 2026), editar código está disponible en los planes de pago y en el plan gratuito el editor es de solo lectura. La sincronización con Git es bidireccional pero de una rama cada vez, según su integración con GitHub (consultada en septiembre de 2026).

Qué pasa al exportar. Sales con un proyecto que cualquier equipo de frontend reconoce. Eso es mucho. Lo que no sale revisado son los permisos: su propia documentación de Supabase (consultada en septiembre de 2026) avisa de que la falta de políticas de Row Level Security es la forma más habitual de exponer los datos de una aplicación, y pide verificarlas a mano antes de publicar.

Para quién. Quien quiere una aplicación con usuarios, datos y login sin montar un backend, y quiere poder llevársela después. El detalle completo, en qué es Lovable y hasta dónde llega.

Bolt: el proyecto de ficheros, con ramas

Su centro de ayuda (consultado en septiembre de 2026) lo presenta como una herramienta de IA que convierte ideas en webs y aplicaciones reales, y menciona webs de marketing, portfolios, tiendas, paneles, herramientas internas y presentaciones.

Qué genera. Aquí hay una restricción que conviene conocer antes de empezar, no después. Su página de tecnologías soportadas (consultada en septiembre de 2026) dice que Bolt se centra en tecnologías web basadas en JavaScript, con Node.js en el backend, y que “Bolt solo admite backends en JavaScript, así que lenguajes como PHP o Python no son compatibles”. Si tu equipo trabaja en Python o si el proyecto va a tirar de librerías que no existen en Node, Bolt queda fuera por diseño.

Qué control te deja. Es donde mejor está. Según su integración con GitHub (consultada en septiembre de 2026), Bolt crea un commit cada vez que haces un cambio que no rompe el proyecto y comprueba GitHub cada 30 segundos para traerse lo que se haya hecho fuera. Admite ramas, cada una con su propia memoria. Dos avisos de la misma página: las fusiones de ramas hay que hacerlas en GitHub, no dentro de Bolt, y si hay cambios simultáneos, Bolt conserva los suyos y sobrescribe la versión de GitHub. Esa última línea merece un subrayado si vais a ser dos personas tocando lo mismo.

Qué pasa al exportar. Como hay repositorio desde el minuto uno, no hay momento de exportación: hay un repositorio que ya existe. Es el flujo más cómodo de los tres para un equipo técnico que entra a mitad.

El coste. Bolt cobra por tokens, y según su documentación de tokens (consultada en septiembre de 2026) la mayor parte del consumo viene de que Bolt lea, entienda y sincronice los ficheros de tu proyecto, así que los proyectos grandes consumen más por mensaje. El plan gratuito incluye un millón de tokens al mes con un tope diario de 300.000 que no se acumula. Traducido a decisiones: un proyecto que crece consume más por cada cosa que le pides, aunque le pidas lo mismo.

v0: el camino corto hacia Next.js y Vercel

Su documentación (consultada en septiembre de 2026) lo describe como un agente de IA que ayuda a crear código real y aplicaciones full-stack, y menciona Next.js, Tailwind y componentes shadcn/ui.

Qué genera. Código dentro del ecosistema de Vercel. Si tu producto va a vivir ahí, eso no es una limitación: es que ya estás en casa.

Qué control te deja. La misma documentación señala que puedes desplegar a producción de inmediato o abrir una pull request para revisión. Esa segunda opción es la interesante: mete lo generado en un flujo de revisión normal, con alguien mirando el diff antes de que llegue a producción. Es la forma sana de trabajar con código generado, y viene de serie.

Qué pasa al exportar. Poco drama, porque el destino es un stack muy estándar. El riesgo aquí no es técnico, es de encaje: si el cliente tiene su infraestructura en otro sitio, empezar por v0 orienta el proyecto hacia Vercel desde el primer día.

El coste. Funciona por créditos incluidos según plan, con un nivel gratuito. Las cifras exactas cambian con frecuencia y conviene mirarlas en su página de precios antes de comprometer un presupuesto; no las reproducimos aquí para no dar un número caducado.

El resto del mapa: Figma Make, Replit Agent y Cursor

No son las mismas herramientas, pero salen en la misma conversación.

Figma Make. Su página oficial (consultada en septiembre de 2026) lo resume como “prompt to code”: lo que construyes está respaldado por código y es editable visualmente, y puedes saltar entre código y lienzo. Se apoya en tu contexto de diseño, con “Make kits” que sincronizan paquetes npm, estilos de librería y guías con Figma. Encaja cuando el equipo de diseño ya vive en Figma y el prototipo tiene que respetar un sistema de diseño existente. Ojo: la propia página marca como “coming soon” el uso local sobre cualquier base de código, así que conviene comprobar el estado de esa pieza antes de planificar con ella.

Replit Agent. Según su documentación (consultada en septiembre de 2026), convierte descripciones en lenguaje natural en aplicaciones funcionales, cubre planificación, desarrollo, pruebas y despliegue, y mantiene puntos de control para volver a un estado anterior. Construye y despliega dentro de Replit. Encaja cuando quieres que el entorno de desarrollo y el de ejecución sean el mismo sitio y no quieres tocar infraestructura.

Cursor. Aquí hay un malentendido frecuente. Su documentación (consultada en septiembre de 2026) lo define como un agente de programación para construir software ambicioso, que sirve para entender un repositorio, planificar y construir funcionalidades, corregir errores y revisar cambios. No es un generador de aplicaciones desde un prompt en blanco: es la herramienta con la que se trabaja sobre un repositorio que ya existe. Por eso no está en la tabla. En un proyecto real, las dos fases conviven: una de estas plataformas para la primera versión, y un entorno como Cursor para el trabajo posterior. Esa forma de trabajar tiene nombre propio y su propio manual de instrucciones: está en qué es el vibe coding.

Cuándo ninguna de las tres es la respuesta

Hay cuatro situaciones en las que empezar por aquí es empezar torcido:

• Hay dinero de por medio con reglas propias. Comisiones, prorrateos, descuentos por tramos, recobros. La lógica determinista se escribe, se prueba y se audita. Un modelo que “casi siempre” calcula bien una comisión no es una implementación, es un riesgo con interfaz.
• Hay datos personales sensibles o requisitos de cumplimiento. Salud, menores, datos financieros. Aquí la primera pregunta no es qué herramienta, sino quién puede ver qué y qué se registra.
• El sistema tiene que integrarse con lo que ya existe. Un ERP, un CRM con años de datos, una pasarela con su propia lógica de suscripciones. El prototipo no conoce esas reglas y el coste está justo ahí.
• El backend no puede ser JavaScript. Con Bolt es una incompatibilidad declarada. Con las otras, es una fricción que aparece más tarde.

En esos casos el prototipo sigue siendo útil, pero para otra cosa: para acordar la interfaz y el recorrido del usuario. El motor se construye aparte. Las señales de cuándo toca ese salto están en de no-code a software a medida.

Errores comunes al elegir

• Elegir por la demo de la web. Todas enseñan el caso que mejor les sale. Prueba tu caso, con tus datos y tus integraciones, antes de decidir.
• No mirar dónde acaba el proyecto. La pregunta buena es dónde vivirá dentro de un año y quién lo mantendrá. Eso descarta o confirma más que cualquier tabla.
• Ignorar el modelo de cobro. Créditos y tokens no se consumen construyendo bien: se consumen sobre todo iterando. Cuanto más crece el proyecto, más cuesta cada petición.
• Confundir “el código es tuyo” con “el código está listo”. Sacarlo es un derecho, no una revisión. Lo que hay que mirar está en revisar código generado por IA.
• Mezclar dos herramientas en el mismo proyecto sin criterio. Cada una impone su estructura. Convivir es posible; hacerlo sin decidirlo, no.
• Publicar sin revisar permisos. Aplica a las tres, aunque solo una lo avise de forma tan explícita en su documentación.

Checklist para decidir en diez minutos

• ¿El backend puede ser JavaScript? Si no, Bolt queda fuera por su propia documentación.
• ¿Dónde se va a desplegar esto en producción y quién lo va a mantener?
• ¿Va a tocar código alguien más que tú? Si sí, mira primero cómo funciona la integración con Git de cada una.
• ¿El proyecto tiene que respetar un sistema de diseño ya existente? Ahí Figma Make parte con ventaja.
• ¿Cuánto vas a iterar? Multiplica por dos y mira el modelo de cobro con ese número.
• ¿Hay datos personales o dinero? Entonces la decisión no es de herramienta, es de arquitectura.
• ¿Podrías llevarte el proyecto mañana a otro sitio? Comprueba la vía de salida antes de empezar, no cuando la necesites.

Y después de elegir, lo de siempre

La elección de herramienta ocupa una tarde. Lo que ocupa el resto es lo mismo con las tres: modelo de datos que aguante, permisos verificados, pagos conciliados, copias de seguridad probadas y alguien que se entere cuando algo se rompe. Esa parte no la decide la comparativa.

En FCG Systems cogemos ese prototipo, venga de donde venga, y lo convertimos en un sistema que se puede cobrar y mantener: software a medida cuando es un proyecto cerrado, y partner tecnológico cuando lo que hace falta es alguien detrás mes a mes. Para agencias, también en marca blanca.

El recorrido completo del prototipo a producción está en de prototipo con IA a producción, y la forma de trabajar con esto delante de un cliente, en prototipos con IA para clientes de agencia. Si ya has elegido y quieres una segunda opinión antes de comprometer un presupuesto, cuéntame el caso.