AI-app til produktion: sådan gør du din Lovable-, Bolt- eller Cursor-app klar

At få en AI-app til produktion betyder at gøre en prototype fra Lovable, Bolt eller Cursor så sikker og stabil at rigtige brugere kan oprette sig, gemme data og betale uden at noget lækker eller går tabt. I praksis sker det i fem trin: en gennemgang af koden, sikkerhed, data, test og hosting med overvågning. De fleste prototyper kan reddes, men næsten ingen er klar som de er.

Jeg sælger selv den her ydelse, så læs med det i baghovedet. Det er også derfor guiden har et afsnit om hvornår du ikke har brug for en udvikler som mig.

Den korte version

Hvor meget arbejde din app kræver, afhænger af to ting: hvem der bruger den og hvilke data den rører. Min tommelfingerregel ser sådan ud:

Grænsen går altså ikke ved et bestemt antal brugere. Den går i det øjeblik en fremmed kan oprette en konto, eller appen gemmer data du ville være ked af at se lække. Fra da af er appen et produkt, og så skal den behandles som et.

Har du ikke styr på begreberne endnu, har jeg skrevet en introduktion til hvad vibe coding er og hvor grænserne går.

Hvorfor en AI-prototype sjældent er klar til rigtige brugere

Lovable, Bolt og Cursor er gode til at bygge noget der ser færdigt ud. De er lavet til at appen virker når du klikker rundt i den. De er ikke lavet til at modstå en der bevidst prøver at misbruge den. Det er hele forskellen på en prototype og et produkt.

Det største problem er næsten altid adgangskontrol: hvem må se og ændre hvilke data. Lovable og Bolt giver dig en indbygget backend eller kobler appen til et Supabase-projekt. Frontend taler direkte med databasen via en offentlig nøgle som ligger synligt i browseren. Sådan er Supabase designet, og det er fint, men kun hvis hver tabel har regler for hvem der må læse og skrive. Ifølge Supabases dokumentation om Row Level Security kan en tabel uden de regler læses og ændres af alle roller der har adgang til den, og i et typisk Supabase-projekt omfatter det alle med den offentlige nøgle.

Det er ikke teori. I 2025 gennemgik sikkerhedsforskeren Matt Palmer 1.645 apps bygget med Lovable og fandt 170 projekter hvor data kunne hentes uden tilladelse. Ifølge hans redegørelse for sårbarheden CVE-2025-48757 drejede det sig blandt andet om e-mails, telefonnumre, API-nøgler og oplysninger om betalinger.

Problemet er heller ikke begrænset til ét værktøj. Da Veracode testede kode fra over 100 sprogmodeller, indeholdt 45 % af kodeeksemplerne sårbarheder fra OWASP Top 10, og sikkerheden blev ikke bedre med større eller nyere modeller (Veracode, 2025 GenAI Code Security Report). Brudt adgangskontrol står i øvrigt øverst på OWASP Top 10 fra 2025, branchens standardliste over de største risici i webapps.

De svagheder jeg leder efter først

Når jeg gennemgår en AI-bygget app, starter jeg med de samme punkter fordi de giver mest risiko for mindst arbejde:

• Tabeller uden adgangsregler eller med regler der lukker alle ind.
• Hemmelige nøgler til fx Stripe, OpenAI eller e-mailudbydere der ligger i frontend-koden hvor alle kan læse dem.
• Logik der kun findes i browseren, fx at kun administratorer kan se en side, uden at databasen eller serveren tjekker det samme.
• Ingen automatiske test, så hver ny prompt kan ødelægge noget der virkede i går.
• Databaseændringer lavet direkte i et kontrolpanel uden historik, så ingen kan genskabe strukturen.
• Ingen backup, eller en backup der aldrig er blevet gendannet.
• Fejl der forsvinder i stilhed fordi ingen får besked når noget går galt.

Den fulde gennemgang med eksempler finder du i mit indlæg om de typiske sikkerhedsproblemer i AI-genereret kode.

Fem trin fra prototype til produktion

Rækkefølgen betyder noget. Der er ingen grund til at skrive test til kode du alligevel smider ud, og ingen grund til at vælge hosting før du ved om backend skal blive hvor den er.

1. Gennemgang: find ud af hvad du faktisk har

Første skridt er at få koden ud af værktøjet og ind i et repository (kodearkiv) som du selv ejer, fx på GitHub. De fleste af værktøjerne kan synkronisere med eller eksportere til GitHub, og med Cursor ligger koden allerede på din egen maskine. Uden versionsstyring kan du ikke se hvad der er ændret, og du kan ikke rulle tilbage.

Derefter kortlægger du appen:

1. Datamodellen: hvilke tabeller findes, hvordan hænger de sammen, og hvor ligger persondata.
2. Brugerroller: hvem må hvad, fx almindelig bruger, administrator og ejer af en organisation.
3. Integrationer: betaling, e-mail, AI-API'er og andre tjenester appen taler med.
4. Hemmeligheder: hvor ligger nøgler og adgangskoder, og hvem kan se dem.
5. Hvor koden kører: i browseren, i edge functions (små serverfunktioner hos Supabase) eller på en rigtig server.

Resultatet bør være en prioriteret liste i tre bunker: det der skal rettes før lancering, det der skal rettes den første måned, og det der kan vente.

Gennemgangen skal også svare på det store spørgsmål: skal appen reddes, eller er det billigere at genskrive dele af den? Mit udgangspunkt er at redde. Brugerfladen fra et AI-værktøj er ofte fin at arbejde videre med. Det er datamodellen og adgangslogikken der afgør sagen. Er de rodede, bliver alt ovenpå dyrt at rette. Jeg har skrevet mere om hvornår du skal genskrive og hvornår du kan redde en AI-app.

2. Sikkerhed: adgangskontrol, nøgler og login

Her ligger den største risiko, så det er her jeg bruger mest tid.

1. Slå Row Level Security til på alle tabeller, og skriv regler der matcher din forretning: en bruger ser kun sine egne rækker, en administrator ser kun sin egen organisation og så videre.
2. Test reglerne ved at prøve at hente en anden brugers data, både med et almindeligt login og helt uden login. Det er præcis det en angriber vil gøre.
3. Flyt hemmelige nøgler til serveren. Kun den offentlige nøgle må ligge i frontend. Supabases service_role-nøgle omgår alle regler og må aldrig nå browseren.
4. Tjek alt der handler om rettigheder, priser og betaling på serveren eller i databasen, ikke kun i brugerfladen.
5. Gør login færdigt: bekræftelse af e-mail, nulstilling af adgangskode, sessioner der udløber, og gerne tofaktorlogin for administratorer.
6. Begræns antallet af forsøg på login og formularer så ingen kan gætte adgangskoder eller fylde din database med spam.
7. Tjek at lagringsmapper til filer (buckets) ikke er offentlige medmindre de skal være det.

Bruger du Lovable med Supabase, kan du gå min sikkerhedstjekliste til Lovable og Supabase igennem punkt for punkt.

3. Data: struktur, migrationer, backup og GDPR

Når sikkerheden er på plads, handler det om at du ikke mister data og kan ændre databasen uden at gå i panik.

Gem databaseændringer som migrationer: små filer i dit repository der beskriver hver ændring. Så kan du genskabe databasen fra bunden, afprøve ændringer i et testmiljø og se hvem der ændrede hvad. Tilføj samtidig de begrænsninger AI-værktøjer ofte springer over, fx at en e-mail skal være unik eller at en ordre ikke kan eksistere uden en kunde.

Find ud af præcis hvilke backups dit abonnement indeholder: hvor ofte de tages, og hvor længe de gemmes. Gendan derefter en backup til et testmiljø. Så ved du at det virker før du får brug for det.

Gemmer appen persondata, er du dataansvarlig efter GDPR. Det betyder blandt andet:

• Du skal typisk have en databehandleraftale med de leverandører der behandler data for dig, fx database, hosting, e-mail og AI-udbydere.
• Vælg en serverregion i EU hvis platformen giver dig muligheden.
• Gem kun de data du faktisk bruger, og slet dem når de ikke længere skal bruges.
• Ved et brud skal du anmelde det til Datatilsynet uden unødig forsinkelse og om muligt inden 72 timer, medmindre det er usandsynligt at bruddet udgør en risiko for de berørte, jf. Datatilsynets vejledning om anmeldelse af sikkerhedsbrud. Logning gør det muligt at se hvad der faktisk blev eksponeret.

Sender appen data videre til en sprogmodel, så læs også om GDPR når du bruger AI-API'er. Jeg er udvikler, ikke jurist, så få en rådgiver til at kigge med hvis du behandler følsomme oplysninger.

4. Test: de flows der ikke må gå i stykker

Du behøver ikke teste alt. Find de tre til fem flows hvor en fejl koster penge eller tillid: oprettelse, login, appens kerneopgave, betaling og sletning af konto.

1. Skriv end-to-end-test (en robot der klikker appen igennem som en bruger, fx med Playwright) for netop de flows.
2. Skriv test af adgangsreglerne: kan bruger A se eller ændre bruger B's data? Svaret skal være nej, og det skal en test bevise.
3. Opret et staging-miljø (testmiljø) med sin egen database så du aldrig afprøver ændringer på rigtige brugeres data.
4. Lad testene køre automatisk ved hver ændring så du opdager fejl før brugerne gør.
5. Test manuelt på mobil og i et par forskellige browsere, især fejlbeskeder og tomme skærme.

Test er dobbelt vigtigt hvis du vil fortsætte med at prompte. En AI-ændring i én del af appen kan sagtens ødelægge en anden, og uden test opdager du det først når en bruger skriver til dig.

5. Hosting, drift og overvågning

Lovable og Bolt kan selv hoste din app, og for mange er det fint. Du skal overveje at flytte hvis du har brug for kontrol over serverregion, baggrundsjob, tungere forretningslogik eller integrationer til fx økonomisystemer. Min anbefaling er typisk at lade frontend blive og flytte den tunge logik til en rigtig backend, ofte Laravel. Det er ikke altid nødvendigt, og en Supabase-backend med ordentlige regler kan sagtens køre i produktion.

Uanset hvor appen kører, skal disse ting være på plads:

• Eget domæne med SSL, og e-mailafsendelse sat korrekt op (SPF og DKIM) så dine mails ikke havner i spam.
• Fejlovervågning (fx Sentry) der giver en person besked når noget går galt.
• Overvågning af oppetid og logs du kan søge i.
• En måde at rulle en udgivelse tilbage på hvis den skaber problemer.
• Et overblik over de løbende udgifter til database, hosting, e-mail og eventuelle AI-kald.

Bruger appen en sprogmodel, kan prisen pr. bruger løbe hurtigt op. Regn den igennem før lancering med min guide til hvad AI koster i drift.

Hvad koster det, og hvor lang tid tager det?

Det korte svar: det afhænger af appens størrelse og tilstand, og du kan først få en præcis pris efter en gennemgang. Det er også derfor jeg altid starter med et betalt forprojekt til fast pris før større opgaver: du får en prioriteret liste og et estimat, og du kender prisen på resten før du siger ja.

Det der driver prisen op eller ned:

• Antallet af tabeller, brugerroller og skærme.
• Hvor rodet datamodellen og adgangslogikken er.
• Om appen håndterer persondata, betaling eller følsomme oplysninger.
• Hvor mange integrationer der er, fx betaling, økonomisystem og AI-API'er.
• Om backend bliver i Supabase eller flyttes til en anden løsning.

Som groft skøn tager en gennemgang af en mindre app nogle dage. Oprydning og opsætning af drift tager typisk fra et par uger og op. En app med betaling, mange roller og integrationer tager længere tid. Det kan virke som meget for noget der allerede virker, men alternativet er at finde hullerne efter lancering hvor de koster tillid hos brugere du lige har fået.

Hvornår du ikke har brug for en udvikler

Det ville være nemt for mig at sige at alle AI-apps skal gennemgås. Det er ikke rigtigt. Du kan roligt vente i disse situationer:

• Appen er en prototype du bruger til at teste en idé på brugere eller vise investorer, og den kører på testdata.
• Du ved endnu ikke om nogen vil bruge den. Brug pengene på at finde ud af det først.
• Det er et internt værktøj for få kolleger uden persondata eller adgang til vigtige systemer. Slå stadig adgangsreglerne til, men drop resten indtil videre.
• Det du har brug for, er i virkeligheden en hjemmeside. Så er en almindelig hjemmesidebygger billigere og nemmere.

Omvendt er en freelancer heller ikke svaret hvis du skal have et helt udviklingsteam på fuld tid. Jeg er én person. Skal produktet udvikles af flere på fuld tid fra dag ét, så ansæt eller brug et bureau.

Er du i tvivl om hvor du står, har jeg samlet tegnene på at det er tid til at stoppe med at prompte og hyre en udvikler.

Efter lanceringen: sådan bliver appen ved med at virke

Arbejdet stopper ikke ved lanceringen. Afhængigheder skal opdateres, platformene ændrer sig, og brugerne finder fejl du aldrig selv ville have fundet.

Du kan sagtens fortsætte med at bruge AI-værktøjerne efter lanceringen. Du skal bare arbejde efter nogle få regler:

• Lav ændringer i en separat gren i Git, ikke direkte i den kode der kører.
• Lad testene køre før noget bliver udgivet, og gennemgå ændringer i adgangsregler manuelt.
• Afprøv i staging før produktion.
• Bed AI-værktøjet om små, afgrænsede ændringer i stedet for store omskrivninger.

Jeg går mere i detaljer med vedligehold af AI-genereret kode i et separat indlæg. Står du foran næste projekt og overvejer værktøj, kan du se min sammenligning af Lovable, Bolt og v0. Og skal appen være en abonnementsforretning, gennemgår jeg hvordan du bygger en SaaS med AI uden at bygge dig selv ind i et hjørne.

Næste skridt

Brug tjeklisten her til at se hvor langt din app er. Kan du sætte flueben ved det hele, er du tættere på produktion end de fleste.

Mangler du flere punkter, eller vil du bare have en anden til at kigge med, kan du læse om min ydelse AI-app til produktion. Der gennemgår jeg din app, retter det vigtigste og sætter den i drift, og du ejer koden hele vejen.

Ofte stillede spørgsmål

Skal jeg flytte væk fra Supabase for at komme i produktion?+

Nej, Supabase kan sagtens køre i produktion hvis adgangsreglerne, backup og overvågning er sat ordentligt op. Jeg anbefaler kun at flytte logik væk når appen får brug for noget Supabase ikke passer godt til, fx tunge baggrundsjob, komplekse integrationer eller forretningsregler der er svære at udtrykke i databasen. Ofte flytter man kun en del af logikken og beholder resten.

Kan AI-værktøjet ikke selv rette sikkerhedsfejlene?+

Delvist. Når du ved præcis hvad der er galt, kan værktøjet ofte rette det, og de indbyggede sikkerhedsscannere er en god start. Men en scanner kan ikke vide hvem der må se hvad i netop din forretning. Den kan se at der findes en regel, ikke om reglen er rigtig. Derfor skal reglerne testes af et menneske der forstår både koden og forretningen.

Hvad skal jeg sende til en udvikler for at få et tilbud?+

Send adgang til koden, gerne via GitHub, og en kort beskrivelse af hvem der skal bruge appen og hvilke data den gemmer. Nævn de integrationer du har, fx betaling og e-mail, og hvornår du gerne vil lancere. En skærmoptagelse på et par minutter hvor du viser appens vigtigste flows, sparer begge parter for mange spørgsmål.

Kan jeg fortsætte med at bygge i Lovable eller Bolt når en udvikler har ryddet op?+

Ja, så længe I aftaler hvordan ændringer kommer ind i koden. Den sikreste model er at alle ændringer, også dem fra AI-værktøjet, går gennem Git og bliver testet før de udgives. Ændringer i adgangsregler og betaling bør altid gennemgås af en udvikler. Så kan du bevare tempoet uden at miste det arbejde der gjorde appen sikker.