Qué es Lovable y qué produce
Lovable es una plataforma de desarrollo de aplicaciones web mediante instrucciones en lenguaje natural. El resultado puede incluir interfaz, lógica de servidor, base de datos, autenticación e integraciones, con código editable. Un proyecto representa una aplicación; el espacio de trabajo reúne personas, proyectos y recursos compartidos.
Su unidad de trabajo es un comportamiento que se puede probar: buscar un recurso, guardar una reserva o mostrar datos autorizados. Una pantalla atractiva es solo una parte del resultado. Para valorar una aplicación conviene seguir la información desde su entrada hasta su almacenamiento y comprobar qué sucede cuando falta un dato, cambia un permiso o falla un servicio.
Documentación de referencia: Welcome to Lovable.
Origen y evolución del producto
El antecedente es GPT Engineer, proyecto abierto que Anton Osika publicó en primavera de 2023. Osika y Fabian Hedin desarrollaron posteriormente Lovable, cuyo lanzamiento bajo esa marca se sitúa en noviembre de 2024 según la empresa. Ambos fundadores recibieron el KTH Innovation Award de 2025.
La evolución explica su enfoque: pasar de generar archivos a acompañar la construcción y operación de una aplicación. El proyecto abierto inicial, el servicio comercial y el código de una aplicación creada por un cliente son objetos diferentes; la existencia del primero no convierte toda la plataforma actual en software abierto.
Documentación de referencia: Engineering history · Series C announcement · KTH Innovation Award.
Empresa y financiación
Los anuncios corporativos documentan tres rondas relevantes: el 17 de julio de 2025, 200 millones de dólares con valoración de 1.800 millones, liderados por Accel; el 18 de diciembre de 2025, 330 millones y valoración de 6.600 millones, con CapitalG y Menlo Ventures; y el 12 de agosto de 2026, 400 millones y valoración de 13.300 millones, liderados por Menlo Ventures y el Scaleup Europe Fund.
Estas cifras describen financiación privada en fechas concretas. Ayudan a entender la expansión de la empresa y su infraestructura, pero no equivalen a facturación, beneficio ni un precio disponible para comprar sus acciones.
Documentación de referencia: Series A announcement · Series B announcement · Series C announcement.
Tecnología y estructura de las aplicaciones
Lovable describe una evolución técnica basada en entornos de ejecución persistentes y recuperación de instrucciones relevantes para el agente. No se reduce a un único modelo conversacional. Desde el 13 de mayo de 2026 los proyectos nuevos usan TanStack Start; para Enterprise, desde el 22 de junio. Los anteriores pueden utilizar React y Vite y tienen una vía de actualización.
TanStack Start renderiza páginas en el servidor. Esa diferencia importa al revisar el HTML que recibe un visitante o un rastreador y al elegir alojamiento externo. La migración debe comprobar rutas, autenticación y metadatos. El cambio preparado en el proyecto no se sirve al público hasta volver a publicar.
Documentación de referencia: Engineering history · TanStack Start upgrade.
Conversación, planificación y construcción
Chat permite discutir; Plan investiga y presenta una propuesta editable sin cambiar código; Build, antes llamado Agent, ejecuta modificaciones y muestra sus diferencias. Las instrucciones persistentes del espacio de trabajo y del proyecto, antes denominadas Knowledge, aportan contexto. Las Skills se cargan cuando resulta pertinente.
Una especificación útil define usuarios, información permitida, estados, errores y criterios de aceptación. Para un catálogo multilingüe, por ejemplo, conviene decidir si cada idioma comparte identificador, qué sucede cuando falta una traducción y quién puede retirar una entrada. Esas decisiones deben preceder a instrucciones visuales como colores o distribución.
Documentación de referencia: Build mode · Plan mode · Instructions.
Edición visual y precisión de los cambios
La barra de la vista previa sustituye a la experiencia anterior Visual edits. Permite seleccionar elementos, modificar texto en línea, dibujar anotaciones y añadir comentarios. Seleccionar una tarjeta aporta contexto al agente; un comentario puede servir para revisión sin describir su posición en otra conversación.
Para conservar coherencia, se puede pedir una corrección pequeña y comprobar varias pantallas: un título traducido puede ocupar dos líneas, un botón puede perder su etiqueta o un cambio de componente repetirse en todo el sitio. Revisar el resultado con teclado, ampliación de texto y contenidos largos aporta evidencia más útil que aprobar únicamente una captura.
Documentación de referencia: Preview toolbar.
Datos, autenticación y permisos del agente
El backend integrado, también llamado Cloud, parte de la tecnología abierta de Supabase e incluye base de datos, almacenamiento, autenticación y funciones. Los permisos del agente distinguen leer, cambiar datos y modificar estructura. En la documentación consultada, las migraciones incompatibles están bloqueadas por defecto, mientras otras operaciones están permitidas.
Conviene separar tres preguntas: quién modifica el código, quién entra en la aplicación y qué registros puede consultar cada persona. Tener una cuenta no concede acceso a todas las filas. Asimismo, cambiar un texto en desarrollo y cambiar un registro almacenado son acciones diferentes: una revisión editorial del sitio no sustituye el control de sus datos.
Documentación de referencia: Built-in backend.
Pruebas de comportamiento y seguridad
Las pruebas de navegador se ejecutan sobre la vista previa en un entorno remoto. Pueden recorrer formularios y tamaños de pantalla, pero tienen límites con lienzos, arrastres y detalles visuales; la autenticación externa también limita lo comprobable. Quick scan revisa controles concretos al publicar; Deep scan analiza problemas de lógica, autorización y exposición en el código.
Una prueba eficaz especifica resultado esperado y resultado prohibido. Por ejemplo, el lector puede abrir una ficha publicada, pero no recuperarla mediante su URL después de retirarla si el contenido debe dejar de estar disponible. Deben ensayarse ambos casos y guardar qué versión, cuenta y datos se usaron. Un escáner y una prueba funcional responden preguntas diferentes.
Documentación de referencia: Browser testing · Security overview.
Publicación y versiones visibles
Publicar despliega una instantánea en una URL; los cambios posteriores requieren volver a publicar. Los permisos del editor y del sitio público son independientes.
Para una biblioteca de recursos, la verificación debe hacerse desde la dirección pública y con una sesión equivalente a la del destinatario. Hay que abrir enlaces profundos, recargar una página interior y comprobar que el idioma elegido sigue siendo correcto. La confirmación de despliegue acredita una operación técnica; la revisión del contenido confirma qué recibe el público.
Documentación de referencia: Publish your Lovable project.
Propiedad, Git y salida de la plataforma
Lovable documenta propiedad del código y contenido creado, sujeta a derechos de terceros. La sincronización Git permite mantener una copia del código y colaborar con desarrolladores; GitHub no es obligatorio para utilizar el servicio. Trasladar una aplicación completa requiere considerar por separado interfaz, datos, autenticación, almacenamiento e integraciones.
Un ensayo de portabilidad consiste en arrancar una copia, importar datos ficticios y comprobar el acceso a archivos y servicios. Si solo se ha exportado el repositorio, no debe darse por preservado todo el sistema. El inventario de dependencias debe incluir también credenciales, configuración del dominio y tareas periódicas, con responsables para mantenerlas.
Documentación de referencia: Sync project with GitHub · Ownership and portability.
Web, escritorio y móvil
Además del navegador, Lovable ofrece aplicaciones de escritorio para macOS y Windows, y móviles para iOS y Android. La aplicación de escritorio añade conexión con servidores MCP locales. La móvil permite continuar proyectos con la misma cuenta y créditos.
Estas aplicaciones son superficies para construir. El proyecto creado se publica como web: Lovable no genera React Native ni incorpora un trámite directo de envío a las tiendas. Una PWA o una envoltura externa son opciones diferentes que requieren trabajo adicional. Para recursos de prevención consultados desde teléfonos, conviene comprobar conectividad, tamaño táctil, descarga de documentos y recuperación después de perder la sesión.
Documentación de referencia: Desktop app · Mobile app · Publish your Lovable project.
Planes, consumo y tratamiento de datos
Los planes son Free, Pro, Business y Enterprise. Un mismo saldo de créditos cubre construcción, conversación, alojamiento, backend e IA de la aplicación. El coste de mantener una web depende también de su uso, no solo de cuántas instrucciones se envíen para crearla.
Desde el 9 de septiembre de 2026, Free y Pro pueden aportar contenido al entrenamiento, con exclusión individual configurable y prospectiva. Business y Enterprise están excluidos por defecto. La documentación distingue ese contenido de los datos que introducen los usuarios finales de las aplicaciones, que no se utilizan para entrenar.
Al presupuestar un proyecto se pueden separar tres escenarios propios: preparación, tráfico habitual y una campaña con más visitas. Así se identifica quién observa el consumo y qué límites deben aplicarse antes de compartir la dirección ampliamente.
Documentación de referencia: Subscription plans · Credits and usage · Data training controls.
Incidentes documentados y aprendizaje
El registro CVE-2025-48757 describe políticas RLS insuficientes en sitios generados hasta el 15 de abril de 2025. Incluye la controversia del proveedor, que señala la responsabilidad del cliente sobre sus datos. No permite concluir que todas las aplicaciones actuales presenten ese fallo.
Separadamente, Lovable reconoció una regresión que permitió acceder a código y conversaciones de proyectos públicos entre el 3 de febrero y el 20 de abril de 2026. Comunicó su corrección y excluyó del alcance proyectos privados y Cloud. El incidente refuerza la necesidad de distinguir visibilidad del editor y acceso a la aplicación.
Documentación de referencia: CVE-2025-48757 record · April 2026 incident response.
Aplicaciones concretas en SST
Puede ayudar a explorar cómo presentar recursos preventivos, organizar materiales o simplificar una consulta interna. Su relación con SST es de apoyo al diseño y al desarrollo: permite probar una idea con rapidez, pero el contenido, los permisos y los criterios de funcionamiento deben definirse y revisarse fuera de las suposiciones del generador.
Otros usos propuestos son una página de bienvenida que explique dónde encontrar recursos y una demostración de consulta de materiales por centro. En ambos conviene separar contenido público de contenido interno desde el diseño. Una etiqueta «interno» o un botón oculto no constituyen permisos: la persona que solicita un recurso debe estar autorizada también cuando accede directamente a su dirección.
Caso práctico y comprobación del resultado
Por ejemplo, se podría prototipar un portal que agrupe materiales aprobados por idioma y temática, usando enlaces públicos. El equipo comprobaría la búsqueda y la legibilidad antes de decidir si merece convertirse en una herramienta mantenida.
En el portal del ejemplo, define cada material mediante título, idioma, tema, fecha de revisión y enlace autorizado. Prepara un conjunto pequeño con duplicados controlados y un documento retirado para comprobar cómo se muestran esos estados. Describe una regla explícita: el buscador ofrece materiales vigentes y explica si una versión ya no está disponible.
Prueba la búsqueda en los tres idiomas y verifica que el filtro no cambia inadvertidamente la lengua del documento. Después introduce una corrección de título y comprueba su efecto en lista y detalle. Si se añaden cuentas, utiliza dos identidades ficticias con permisos diferentes y verifica el acceso efectivo a los datos, no solo a los botones. La revisión final debe identificar la versión probada y la audiencia prevista antes de publicar.
Límites y condiciones de uso
La apariencia final puede ocultar problemas de acceso, validación o almacenamiento. Deben revisarse el código y la configuración, usar datos ficticios durante las pruebas y evitar publicar un proyecto con información real sin comprobar previamente sus controles y responsabilidades.
La guía de seguridad de Lovable indica que el código del navegador puede inspeccionarse o alterarse y no debe decidir accesos sensibles. La autorización necesita verificarse en servidor y en las reglas de datos correspondientes. Un escaneo sin hallazgos no demuestra que la lógica funcional sea correcta: puede no detectar que el portal ofrece una guía retirada o atribuye una aprobación inexistente. Revisa también esas reglas editoriales.
Documentación de referencia: Publish your Lovable project · Security best practices for Lovable apps.
Cuándo elegirla y con qué complementarla
Lovable encaja para probar una experiencia web y evolucionarla con código revisable. Figma puede resolver la discusión inicial sobre estructura sin conectar datos reales. Replit permite comparar otro entorno de desarrollo cuando el equipo necesita inspeccionar con más detalle ejecución y cambios.
Valora portabilidad, control de acceso, mantenimiento y facilidad de corregir una regla, además del aspecto inicial. La prueba debe incluir una solicitud sin permiso y un recurso inexistente; una pantalla vacía o un error técnico no explican al usuario cómo continuar.
Preguntas frecuentes
¿Compartir el proyecto y publicar la aplicación son lo mismo?
No. La colaboración sobre el proyecto y el acceso a la aplicación publicada tienen finalidades y controles diferentes. Revisa ambos antes de incorporar colaboradores o lectores externos.
¿Ocultar un botón protege una operación?
No. La comprobación debe realizarse donde se ejecuta la operación y se accede a los datos. La interfaz solo puede ayudar a mostrar las acciones disponibles.
¿Sincronizar GitHub crea una copia completa del servicio?
Conserva código, pero un servicio también puede depender de datos, secretos y configuración de alojamiento. Documenta esas dependencias y prueba la recuperación antes de considerar resuelta la continuidad.
