Utkastet är en kopia av appen, inte av innehållet. Skapa ett utkast, lägg in en post som är omöjlig att förväxla med riktig data och kontrollera att den syns i huvudversionens förhandsvisning. Rör aldrig befintliga poster i ett utkast. Vill du prova något som kräver egen data, egna inloggningar eller egna nycklar är ett eget projekt fortfarande rätt väg.
Vad Lovable ändrade
Enligt Lovables changelog för 9 september 2026 öppnar du utkastväxlaren genom att klicka på projektnamnet högst upp i editorn. New draft skapar en kopia av huvudversionen som först heter Draft 1 och sedan döps om efter ditt första uppdrag. I utkastet chattar du som vanligt, förhandsvisningen visar utkastets version av appen och varje redigering stannar där tills du väljer Accept. Raderar du utkastet försvinner det med alla sina redigeringar, och det går inte att återställa; projektet är då oförändrat.
Funktionsdokumentationen anger att utkast finns på alla planer. Meddelanden i ett utkast kostar samma krediter som i huvudversionen, medan att skapa, uppdatera, acceptera och radera ett utkast inte drar några krediter enligt Lovable. Ett utkast som ingen har redigerat tas bort automatiskt efter 24 timmar. Antalet utkast är inte begränsat, och när huvudversionen får nyare ändringar visar utkastets rad en grå punkt märkt Updates available.
Accept är inte publicering. Bekräftelsen lägger utkastets redigeringar bland projektets opublicerade ändringar och tar dig tillbaka till huvudversionen; ett utkast har ingen egen Publish-knapp. Din publicerade app ändras först när du publicerar från huvudversionen. Före bekräftelsen visar Lovable en sammanfattning på en rad av vad utkastet ändrar. Samma post i changeloggen innehåller även en omgjord meny för chattåtgärder, sparade planversioner och tabellvisning av CSV-filer; de påverkar inte utkasten och behandlas inte här.
Det utkastet inte kopierar
Dokumentationen är tydlig på en punkt som lätt drunknar i ordet kopia: ett utkast har ingen egen backend. Varje utkast använder projektets inbyggda backend, Cloud, med samma databas, samma filer och samma inställningar som huvudversionen. Lägger du till, ändrar eller raderar information medan du testar i utkastet är ändringen verklig, precis som när du testar direkt i projektet. Att radera utkastet ångrar den inte.
Lovables egen varning lyder: redigerar eller raderar du en post som appen redan har, ändras den även för den publicerade appen. Lovables råd är att skapa egna poster att testa med. Det gäller även användarkontona, som hör till samma backend. Utkastets förhandsvisning har en egen webbadress, så du kan behöva logga in igen där; det betyder inte att du fått ett separat konto, utan att du loggar in i samma app med samma användare.
Här ligger skillnaden mot sajtens tidigare prov på en isolerad kopia. Det provet byggde på att kopian saknar produktionsdata, så att en ändring kan gå fel utan att någon riktig bokning eller kund berörs. Ett utkast ger dig den friheten för appens utseende och sidor, men inte för dess innehåll. Det är ett annat verktyg, och det ska väljas för andra prov.
Åtta saker som bara ändras i huvudversionen
Eftersom en ändring av den delade backendens inställningar når den publicerade appen direkt gör Lovable dessa ändringar bara i huvudversionen. Dokumentationen räknar upp åtta punkter, och listan nedan är fullständig i förhållande till källan:
Ber du om något av detta i ett utkast säger Lovable till att göra ändringen i huvudversionen och fortsätter med resten av din begäran. Arbetsordningen blir då: byt till huvudversionen, gör ändringen där, uppdatera utkastet så att den följer med. Nya tabeller och kolumner är ett mellanting. Du kan beställa dem i utkastet, men Lovable förbereder bara ändringen och gör den i databasen först när du accepterar. Fram till dess visar sidor som läser den nya tabellen ett fel i utkastets förhandsvisning, och det felet är enligt dokumentationen väntat. Att ta bort eller döpa om en befintlig tabell eller kolumn görs inte alls från ett utkast; Lovable lägger i stället till en ny kolumn och kopierar över data, eller hänvisar till SQL-editorn under More → Cloud → SQL editor. Har du kopplat ett Git-repo syns utkastet inte som en gren där; koden når repot först efter Accept.
Prova gränsen med en märkt testpost
Gör provet i ett projekt som redan har en tabell med riktiga eller riktigt utseende poster, till exempel en lista över bokningar eller ärenden. Syftet är inte att bygga något utan att se med egna ögon var utkastets gräns går. Skriv ner projektnamnet och tidpunkten innan du börjar.
Om posten inte syns i huvudversionen i steg 3 är det inte ett tecken på isolering. Kontrollera först att du är inloggad med samma användare i båda förhandsvisningarna och att sidan är omladdad, eftersom inloggningen inte alltid följer med till utkastets adress. Om något redan gått fel med en riktig post innan du läste hit är artikeln om att återställa appen från en backup nästa steg; radera inte fler poster i hopp om att det ska rätta till sig.
Utkast eller eget projekt: välj före nästa prov
Valet ska göras innan du skriver första uppdraget, inte efter att en testpost dykt upp i kundens lista. Tre frågor räcker:
Utkastet löser ett verkligt problem: att kunna jämföra två versioner av en sida utan att bygga om originalet, till samma kreditkostnad per meddelande som förut. Det löser inte problemet att prova med låtsasdata. Den som bygger utan kod behöver hålla isär de två, och det enklaste sättet är att ha gjort provet ovan en gång.
Du har skapat ett utkast, lagt in en post med texten UTKASTPROV och datum via appens eget formulär, sett samma post i huvudversionens förhandsvisning utan att acceptera, raderat utkastet och sett att posten fanns kvar, och därefter tagit bort den. De åtta inställningar som bara ändras i huvudversionen står i projektets anteckningar. För nästa prov har du skrivit ner om det ska göras i ett utkast eller i ett eget projekt, och varför.