Lovable AI Opsætning: Byg App i 13 Trin, 45 Min [2026]

Lovable har på under to år udviklet sig fra et lille eksperiment til en af de mest omtalte AI-appbyggere i 2026. Platformen lader dig beskrive en app i almindeligt sprog og få en fungerende React-applikation med database og login tilbage på minutter. For danske udviklere, freelancere og iværksættere, der vil teste en idé hurtigt uden at skrive hver linje kode selv, er det blevet et reelt alternativ til traditionel udvikling. Denne guide viser dig, trin for trin, hvordan du opsætter Lovable, forbinder Supabase, synkroniserer med GitHub og deployer et komplet projekt til produktion.

Vi bygger et konkret eksempel undervejs, en venteliste-app med login og en database-tabel, så du ikke bare læser om trinene, men kan følge med og have et kørende produkt i hånden efter omkring 45 minutter. Undervejs får du kodeeksempler, en prisoversigt, ni almindelige fejl med løsninger og en liste over faldgruber, som koster nye brugere unødvendige kreditter. Guiden dækker hele forløbet fra oprettelse af konto til et deployet projekt med sin egen database, så du kan følge med trin for trin uden at skulle slå detaljer op andre steder undervejs.

Hvad er Lovable, og hvorfor taler alle om det i 2026?

Lovable (lovable.dev) er en AI-drevet appbygger, hvor du chatter dig frem til en app i stedet for at skrive kode fra bunden. Du skriver en prompt, og platformen genererer en frontend i React med Vite og Tailwind CSS, kobler den til en Postgres-database via Supabase og giver dig en live preview-URL, du kan dele med det samme. Det gør Lovable relevant for både ikke-tekniske grundlæggere, der vil validere en idé, og udviklere, der vil spare tid på kedeligt bundtøjsarbejde som formularer, autentificering og CRUD-endpoints.

I løbet af 2026 har Lovable udvidet fra et rent frontend-værktøj til en platform, der håndterer hele stakken. To-vejs GitHub-synkronisering betyder, at du kan arbejde videre i din egen editor, mens Supabase-integrationen automatisk opsætter tabeller, Row Level Security-politikker, autentificering og Edge Functions. Domænekøb, en visuel direkte-redigeringstilstand og rollestyring til teams er også kommet til i løbet af året. Lovable oplyser ikke offentligt, hvilke sprogmodeller der driver platformen, så betragt selve “motoren” som en sort boks, du styrer gennem prompts og indstillinger frem for konfigurationsfiler.

Konkurrencen i kategorien er hård. Værktøjer som Vercels v0, bolt.new og Replit trækker i den samme gruppe af brugere, der vil gå fra idé til fungerende produkt uden at samle et helt udviklerteam først. Det, der adskiller Lovable, er kombinationen af en fast Supabase-backend og en kodebase, du frit kan tage med dig, hvis du på et tidspunkt vokser ud af platformen. Den kombination gør værktøjet lige så relevant for en enkeltmandsvirksomhed i Aarhus som for et større produktteam, der vil teste ti idéer på en måned, før de vælger, hvilken der skal bygges videre på med et rigtigt team.

Derfor er Lovable relevant for danske og nordiske udviklere

Danske freelancere og små udviklingsbureauer bruger ofte de første uger på et projekt til at bygge det samme fundament igen og igen: login, en database-tabel, en admin-side og et betalingsflow. Lovable fjerner meget af det gentagne arbejde, fordi platformen genererer et fungerende udgangspunkt på minutter i stedet for dage. Det betyder ikke, at faglig indsigt bliver overflødig. Det betyder, at den indsigt flyttes fra at skrive boilerplate-kode til at vurdere arkitektur, sikkerhed og brugeroplevelse, hvilket er den del af arbejdet, kunder rent faktisk betaler for.

Der er også en praktisk detalje, danske brugere bør kende til. Supabase-projekter kan oprettes i forskellige regioner, og vælger du en europæisk region, ligger dine data som udgangspunkt inden for EU. Det er relevant, hvis appen kommer til at håndtere persondata om danske brugere, fordi placeringen af data har betydning for, hvordan du dokumenterer overholdelse af databeskyttelsesreglerne over for kunder eller investorer. Vælg regionen bevidst, allerede når du opretter Supabase-projektet i trin 5, i stedet for at flytte data senere.

Forudsætninger: det skal du have klar

Lovable kører i browseren, så du behøver ikke installere en lokal udviklingsmiljø for at komme i gang. Men hvis du vil redigere koden lokalt, synkronisere med GitHub eller køre den eksporterede app på din egen maskine, skal følgende være på plads:

• En moderne browser (Chrome, Edge eller Firefox, opdateret inden for de sidste par måneder)
• En gratis GitHub-konto til to-vejs synkronisering af projektet
• En gratis Supabase-konto til database, autentificering og Edge Functions
• Node.js version 20 eller nyere, hvis du vil klone og køre projektet lokalt
• npm 10 eller pnpm som pakkehåndtering til den eksporterede kode
• Git installeret lokalt, hvis du vil arbejde i en editor som VS Code eller Cursor ved siden af Lovable
• Et gyldigt betalingskort, hvis du senere vil opgradere til Pro eller Business (ikke nødvendigt på Free-planen)

Du behøver ingen forudgående erfaring med React for at følge guiden, men grundlæggende kendskab til, hvordan en database-tabel og en API-nøgle hænger sammen, gør fejlfindingen lettere senere. Sæt gerne 45 til 60 minutter af til hele forløbet, fra du opretter kontoen, til ventelisten er live på et offentligt tilgængeligt link. Har du allerede en Supabase- eller GitHub-konto fra et andet projekt, kan du regne med den lave ende af det tidsrum.

Trin 1: Opret konto og vælg den rigtige plan

Gå til lovable.dev, og opret en konto med enten din e-mail eller dit GitHub-login. Free-planen kræver ikke betalingskort og er nok til at følge denne guide igennem. Før du går videre, er det værd at kende forskellen på planerne, da kreditforbruget er det, der oftest overrasker nye brugere.

Plan	Pris/md	Pris/md (årligt)	Kreditter inkluderet	Bedst til
Free	$0	–	5 daglige build-kreditter, maks. 30/md	Test og små projekter
Pro	$25	$21	100 kreditter/md + 5 daglige (op til 150/md), rollover	Soloudviklere og hurtige MVP’er
Business	$50	$42	Som Pro, plus SSO, roller og opt-out af AI-træning	Teams med styringsbehov
Enterprise	Individuel pris	–	Volumenbaseret	Store organisationer
Ekstra kreditter (top-up)	Betales pr. forbrug	–	Gyldig 12 måneder fra køb	Alle betalte planer ved spidsbelastning

Priserne stammer fra Lovables egen prisside, krydstjekket mod flere uafhængige gennemgange fra august 2026. Læg mærke til, at kreditsystemet er delt op i flere lag: generelle kreditter dækker det meste af arbejdet, mens daglige build-kreditter nulstilles hver dag og fungerer som en buffer, selv når din månedlige kvote er brugt. Det er grunden til, at du sjældent låses helt ude, selv på Free-planen.

Trin 2: Forstå kredittyperne, før du bruger dem

Lovables kreditsystem forvirrer nye brugere, fordi der findes fire forskellige typer, og de bruges til forskellige ting. Tabellen herunder opsummerer, hvad hver type dækker, så du ikke ender med at spilde en hel dags kvote på en enkelt stor ændring.

Kredittype	Hvad den dækker	Nulstilles	Tilgængelig på	Praktisk konsekvens
Generelle kreditter	De fleste prompts og kodeændringer	Månedligt	Pro og Business	Brug dem til større ændringer
Daglige build-kreditter	Mindre builds og genereringer	Dagligt	Alle planer	Fordel arbejdet over flere dage
Cloud-kreditter	Hosting og sandbox-kørsel	Månedligt	Alle planer	Påvirkes af, hvor ofte previewet genindlæses
AI-grants	Ekstra AI-forbrug ved lancering af nye funktioner	Varierer	Alle planer	Brug dem først, da de ofte udløber
Top-up-kreditter	Ekstra kapacitet købt separat	Udløber efter 12 måneder	Pro og Business	God buffer ved deadlines

En praktisk tommelfingerregel: bed AI’en om to til tre ændringer ad gangen i stedet for at bede om ti ting i én prompt. Store, sammensatte prompts bruger markant flere generelle kreditter, fordi Lovable ofte skal regenerere større dele af koden for at holde det hele konsistent.

Trin 3: Skriv din første prompt og generér appen

Klik på “New project” på dashboardet, og skriv en beskrivelse af den app, du vil bygge. Jo mere konkret prompten er, desto bedre bliver resultatet. Undgå at skrive “byg mig en app til min startup”. Skriv i stedet, hvad appen konkret skal kunne, hvilke sider den har, og hvordan brugeren interagerer med den.

Byg en venteliste-app til en kommende SaaS-tjeneste.

Krav:
- Forside med produktnavn, kort beskrivelse og et e-mail-signup-felt
- Når en bruger tilmelder sig, gemmes e-mailen i en tabel "waitlist_signups"
- Vis en tælleopdatering: "Du er nummer X på ventelisten"
- Admin-side på /admin, kun tilgængelig efter login, der viser en liste over alle tilmeldte
- Design: mørk baggrund, ét accentfarve, enkel og ren, ingen overflødige elementer
- Brug Supabase til database og autentificering på admin-siden

Efter du sender prompten, bruger Lovable typisk et halvt til et helt minut på at generere det første udkast. Du får en live preview i højre side af skærmen og en chatlog i venstre side, hvor du kan se, hvilke filer der blev oprettet eller ændret. En god vane, som flere erfarne brugere fremhæver, er at skrive et kort produktkrav-dokument i ChatGPT eller Claude, før du overhovedet åbner Lovable. Det giver en mere præcis første prompt og sparer kreditter, fordi du undgår at rette den samme ting fem gange.

Output-eksempler: sådan ser en vellykket generering ud

Det er nyttigt at vide, hvad et normalt resultat faktisk ligner, før du selv sidder med det. Efter prompten i forrige trin viser chatloggen typisk en kort liste over de filer, Lovable har rørt ved, efterfulgt af en kort forklaring i almindeligt sprog. Herunder ses et typisk uddrag af, hvad du kan forvente at se i loggen.

Opretter projekt "venteliste-app"...

✓ Oprettede src/pages/Index.tsx
✓ Oprettede src/components/WaitlistForm.tsx
✓ Oprettede src/pages/Admin.tsx
✓ Forbandt Supabase-projekt "venteliste-app-db"
✓ Oprettede tabel waitlist_signups
✓ Konfigurerede Supabase Auth (e-mail/adgangskode)

Preview klar: https://venteliste-app.lovable.app
Build-tid: 34 sekunder

Ser din log markant anderledes ud, for eksempel med en fejlmeddelelse i stedet for et grønt flueben ud for et af trinnene, er det første sted at kigge. Kopiér den præcise fejltekst ind i en ny prompt, og bed Lovable rette netop den fejl, i stedet for at omformulere hele den oprindelige prompt igen. Det er hurtigere og bruger færre kreditter, fordi AI’en kan fokusere ændringen på den fil, der faktisk fejlede. Gem gerne et par af dine bedste prompts i en tekstfil ved siden af, så du hurtigt kan genbruge strukturen, næste gang du starter et lignende projekt.

Trin 4: Brug den visuelle editor og live preview

Når det første udkast er klar, kan du skifte mellem tre visninger: chatten, live previewet og rå kode. Den visuelle editor lader dig klikke direkte på elementer i previewet, ændre tekst, farver og layout uden at skrive en ny prompt for hver lille justering. Det er praktisk til finpudsning, men vær opmærksom på, at manuelle rettelser i koden ikke altid opdaterer chattens forståelse af projektet automatisk.

Prøv at ændre accentfarven og knapteksten via den visuelle editor nu. Du vil se, at previewet opdateres med det samme, uden at du bruger en generel kredit. Det er en af de billigste måder at style appen på, fordi rene stilændringer typisk trækker på de mindre daglige build-kreditter frem for de generelle.

Trin 5: Forbind Supabase til database og login

Klik på Supabase-ikonet i toppen af projektet, og godkend forbindelsen med din Supabase-konto. Har du ikke en konto, opretter Lovable et nyt gratis Supabase-projekt til dig med det samme. Når forbindelsen er oprettet, kan du bede Lovable om at oprette de nødvendige tabeller direkte fra en prompt.

-- Genereret og anvendt af Lovable i Supabase SQL-editoren
create table waitlist_signups (
  id uuid primary key default gen_random_uuid(),
  email text not null unique,
  created_at timestamp with time zone default now()
);

create table admin_users (
  id uuid primary key references auth.users(id),
  full_name text,
  created_at timestamp with time zone default now()
);

Lovable håndterer selv migrationsfilerne og kører dem mod dit Supabase-projekt. Du kan altid åbne Supabase-dashboardet direkte og se de samme tabeller, hvis du vil dobbelttjekke, at strukturen matcher det, du bad om. Autentificering til admin-siden sættes typisk op med Supabase Auth via e-mail og adgangskode, men du kan også bede om OAuth-login med Google eller GitHub i samme prompt.

Trin 6: Skriv sikre RLS-politikker, før du går videre

Supabase bruger Row Level Security (RLS) til at afgøre, hvem der må læse og skrive i en tabel. Uden en eksplicit politik afviser Postgres som udgangspunkt alle forespørgsler, når RLS er slået til, hvilket er en sikker standard, men ofte forveksles med en fejl af nye brugere. Bed Lovable om at sætte politikkerne op eksplicit, i stedet for at stole på standardindstillingen.

alter table waitlist_signups enable row level security;

-- Alle må tilmelde sig ventelisten (offentligt indsæt)
create policy "Alle kan tilmelde sig"
  on waitlist_signups for insert
  with check (true);

-- Kun autentificerede admin-brugere må læse listen
create policy "Kun admin kan læse ventelisten"
  on waitlist_signups for select
  using (auth.uid() in (select id from admin_users));

Test politikkerne ved at logge ud og prøve at tilgå admin-siden direkte via URL’en. Får du adgang uden login, er politikken enten forkert konfigureret, eller også mangler den helt. Det er en af de hyppigste sikkerhedsfejl i AI-genererede apper, fordi det er nemt at glemme, at “det virker i previewet” ikke er det samme som “det er sikkert i produktion”.

Sikkerhed og datahåndtering, du bør kende, før du lancerer

AI-genereret kode er ikke automatisk usikker, men den er heller ikke automatisk sikker, bare fordi den kommer fra en model. Behandl output fra Lovable, som du ville behandle kode skrevet af en ny, dygtig kollega: gennemgå den, før den rammer produktion. Tre ting er værd at tjekke systematisk, hver gang du tilføjer en ny tabel eller et nyt endpoint. Er RLS slået til på tabellen. Matcher politikkerne den adgang, du faktisk ønsker at give. Ligger hemmelige nøgler i miljøvariabler frem for direkte i koden eller i en prompt.

På Business-planen kan du slå AI-træning på dine projektdata fra som standard, hvilket er relevant, hvis appen håndterer kundedata, interne systemer eller andet, du ikke ønsker indgår i træningsgrundlaget for fremtidige modelforbedringer. Kombinér det gerne med en gennemgang af, hvilken Supabase-region dit projekt ligger i, og hvilke tredjepartstjenester du kobler på via API-nøgler, så du har et samlet overblik, før appen bliver offentligt tilgængelig.

Lav en kort tjekliste, du gennemgår, hver gang du er klar til at dele et projekt uden for dit eget team. Er RLS aktiveret på alle tabeller med brugerdata. Er hemmelige nøgler flyttet ud af prompthistorikken og ind i miljøvariabler. Er projektet sat til privat, hvis det stadig er under udvikling. De tre spørgsmål tager under et minut at besvare og fanger langt de fleste af de sikkerhedsfejl, nye Lovable-brugere ellers opdager for sent.

Trin 7: Rediger koden direkte og forstå stakken

Lovable genererer en fuld React-applikation bygget med Vite og Tailwind CSS, med Supabase som backend. Du kan altid skifte til kodevisningen og se hele filstrukturen, hvilket er nyttigt, når du vil forstå, hvad AI’en faktisk har bygget, eller når du vil rette en detalje manuelt i stedet for at bruge en kredit på en ny prompt.

venteliste-app/
├── src/
│   ├── components/
│   │   ├── WaitlistForm.tsx
│   │   └── AdminTable.tsx
│   ├── pages/
│   │   ├── Index.tsx
│   │   └── Admin.tsx
│   ├── integrations/
│   │   └── supabase/
│   │       └── client.ts
│   └── App.tsx
├── package.json
├── tailwind.config.ts
└── vite.config.ts

Denne struktur følger konventionerne for et almindeligt Vite-projekt, hvilket betyder, at enhver udvikler, der kender React, kan overtage koden uden at lære et proprietært framework. Det er en af grundene til, at Lovable er blevet populært blandt teams, der starter som no-code, men forventer at skalere til et rigtigt udviklerteam senere.

Trin 8: Synkronisér projektet med GitHub

Under projektindstillinger finder du en knap til at forbinde et GitHub-repository. Lovable opretter et nyt repo eller kobler sig til et eksisterende, og herefter er synkroniseringen to-vejs: ændringer, du laver i Lovable, bliver committet til repoet, og ændringer, du laver lokalt i VS Code eller Cursor, dukker op i Lovable, næste gang du åbner projektet.

# Klon det repo, som Lovable har oprettet
git clone https://github.com/dit-brugernavn/venteliste-app.git
cd venteliste-app

# Installer afhængigheder og kør lokalt
npm install
npm run dev

# Lav en ændring lokalt, og send den tilbage til Lovable
git add .
git commit -m "Justerer valideringsregel på e-mail-felt"
git push origin main

Når du har pushet, henter Lovable automatisk ændringen inden for kort tid og opdaterer sit interne billede af projektet. Arbejder du i et team, hvor flere redigerer samme fil både i Lovable og lokalt samtidig, kan du opleve synkroniseringskonflikter. Løsningen er at committe lokale ændringer først og lade Lovable trække dem ind, før du fortsætter med nye prompts i selve platformen. Denne arbejdsgang gør det også muligt at sætte almindelig code review op i GitHub, hvis flere personer arbejder på samme projekt, uanset om de sidder i Lovable eller i en lokal editor.

Trin 9: Miljøvariabler, hemmeligheder og deploy

De fleste projekter har brug for hemmelige nøgler, som ikke skal ligge synligt i koden, for eksempel en API-nøgle til en tredjepartstjeneste. Lovable har et separat panel til miljøvariabler under projektindstillinger, adskilt fra chatten, så nøglerne ikke havner i prompthistorikken ved en fejl.

# .env.local (eksempel, sættes via Lovables miljøvariabel-panel)
VITE_SUPABASE_URL=https://dit-projekt.supabase.co
VITE_SUPABASE_ANON_KEY=din-anon-noegle
RESEND_API_KEY=din-noegle-til-e-mail-udsendelse

Husk at sætte variablerne i både preview- og produktionsmiljøet, hvis de skal virke begge steder. Det er en af de mest almindelige fejl, når en app virker perfekt i previewet, men fejler, lige så snart den er deployet. Når variablerne er på plads, klikker du på “Publish” for at deploye. Første deploy sker typisk til et gratis underdomæne i formatet dit-projekt.lovable.app, og du kan se den live om få sekunder. Åbn linket i en privat browserfane med det samme, så du tester appen, som en fremmed besøgende ville opleve den, uden din egen indloggede session eller browsercache i vejen.

Trin 10: Tilknyt eget domæne og inviter teamet

Du kan enten købe et domæne direkte gennem Lovable eller pege dit eksisterende domæne mod projektet. Under Business-planen får du derudover adgang til roller og rettighedsstyring, single sign-on og mulighed for at slå AI-træning på dine data fra som standard. Det gør Business relevant for virksomheder, der arbejder med interne eller følsomme data i deres apps.

For at invitere teammedlemmer går du til projektets indstillinger og tilføjer deres e-mail. Free-planen tillader ubegrænsede samarbejdspartnere på private projekter, mens roller med adgangsniveauer først bliver relevante på Pro og Business, hvor du kan begrænse, hvem der må ændre produktionskoden, og hvem der kun må se previewet.

Byg et komplet projekt: venteliste-app fra bund til produktion

Nu samler vi det hele. Her er den fulde rækkefølge, du følger for at gå fra tom skærm til en live, offentligt tilgængelig venteliste-app med database og et beskyttet admin-panel.

1. Trin 11: Opret projektet med den detaljerede prompt fra trin 3, og vent på det første udkast. Læs chatloggen igennem, og bekræft, at alle filerne fra output-eksemplet blev oprettet, før du går videre.
2. Trin 12: Forbind Supabase, og bekræft, at tabellerne waitlist_signups og admin_users er oprettet korrekt i dashboardet. Åbn Table Editor i Supabase, og tjek kolonnenavnene, så de matcher det, du bad om.
3. Trin 13: Tilføj RLS-politikkerne fra trin 6, og test dem ved at prøve at tilgå admin-siden i et privat browservindue uden at være logget ind. Bekræft samtidig, at et almindeligt tilmeldingsforsøg fra forsiden stadig virker.
4. Trin 14: Bed Lovable om at tilføje en tæller, der viser antallet af rækker i waitlist_signups, så forsiden opdateres i realtid. Test tælleren ved at oprette to-tre testtilmeldinger og se, at tallet stiger korrekt.
5. Trin 15: Sæt miljøvariablerne op, forbind GitHub, og klik “Publish” for at gå live på dit gratis underdomæne. Gem preview-URL’en et sted, hvor du kan finde den igen, når du skal dele projektet med andre.

Testresultat: en fungerende venteliste, hvor et testsignup med en e-mail som “[email protected]” med det samme dukker op i Supabase-tabellen, og hvor forsiden viser en opdateret tæller uden at genindlæse siden. Log ind på admin-siden med den bruger, du oprettede i Supabase Auth, og bekræft, at listen med tilmeldte kun er synlig, når du er logget ind. Lykkes begge dele, har du et fungerende, sikkert fundament, du kan bygge videre på med betalingsintegration, e-mail-notifikationer eller flere sider. Gem projektet som skabelon i dit eget GitHub-repo, så du kan genbruge fundamentet, næste gang du skal validere en ny idé hurtigt.

Tilføj betaling med Stripe: et typisk næste skridt

Når ventelisten virker, er det næste, de fleste beder om, en betalingsintegration, så de kan begynde at tage imod forudbestillinger eller sælge tidlig adgang. Lovable understøtter Stripe gennem samme prompt-baserede flow som resten af appen, men kræver, at du selv opretter en Stripe-konto og henter API-nøglerne derfra, inden du beder om integrationen.

Tilføj Stripe Checkout til ventelisten.

Krav:
- Ny knap "Sikr din plads – 99 kr." på forsiden
- Ved klik åbnes Stripe Checkout i et nyt vindue
- Efter gennemført betaling markeres brugerens række i waitlist_signups
  med has_paid = true
- Brug miljøvariablerne STRIPE_SECRET_KEY og STRIPE_PUBLISHABLE_KEY,
  som allerede er sat i projektindstillingerne

Lovable opretter typisk en Edge Function i Supabase til at håndtere webhook-kaldet fra Stripe, fordi den logik ikke bør ligge i frontend-koden. Test altid betalingsflowet med Stripes testkort, før du skifter til de rigtige nøgler, og bekræft i Supabase-dashboardet, at feltet has_paid faktisk opdateres efter en gennemført testbetaling. Det er en god øvelse i at læse den kode, Lovable har genereret, i stedet for blot at stole på, at previewet ser rigtigt ud.

Fem faldgruber, der koster dig credits og tid

De fleste nye Lovable-brugere rammer de samme faldgruber i de første par projekter. Her er dem, der oftest nævnes i erfarne brugeres gennemgange, og som du kan undgå med det samme.

• For store prompts. At bede om ti ændringer på én gang forvirrer modellen og bruger flere generelle kreditter, end fem separate, præcise prompts ville gøre. Del i stedet arbejdet op efter funktion: én prompt til data, én til visning, én til validering.
• Springer RLS-politikker over. Uden eksplicitte politikker er tabellen enten helt lukket eller, værre, helt åben, hvis nogen deaktiverer RLS for at “få det til at virke”. Den hurtige løsning er ofte den usikre løsning her.
• Offentlige projekter på Free-planen. Projekter på Free er som udgangspunkt synlige, hvilket betyder, at følsomme data eller forretningslogik kan være tilgængelig for andre. Opgrader, hvis projektet skal være privat, allerede før du lægger rigtige data ind.
• Redigerer kode og chat parallelt uden at synkronisere. Manuelle kodeændringer, der ikke bliver hentet ind i chattens kontekst, fører til, at AI’en overskriver dine rettelser ved næste prompt. Push altid dine lokale ændringer, før du beder om noget nyt i chatten.
• Glemmer miljøvariabler i preview-miljøet. En funktion, der virker i produktion, men fejler i preview, skyldes næsten altid manglende variabler dér. Tjek begge miljøer, hver gang du tilføjer en ny nøgle.
• Venter med at teste RLS til efter lancering. Test altid adgangskontrol, mens projektet stadig er i preview, ikke efter det er delt med rigtige brugere. Det er markant billigere at rette en politik nu end at håndtere en datalæk senere.

Fejlfinding: ni problemer og deres løsninger

Herunder er en oversigt over de problemer, du med størst sandsynlighed støder på, og hvordan du løser dem uden at bruge unødvendige kreditter på at gætte dig frem. De fleste af dem opstår i overgangen mellem to systemer, for eksempel mellem Lovable og Supabase eller mellem Lovable og GitHub, snarere end i selve AI-genereringen. Start derfor altid fejlsøgningen med at spørge, hvilket af de to systemer der sidst blev ændret.

Problem	Sandsynlig årsag	Løsning
Supabase-forbindelse fejler	Forkert projekt-URL eller API-nøgle	Hent nøglerne igen under Project Settings > API i Supabase, og genindsæt dem
Hvid eller tom skærm efter deploy	Build fejlede stille pga. en forældet afhængighed	Åbn build-loggen, og bed AI’en rette den specifikke fejlmeddelelse
GitHub-sync viser konflikt	Samme fil er redigeret lokalt og i Lovable samtidig	Commit lokale ændringer først, og lad Lovable trække dem ind, før du fortsætter
Kreditter opbrugt midt i en session	For mange samtidige ændringer i én prompt	Vent på daglig reset, eller opgrader til Pro for rollover og flere kreditter
Custom domain validerer ikke	DNS-poster er ikke propageret endnu	Vent op til 24-48 timer, og tjek opsætningen med en DNS-lookup-tjeneste
Login virker ikke i produktion	Redirect-URL matcher ikke det nye domæne i Supabase Auth	Tilføj produktionsdomænet som gyldig redirect-URL i Supabase-indstillingerne
Miljøvariabel mangler i preview	Variablen blev kun sat i produktionsmiljøet	Dupliker variablen til preview-miljøet under projektindstillinger
Visuel editor og kode er ude af sync	Direkte kodeændringer uden opdatering via chatten	Genindlæs projektet, eller kør en manuel synkronisering fra kodefanen
RLS-politik blokerer alle forespørgsler	Ingen politik er defineret, så Postgres afviser som standard	Tilføj en eksplicit SELECT/INSERT-politik, der matcher din autentificeringslogik

Avancerede tips til at få mere ud af Lovable

Når det grundlæggende sidder fast, kan et par vaner fra erfarne brugere spare dig for både tid og kreditter på de næste projekter.

• Skriv et kort produktkrav-dokument, før du åbner Lovable. Jo mere præcis den første prompt er, desto færre rettelsesrunder skal du bruge kreditter på.
• Brug Edge Functions i Supabase til logik, der ikke bør ligge i frontenden, for eksempel beregning af priser eller kald til eksterne API’er med hemmelige nøgler.
• Udnyt kredit-rollover på Pro og Business ved at samle større ændringer til dage, hvor du har flere kreditter til rådighed.
• Arbejd i Cursor eller VS Code ved siden af Lovable via GitHub-synkroniseringen, når en ændring er for detaljeret til at beskrive præcist i en prompt.
• Slå opt-out af AI-træning til på Business-planen, hvis projektet indeholder kundedata eller forretningskritisk logik.
• Brug den visuelle editor til rene stilændringer, og gem chatprompts til strukturelle ændringer, der påvirker flere filer.
• Bed løbende Lovable om at forklare en ændring, før den udføres, hvis du er usikker på konsekvensen. Et enkelt spørgsmål koster typisk færre kreditter end at rulle en fejlslagen ændring tilbage bagefter.
• Opret et separat testprojekt til eksperimenter, og hold produktionsprojektet i ro, når du afprøver en risikabel idé som en større omskrivning af databasestrukturen.

Ingen af disse vaner kræver, at du er erfaren udvikler. De handler mest om at behandle AI’en som en samarbejdspartner, der har brug for klare instrukser og feedback, frem for et automatisk system, der altid rammer plet første gang.

Lovable sammenlignet med andre AI-appbyggere

Lovable er langt fra alene i kategorien. Vercels v0 gik i august 2026 fra at være en intern GUI-app-builder til at tilbyde en offentlig, “headless” API, hvor udviklere sender prompts direkte til v0’s agent og får en kørende dev-server og preview-URL tilbage. v0 bruger en firelaget model-prisstruktur (Mini, Pro, Max og Max Fast) og har et gratis niveau med 5 dollars i kreditter om måneden og en grænse på syv beskeder om dagen, mens den billigste betalte plan, Plus, koster 30 dollar pr. bruger om måneden.

Forskellen i praksis er, at Lovable fra start er bygget omkring en fuld stack med Supabase som fast backend-partner, mens v0 historisk har været tættere knyttet til Vercels egen infrastruktur og Next.js-økosystemet. Har du brug for database og login ud af boksen uden selv at vælge en backend-udbyder, er Lovable typisk det hurtigste valg. Skal appen derimod deployes direkte ind i en eksisterende Vercel-opsætning, kan v0’s nye API være det mere naturlige valg. Andre værktøjer som Replit og bolt.new konkurrerer i samme kategori, men da hverken Lovable, Replit eller bolt.new offentliggør direkte sammenlignelige forbrugstal, bør du teste dem selv på et lille projekt, før du vælger en fast platform til et større produkt.

En praktisk måde at vælge på er at bygge det samme lille projekt, for eksempel ventelisten fra denne guide, i to af værktøjerne og sammenligne, hvor meget tid du reelt bruger på at rette fejl bagefter. Den metrik siger ofte mere om, hvilket værktøj der passer til din arbejdsstil, end en liste over funktioner gør. Nogle udviklere ender med at bruge Lovable til det første udkast og derefter flytte koden over i deres foretrukne editor, når projektet vokser forbi et par sider og en enkelt database-tabel.

Du kan læse mere om Lovables fulde prisstruktur på lovable.dev/pricing og finde teknisk dokumentation til integrationer på docs.lovable.dev. Supabases officielle dokumentation, som dækker RLS-politikker og Edge Functions i detaljer, ligger på supabase.com/docs. Vil du følge med i Lovables egne opdateringer, ligger nyhederne på lovable.dev/blog, mens Vercels annonceringer om v0 findes på vercel.com/blog.

Ofte stillede spørgsmål

Skal jeg kunne kode for at bruge Lovable?
Nej. Du kan bygge og deploye en fungerende app udelukkende gennem prompts og den visuelle editor. Kodekendskab bliver først vigtigt, hvis du vil finjustere detaljer eller fejlfinde noget, AI’en ikke selv kan løse.

Hvor mange kreditter bruger et typisk projekt?
Det afhænger af projektets kompleksitet og størrelsen på dine prompts. Et lille projekt som venteliste-appen i denne guide kan typisk gennemføres inden for Free-planens daglige kvote, hvis du deler arbejdet over et par dage.

Kan jeg flytte mit projekt væk fra Lovable senere?
Ja. Fordi projektet er en almindelig Vite- og React-kodebase synkroniseret til GitHub, kan du klone repoet og fortsætte udviklingen i en hvilken som helst editor uden Lovable.

Er mine data sikre, hvis jeg bruger Free-planen?
Projekter på Free er som udgangspunkt offentlige. Har du følsomme data eller forretningslogik, bør du enten holde projektet privat via en betalt plan eller undgå at lægge følsom information i det, før du opgraderer.

Hvad er forskellen på Pro og Business?
Pro og Business har samme grundlæggende kreditniveau, men Business tilføjer single sign-on, rollestyring, mulighed for at fravælge AI-træning på dine data som standard og bedre understøttelse af interne, ikke-offentlige projekter.

Kan Lovable erstatte et helt udviklerteam?
Til tidlige MVP’er og enkle interne værktøjer, ja. Til komplekse produkter med avanceret forretningslogik, høje sikkerhedskrav eller store mængder brugerdata er Lovable et godt udgangspunkt, men bør suppleres med en udvikler, der kan gennemgå og finjustere koden.

Hvilke sprogmodeller bruger Lovable under motorhjelmen?
Det oplyser Lovable ikke offentligt som af september 2026. Platformen præsenteres som en samlet AI-agent, uden at specifikke modelnavne eller -versioner nævnes i den officielle dokumentation.

Kan jeg vælge, hvor mine data lagres geografisk?
Ja, gennem Supabase kan du vælge en specifik region, når du opretter databaseprojektet. Vælger du en europæisk region, ligger data som udgangspunkt inden for EU, hvilket er relevant, hvis appen behandler persondata om danske eller andre europæiske brugere.

Hvad sker der, hvis jeg løber tør for kreditter midt i et projekt?
Du kan fortsætte arbejdet, når de daglige build-kreditter nulstilles, købe ekstra kreditter som et engangstilkøb, eller opgradere til en plan med et højere månedligt loft og kredit-rollover. Selve projektet og koden forsvinder ikke, selvom kreditterne er brugt op.