# Lovable: qué es, qué resuelve de verdad y hasta dónde llega antes de ser un producto > Qué es Lovable, qué construye realmente con IA y dónde está su límite: datos, permisos, pagos, dominio, copias y costes antes de llamarlo producto. - URL: https://fcgsystems.es/blog/lovable-que-es-y-hasta-donde-llega/ - Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/) - Publicado: 2026-09-16 (16 de septiembre de 2026) - Tema: Software · Formato: Breakdown · Lectura: 10 min - Palabra clave: lovable que es (también: que es lovable, lovable español, para que sirve lovable, como funciona lovable, lovable opiniones, lovable es gratis, lovable ai) **Lovable es una plataforma que construye aplicaciones web a partir de instrucciones escritas en lenguaje natural.** Su propia documentación la describe como una plataforma de desarrollo full-stack con IA que genera frontend, backend, base de datos, autenticación e integraciones, con código editable detrás. Sirve para tener una primera versión funcionando en horas. No sirve, por sí sola, para tener un producto. Esa distinción es todo el artículo. Lovable hace muy bien una parte del trabajo, y esa parte antes costaba semanas. El problema aparece cuando se confunde "ya se ve y se puede pinchar" con "ya se puede cobrar por esto". Aquí va qué es, qué genera por debajo, dónde está su techo y qué hay que montar después para que aquello sea un producto y no una demo con dominio propio. ## ¿Qué es Lovable y cómo funciona? Escribes lo que quieres. Lovable genera la aplicación, la enseña en una vista previa y la itera contigo en el mismo chat. Según su [documentación de introducción](https://docs.lovable.dev/introduction) (consultada en septiembre de 2026), cada proyecto "produce un código que se puede sincronizar con GitHub, GitLab o Bitbucket" y se puede publicar en una URL. Tres piezas conviene entender desde el principio, porque son las que marcan hasta dónde llega: - **El código es real y es tuyo.** La documentación sobre [despliegue, hosting y propiedad del código](https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership) (consultada en septiembre de 2026) lo dice sin rodeos: "You own your code". Las aplicaciones son proyectos estándar de Vite y React que puedes clonar, modificar fuera de la plataforma y desplegar en AWS, GCP, Azure, Netlify, Cloudflare Pages, Vercel o tu propio servidor. - **Hay un backend incluido.** Lo llaman [Cloud](https://docs.lovable.dev/features/cloud) (consultada en septiembre de 2026): base de datos, almacenamiento, autenticación, tiempo real y funciones, sin montar infraestructura. Está construido sobre la base open source de Supabase, y quien ya tenía su propio proyecto de Supabase conectado puede seguir usándolo. - **Se sincroniza con Git en las dos direcciones.** Según su [integración con GitHub](https://docs.lovable.dev/integrations/github) (consultada en septiembre de 2026), lo que cambias en Lovable llega al repositorio y lo que empujas a la rama sincronizada vuelve a Lovable. El repositorio es privado por defecto y sigue siendo tuyo aunque desconectes la integración. Un detalle importante: Lovable sincroniza una sola rama a la vez. Esa última pieza es la que más se ignora y la que más cambia el escenario. Significa que un equipo técnico puede entrar a trabajar sobre lo generado sin empezar de cero. Es un buen diseño, y hay que decirlo. ## ¿Para qué sirve Lovable de verdad? Sin humo, esto es lo que resuelve bien: - **La primera versión.** Pasar de una idea a algo que se ve, se navega y se enseña. Eso antes se pagaba en semanas de maquetación y ahora sale en una tarde. - **La conversación con un cliente o un socio.** Enseñar una pantalla real cambia una reunión entera. La gente opina sobre lo que ve, no sobre lo que imagina. - **El descarte barato.** Tres ideas prototipadas y dos muertas en una semana es una buena semana. Ahí Lovable gana solo. - **Herramientas internas de bajo riesgo.** Un panel para el equipo, un formulario con lógica, una calculadora de presupuestos. Poco dato sensible, poco tráfico, poco que perder. - **El arranque de un proyecto que luego seguirá un equipo técnico.** Gracias a la sincronización con Git, lo generado es un punto de partida, no un callejón. El resto de este artículo no va contra Lovable. Va contra la idea de que con eso ya está. ## ¿Qué hay que montar después para que sea un producto? Aquí está la parte que ningún generador resuelve por ti, porque no son pantallas: son decisiones con consecuencias. ### 1. Los datos Una aplicación generada crea tablas a partir de tu descripción. Funciona en la demo porque los datos son tres filas que has metido tú. Con datos reales aparece lo de siempre: el mismo cliente dado de alta dos veces con dos correos distintos, un pedido sin cliente asociado, un campo de texto libre donde debería haber una lista cerrada. Lo que hay que resolver antes de que entre gente de verdad: claves únicas donde toca, relaciones con integridad, qué pasa cuando se borra algo que otra tabla usa, y qué dato es el bueno cuando dos sistemas discrepan. Esto es diseño de modelo de datos, y arreglarlo con la base ya llena cuesta mucho más que hacerlo antes. ### 2. Los permisos Este es el punto de fallo número uno, y no lo decimos nosotros. La [documentación de la integración con Supabase](https://docs.lovable.dev/integrations/supabase) (consultada en septiembre de 2026) avisa: antes de publicar, asegúrate de que cada tabla tiene políticas de Row Level Security que restrinjan quién lee y quién escribe cada fila, y verifícalas tú en el panel de Supabase, porque "la falta de políticas RLS es la forma más habitual de que los datos de una aplicación queden expuestos". Su [página de seguridad](https://docs.lovable.dev/features/security) (consultada en septiembre de 2026) es igual de clara sobre el escaneo automático que incluye la plataforma: ayuda a detectar problemas comunes, pero "no puede garantizar una seguridad completa" y "no sustituye una revisión de seguridad a fondo". Y remata: eres tú el responsable de que tu aplicación cumpla los requisitos de seguridad que le correspondan. Traducido: la herramienta te avisa, pero la responsabilidad no se delega. Un panel donde cualquier usuario autenticado puede consultar las filas de todos los demás es un incidente esperando fecha. Cómo se revisa esto está en la guía sobre [revisar código generado por IA](https://fcgsystems.es/blog/revisar-codigo-generado-por-ia/). ### 3. Los pagos Cobrar no es poner un botón. Es qué ocurre cuando la tarjeta se rechaza al tercer mes, cuando el webhook llega dos veces, cuando llega tarde, cuando no llega, cuando el usuario paga y el acceso no se activa, y cuando alguien pide la baja. Nada de eso se ve en una demo, porque en una demo el pago siempre sale bien. Ese es exactamente el agujero que describimos en [pagos fallidos de Stripe y accesos que no se cortan](https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/): dinero que se escapa cada mes sin que nadie lo vea. Hace falta conciliación entre lo que dice la pasarela y lo que dice tu base de datos, y una alerta con responsable cuando no cuadran. ### 4. El dominio y la publicación Publicar en Lovable es inmediato, pero el dominio propio tiene condiciones. Según su [documentación de dominios personalizados](https://docs.lovable.dev/features/custom-domain) (consultada en septiembre de 2026), los dominios propios están disponibles en los planes de pago, la plataforma registra el dominio, configura los DNS y el SSL por ti, y el dominio no sirve contenido hasta que publicas el proyecto. La pregunta que hay que hacerse no es si se puede conectar el dominio. Es dónde quieres que viva esto dentro de un año: en la plataforma, o en tu propia infraestructura con tu propio despliegue. Las dos opciones son legítimas. La mala es no haberla decidido. ### 5. Las copias de seguridad y la vuelta atrás Lovable guarda historial de versiones del proyecto. Eso te cubre el código. No te cubre los datos de tus clientes. Preguntas que conviene poder responder antes de tener usuarios: ¿dónde está la copia de la base de datos de ayer?, ¿cuánto se tarda en restaurarla?, ¿alguien ha probado a restaurarla alguna vez? Una copia que nunca se ha restaurado no es una copia, es una carpeta. Y si la aplicación acaba viviendo fuera de la plataforma, esto pasa a ser tuyo entero. ### 6. Los costes Aquí hay que mirar el modelo de cobro, no el precio de entrada. Según la [documentación de planes de Lovable](https://docs.lovable.dev/introduction/subscription-plans) (consultada en septiembre de 2026): - El plan **Free** da 5 créditos de construcción al día con un tope de 30 al mes, más 20 créditos de Cloud mensuales. El editor de código es de solo lectura en este plan, según su [documentación del editor](https://docs.lovable.dev/features/code-mode) (consultada en septiembre de 2026). - El plan **Pro** arranca en 25 dólares al mes por 100 créditos y escala por tramos según los créditos que necesites. - El plan **Business** arranca en 50 dólares al mes por 100 créditos, con sus propios tramos. Los créditos se gastan construyendo, y construir incluye equivocarse. Cada iteración para arreglar algo que salió torcido consume. Por eso el coste real no se estima con el precio del plan, sino con cuántas vueltas vas a dar. Y ojo con el otro coste: el backend incluido tiene su propio consumo, y una aplicación con tráfico real no consume como una demo. ## Qué te da Lovable y qué tienes que montar tú | Pieza | Lovable | Lo que sigue siendo tuyo | |---|---|---| | Interfaz y navegación | La genera completa y editable | Accesibilidad, estados de error, comportamiento en móvil real | | Base de datos | Crea tablas y relaciones desde una descripción | Modelo correcto, claves únicas, integridad, migraciones con datos vivos | | Autenticación | Registro y login conectados | Roles, qué ve cada perfil, recuperación de cuenta | | Permisos de datos | Avisa y hace linting de políticas RLS | Definir y verificar cada política antes de publicar | | Pagos | Integra la pasarela | Webhooks idempotentes, conciliación, impagos, bajas | | Publicación | URL y dominio propio en planes de pago | Decidir dónde vive el sistema a medio plazo | | Código | Vite + React, sincronizado con Git | Revisión, pruebas de lo crítico, despliegue reproducible | | Copias de seguridad | Historial de versiones del código | Copias de datos, restauración probada | | Fallos | Corrige errores que detecta al construir | Saber qué se rompió en producción y avisar a alguien | La columna de la derecha no es un reproche a la herramienta. Es el trabajo que siempre ha existido y que ninguna herramienta de generación ha prometido nunca hacer. ## Errores comunes con Lovable - **Confundir la demo con el producto.** El demo funciona con tres filas y un usuario: tú. Producción son datos sucios, usuarios con prisa y fallos de red. - **Publicar sin revisar las políticas de permisos.** Lo avisa la propia documentación. Se sigue haciendo. - **Meter claves de API en el chat o en el código.** Lovable detecta claves pegadas en el chat y te guía para guardarlas en su almacén de credenciales ("Secrets"), según su página de seguridad. Aprovéchalo en vez de esquivarlo. - **No mirar el consumo hasta que llega la factura.** El coste no está en el plan, está en las iteraciones y en el tráfico real. - **Seguir pidiendo cambios cuando el problema es de arquitectura.** Si llevas quince vueltas sobre lo mismo, no necesitas otro prompt: necesitas decidir cómo debería estar montado. - **No sincronizar con Git desde el principio.** Es la vía de salida y el punto de entrada de cualquiera que venga a ayudarte. Conectarla tarde cuesta trabajo. - **Prometerle a un cliente una fecha basándose en lo que tardó el prototipo.** Ese error cuesta dinero y reputación; lo desarrollamos en [prototipos con IA para clientes de agencia](https://fcgsystems.es/blog/prototipo-con-ia-para-clientes-de-agencia/). ## Checklist antes de llamarlo producto - ¿Cada tabla tiene políticas de permisos y las has verificado tú, una a una? - ¿Hay claves únicas que impidan duplicar clientes, pedidos o inscripciones? - ¿Qué pasa si el mismo webhook de pago llega dos veces? - ¿Sabrías decir hoy qué pagos de este mes no cuadran con los accesos concedidos? - ¿Dónde está la copia de la base de datos y quién la ha restaurado alguna vez? - ¿Si algo se rompe un domingo, quién se entera y cómo? - ¿Hay datos personales? ¿Quién puede verlos y con qué base legal? - ¿El proyecto está en un repositorio propio al que tiene acceso alguien más que tú? - ¿Sabes cuánto costará esto al mes con diez veces el tráfico de hoy? Si hay más de tres noes, todavía no es un producto. Es un prototipo con buena pinta, que ya es mucho, pero no es lo mismo. ## ¿Entonces Lovable sirve o no? Sirve, y bastante. Para validar una idea, para enseñar algo tangible, para herramientas internas y para arrancar un proyecto que después seguirá un equipo. Y el hecho de que el código salga en un repositorio estándar de Vite y React lo separa de las herramientas que te encierran dentro. Lo que no hace es tomar las decisiones que convierten un programa en un negocio: qué dato es la verdad, quién puede ver qué, qué ocurre cuando falla el cobro, qué se hace cuando el servidor se cae un domingo. Eso no es un fallo de la herramienta. Es que ese trabajo nunca fue el de escribir pantallas. Construir sin entender es fracaso con buena pinta. Y la parte que hay que entender es justo la que no se ve en la vista previa. Si lo que quieres es entender la categoría entera antes que la herramienta, empieza por [qué es el vibe coding](https://fcgsystems.es/blog/que-es-vibe-coding/). Si quieres la comparación con las otras opciones, está en [Lovable vs Bolt vs v0](https://fcgsystems.es/blog/lovable-vs-bolt-vs-v0/). Si lo que tienes ya es un prototipo y la pregunta es cómo llevarlo a producción, el recorrido completo está en [de prototipo con IA a producción](https://fcgsystems.es/blog/de-prototipo-ia-a-produccion/). Y si vienes del no-code, las señales de cuándo toca dar el salto están en [de no-code a software a medida](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/). ## Qué hacemos nosotros con esto En FCG Systems no venimos a decirte que tires el prototipo. Al revés: si ya tienes algo hecho en Lovable, tienes recorrido ganado y decisiones tomadas. Lo que hacemos es coger ese proyecto, revisar permisos y modelo de datos, montar el backend que aguante, cerrar los pagos y dejarlo desplegado con copias, alertas y quien responda cuando falla. Es el servicio de [software a medida](https://fcgsystems.es/servicios/software-a-medida/), y cuando el acompañamiento es continuo, el de [partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/). Para agencias lo hacemos también en marca blanca. Si tienes un prototipo y no sabes qué le falta para poder cobrarlo, [cuéntamelo](https://fcgsystems.es/contacto/) y te digo qué hay que tocar y en qué orden. ## Preguntas frecuentes ### ¿Qué es Lovable exactamente? Lovable es una plataforma que construye aplicaciones web a partir de instrucciones escritas en lenguaje natural. Su documentación la define como una plataforma de desarrollo full-stack con IA que genera frontend, backend, base de datos, autenticación e integraciones, todo respaldado por código editable. No es un maquetador de pantallas: produce un proyecto de código real. ### ¿Lovable es gratis? Hay un plan gratuito, pero está pensado para probar. Según su documentación de planes (consultada en septiembre de 2026), el plan Free da 5 créditos de construcción al día con un tope de 30 al mes, el editor de código es de solo lectura y los dominios propios están reservados a los planes de pago. Para sostener un proyecto en marcha hay que pasar a un plan de pago. ### ¿Puedo sacar el código que genera Lovable? Sí. Su documentación afirma literalmente "You own your code" y que los proyectos se pueden sincronizar con un repositorio de Git, clonar, modificar fuera de Lovable y desplegar en tu propia infraestructura. Las aplicaciones son proyectos estándar de Vite y React. Que puedas sacarlo no significa que esté listo para producción: eso lo decide una revisión, no la exportación. ### ¿Se puede lanzar un negocio real con una aplicación hecha en Lovable? Depende de qué maneje. Si es una herramienta interna, una lista de espera o un panel sin datos sensibles, puede aguantar. Si cobra dinero, guarda datos personales o da acceso a un contenido pagado, antes hay que resolver permisos a nivel de base de datos, conciliación de pagos, copias de seguridad y alertas cuando algo falla. ### ¿Qué es lo que más se rompe al llevar un proyecto de Lovable a producción? Los permisos de base de datos. La propia documentación de Lovable avisa de que las políticas de Row Level Security mal configuradas son la causa más habitual de fuga de datos y pide verificarlas en el panel de Supabase antes de publicar. Después vienen los pagos sin conciliar y la ausencia de alertas: el sistema falla y nadie se entera. ## Servicios relacionados - [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial. - [Partner tecnológico](https://fcgsystems.es/servicios/partner-tecnologico/): Tu equipo técnico externo: mantenimiento, incidencias y nuevos sistemas con capacidad mensual definida. ## Contacto Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable.