Què és Lovable i què produeix
Lovable és una plataforma de desenvolupament d’aplicacions web mitjançant instruccions en llenguatge natural. El resultat pot incloure interfície, lògica de servidor, base de dades, autenticació i integracions, amb codi editable. Un projecte representa una aplicació; l’espai de treball reuneix persones, projectes i recursos compartits.
La seva unitat de treball és un comportament que es pot provar: cercar un recurs, desar una reserva o mostrar dades autoritzades. Una pantalla atractiva és només una part del resultat. Per valorar una aplicació convé seguir la informació des de l’entrada fins a l’emmagatzematge i comprovar què passa quan falta una dada, canvia un permís o falla un servei.
Documentació de referència: Welcome to Lovable.
Origen i evolució del producte
L’antecedent és GPT Engineer, projecte obert que Anton Osika va publicar a la primavera de 2023. Osika i Fabian Hedin van desenvolupar posteriorment Lovable, el llançament amb aquesta marca del qual se situa al novembre de 2024 segons l’empresa. Tots dos fundadors van rebre el KTH Innovation Award de 2025.
L’evolució explica el seu enfocament: passar de generar fitxers a acompanyar la construcció i operació d’una aplicació. El projecte obert inicial, el servei comercial i el codi d’una aplicació creada per un client són objectes diferents; l’existència del primer no converteix tota la plataforma actual en programari obert.
Documentació de referència: Engineering history · Series C announcement · KTH Innovation Award.
Empresa i finançament
Els anuncis corporatius documenten tres rondes rellevants: el 17 de juliol de 2025, 200 milions de dòlars amb valoració de 1.800 milions, liderats per Accel; el 18 de desembre de 2025, 330 milions i valoració de 6.600 milions, amb CapitalG i Menlo Ventures; i el 12 d’agost de 2026, 400 milions i valoració de 13.300 milions, liderats per Menlo Ventures i el Scaleup Europe Fund.
Aquestes xifres descriuen finançament privat en dates concretes. Ajuden a entendre l’expansió de l’empresa i la infraestructura, però no equivalen a facturació, benefici ni un preu disponible per comprar-ne accions.
Documentació de referència: Series A announcement · Series B announcement · Series C announcement.
Tecnologia i estructura de les aplicacions
Lovable descriu una evolució tècnica basada en entorns d’execució persistents i recuperació d’instruccions rellevants per a l’agent. No es redueix a un únic model conversacional. Des del 13 de maig de 2026 els projectes nous utilitzen TanStack Start; per a Enterprise, des del 22 de juny. Els anteriors poden utilitzar React i Vite i disposen d’una via d’actualització.
TanStack Start renderitza pàgines al servidor. Aquesta diferència importa en revisar l’HTML que rep un visitant o un rastrejador i en escollir allotjament extern. La migració ha de comprovar rutes, autenticació i metadades. El canvi preparat al projecte no se serveix al públic fins que es torna a publicar.
Documentació de referència: Engineering history · TanStack Start upgrade.
Conversa, planificació i construcció
Chat permet discutir; Plan investiga i presenta una proposta editable sense canviar codi; Build, abans anomenat Agent, executa modificacions i mostra les diferències. Les instruccions persistents de l’espai de treball i del projecte, abans denominades Knowledge, aporten context. Les Skills es carreguen quan és pertinent.
Una especificació útil defineix usuaris, informació permesa, estats, errors i criteris d’acceptació. Per a un catàleg multilingüe, per exemple, convé decidir si cada idioma comparteix identificador, què passa quan falta una traducció i qui pot retirar una entrada. Aquestes decisions han de precedir instruccions visuals com colors o distribució.
Documentació de referència: Build mode · Plan mode · Instructions.
Edició visual i precisió dels canvis
La barra de la vista prèvia substitueix l’experiència anterior Visual edits. Permet seleccionar elements, modificar text en línia, dibuixar anotacions i afegir comentaris. Seleccionar una targeta aporta context a l’agent; un comentari pot servir per revisar sense descriure’n la posició en una altra conversa.
Per conservar coherència, es pot demanar una correcció petita i comprovar diverses pantalles: un títol traduït pot ocupar dues línies, un botó pot perdre l’etiqueta o un canvi de component repetir-se a tot el lloc. Revisar el resultat amb teclat, ampliació de text i continguts llargs aporta més evidència que aprovar únicament una captura.
Documentació de referència: Preview toolbar.
Dades, autenticació i permisos de l’agent
El backend integrat, també anomenat Cloud, parteix de la tecnologia oberta de Supabase i inclou base de dades, emmagatzematge, autenticació i funcions. Els permisos de l’agent distingeixen llegir, canviar dades i modificar estructura. En la documentació consultada, les migracions incompatibles estan bloquejades per defecte, mentre que altres operacions estan permeses.
Convé separar tres preguntes: qui modifica el codi, qui entra a l’aplicació i quins registres pot consultar cada persona. Tenir un compte no concedeix accés a totes les files. Igualment, canviar un text en desenvolupament i canviar un registre emmagatzemat són accions diferents: una revisió editorial del lloc no substitueix el control de les dades.
Documentació de referència: Built-in backend.
Proves de comportament i seguretat
Les proves de navegador s’executen sobre la vista prèvia en un entorn remot. Poden recórrer formularis i mides de pantalla, però tenen límits amb llenços, arrossegaments i detalls visuals; l’autenticació externa també limita què es pot comprovar. Quick scan revisa controls concrets en publicar; Deep scan analitza problemes de lògica, autorització i exposició al codi.
Una prova eficaç especifica resultat esperat i resultat prohibit. Per exemple, el lector pot obrir una fitxa publicada, però no recuperar-la mitjançant l’URL després de retirar-la si el contingut ha de deixar d’estar disponible. Cal assajar tots dos casos i desar quina versió, compte i dades s’han utilitzat. Un escàner i una prova funcional responen preguntes diferents.
Documentació de referència: Browser testing · Security overview.
Publicació i versions visibles
Publicar desplega una instantània en una URL; els canvis posteriors requereixen tornar a publicar. Els permisos de l’editor i del lloc públic són independents.
Per a una biblioteca de recursos, la verificació s’ha de fer des de l’adreça pública i amb una sessió equivalent a la del destinatari. Cal obrir enllaços profunds, recarregar una pàgina interior i comprovar que l’idioma escollit continua sent correcte. La confirmació del desplegament acredita una operació tècnica; la revisió del contingut confirma què rep el públic.
Documentació de referència: Publish your Lovable project.
Propietat, Git i sortida de la plataforma
Lovable documenta propietat del codi i contingut creat, subjecta a drets de tercers. La sincronització Git permet mantenir una còpia del codi i col·laborar amb desenvolupadors; GitHub no és obligatori per utilitzar el servei. Traslladar una aplicació completa requereix considerar per separat interfície, dades, autenticació, emmagatzematge i integracions.
Un assaig de portabilitat consisteix a arrencar una còpia, importar dades fictícies i comprovar l’accés a fitxers i serveis. Si només s’ha exportat el repositori, no s’ha de donar per preservat tot el sistema. L’inventari de dependències ha d’incloure també credencials, configuració del domini i tasques periòdiques, amb responsables per mantenir-les.
Documentació de referència: Sync project with GitHub · Ownership and portability.
Web, escriptori i mòbil
A més del navegador, Lovable ofereix aplicacions d’escriptori per a macOS i Windows, i mòbils per a iOS i Android. L’aplicació d’escriptori afegeix connexió amb servidors MCP locals. La mòbil permet continuar projectes amb el mateix compte i crèdits.
Aquestes aplicacions són superfícies per construir. El projecte creat es publica com a web: Lovable no genera React Native ni incorpora un tràmit directe d’enviament a les botigues. Una PWA o un embolcall extern són opcions diferents que requereixen feina addicional. Per a recursos preventius consultats des de telèfons, convé comprovar connectivitat, mida tàctil, descàrrega de documents i recuperació després de perdre la sessió.
Documentació de referència: Desktop app · Mobile app · Publish your Lovable project.
Plans, consum i tractament de dades
Els plans són Free, Pro, Business i Enterprise. Un mateix saldo de crèdits cobreix construcció, conversa, allotjament, backend i IA de l’aplicació. El cost de mantenir una web depèn també del seu ús, no només de quantes instruccions s’enviïn per crear-la.
Des del 9 de setembre de 2026, Free i Pro poden aportar contingut a l’entrenament, amb exclusió individual configurable i prospectiva. Business i Enterprise n’estan exclosos per defecte. La documentació distingeix aquest contingut de les dades que introdueixen els usuaris finals de les aplicacions, que no s’utilitzen per entrenar.
En pressupostar un projecte es poden separar tres escenaris propis: preparació, trànsit habitual i una campanya amb més visites. Així s’identifica qui observa el consum i quins límits cal aplicar abans de compartir àmpliament l’adreça.
Documentació de referència: Subscription plans · Credits and usage · Data training controls.
Incidents documentats i aprenentatge
El registre CVE-2025-48757 descriu polítiques RLS insuficients en llocs generats fins al 15 d’abril de 2025. Inclou la controvèrsia del proveïdor, que assenyala la responsabilitat del client sobre les dades. No permet concloure que totes les aplicacions actuals presentin aquest error.
Separadament, Lovable va reconèixer una regressió que va permetre accedir a codi i converses de projectes públics entre el 3 de febrer i el 20 d’abril de 2026. Va comunicar-ne la correcció i va excloure de l’abast projectes privats i Cloud. L’incident reforça la necessitat de distingir visibilitat de l’editor i accés a l’aplicació.
Documentació de referència: CVE-2025-48757 record · April 2026 incident response.
Aplicacions concretes en SST
Pot ajudar a explorar com presentar recursos preventius, organitzar materials o simplificar una consulta interna. La seva relació amb SST és de suport al disseny i al desenvolupament: permet provar una idea ràpidament, però el contingut, els permisos i els criteris de funcionament s’han de definir i revisar fora de les suposicions del generador.
Altres usos proposats són una pàgina de benvinguda que expliqui on trobar recursos i una demostració de consulta de materials per centre. Convé separar contingut públic i intern des del disseny. Una etiqueta «intern» o un botó ocult no constitueixen permisos: qui demana un recurs ha d’estar autoritzat també si accedeix directament a la seva adreça.
Cas pràctic i comprovació del resultat
Per exemple, es podria prototipar un portal que agrupés materials aprovats per idioma i temàtica, amb enllaços públics. L’equip comprovaria la cerca i la llegibilitat abans de decidir si val la pena convertir-lo en una eina mantinguda.
Al portal de l’exemple, defineix cada material amb títol, idioma, tema, data de revisió i enllaç autoritzat. Prepara un conjunt petit amb duplicats controlats i un document retirat per comprovar com es mostren aquests estats. Descriu una regla explícita: el cercador ofereix materials vigents i explica si una versió ja no està disponible.
Prova la cerca en els tres idiomes i verifica que el filtre no canvia inadvertidament la llengua del document. Després corregeix un títol i comprova l’efecte a la llista i al detall. Si s’afegeixen comptes, utilitza dues identitats fictícies amb permisos diferents i verifica l’accés efectiu a les dades, no només als botons. La revisió final ha d’identificar la versió provada i l’audiència prevista abans de publicar.
Límits i condicions d’ús
L’aparença final pot amagar problemes d’accés, validació o emmagatzematge. Cal revisar el codi i la configuració, utilitzar dades fictícies durant les proves i evitar publicar informació real sense comprovar prèviament els controls i les responsabilitats.
La guia de seguretat de Lovable indica que el codi del navegador es pot inspeccionar o alterar i no ha de decidir accessos sensibles. L’autorització s’ha de verificar al servidor i a les regles de dades. Un escaneig sense incidències no demostra una lògica funcional correcta: pot no detectar que el portal ofereix una guia retirada o atribueix una aprovació inexistent. Revisa també aquestes regles editorials.
Documentació de referència: Publish your Lovable project · Security best practices for Lovable apps.
Quan escollir-la i amb què complementar-la
Lovable encaixa per provar una experiència web i evolucionar-la amb codi revisable. Figma pot resoldre la discussió inicial sobre estructura sense connectar dades reals. Replit permet comparar un altre entorn quan cal inspeccionar amb més detall execució i canvis.
Valora portabilitat, control d’accés, manteniment i facilitat de corregir regles, a més de l’aspecte inicial. Inclou una petició sense permís i un recurs inexistent a la prova; una pantalla buida o un error tècnic no expliquen com continuar.
Preguntes freqüents
Compartir el projecte i publicar l’aplicació són el mateix?
No. La col·laboració sobre el projecte i l’accés a l’aplicació publicada tenen finalitats i controls diferents. Revisa tots dos abans d’incorporar col·laboradors o lectors externs.
Amagar un botó protegeix una operació?
No. Cal comprovar permisos on s’executa l’operació i s’accedeix a les dades. La interfície només ajuda a mostrar les accions disponibles.
Sincronitzar GitHub crea una còpia completa del servei?
Conserva codi, però el servei també pot dependre de dades, secrets i configuració d’allotjament. Documenta aquestes dependències i prova la recuperació abans de considerar resolta la continuïtat.
