Hvad koster det at få en Lovable-app i produktion? Priser på audit og oprydning (2026)

Prisen på at få en Lovable-app i produktion ligger typisk på 8.000-30.000 kr. for en teknisk gennemgang, 15.000-40.000 kr. for at lukke de akutte sikkerhedshuller og 40.000-120.000 kr. for en fuld oprydning med test, backup og overvågning. Skal appen genskrives fordi fundamentet ikke holder, er du på niveau med en ny MVP, typisk 100.000-400.000 kr. Tallene er regnet ved 1.000 kr. i timen og gælder også for apps bygget med Bolt, v0, Replit eller Cursor.

Jeg tilbyder selv at gøre den slags apps klar til rigtige brugere, så læs tallene med det forbehold. Derfor har jeg også skrevet hvornår du slet ikke skal bruge penge på det endnu.

Den korte version: fire prisniveauer

Timerne er mine grove skøn for en erfaren udvikler. De forudsætter en mindre til mellemstor app med op til omkring 20 tabeller og 2-3 brugerroller. Jeg regner med 1.000 kr. i timen, fordi det ligger midt i spændet på 800-1.200 kr. som LønRadar angiver for senior it-freelancere i 2026. Det er et regnestykke og ikke min pris: betaler du 800 kr. i timen, trækker du 20 % fra.

Hvad der er en normal timepris for en freelanceudvikler, har jeg skrevet om i indlægget om timepriser i Danmark. Vil du se hvordan en AI-oprydning passer ind i resten af dit it-budget, så start med min oversigt over hvad softwareudvikling koster.

Hvad du får på hvert niveau

Niveauerne bygger oven på hinanden. Produktionsklar oprydning indeholder altså sikkerhedsoprydningen, og en genskrivning starter som regel med en gennemgang. Selve arbejdsgangen trin for trin har jeg beskrevet i guiden til at gøre en AI-prototype klar til rigtige brugere. Her handler det om hvad hvert trin koster, og hvad du får for pengene.

Gennemgang (audit): 8-30 timer

En gennemgang er det billigste sted at starte og det sted hvor flest penge bliver sparet. Udvikleren læser kode, database og opsætning igennem og giver dig en liste over problemer sorteret efter alvor, plus et estimat på at rette dem.

En god gennemgang svarer på tre spørgsmål. Kan brugere se data de ikke må se? Ligger der hemmelige nøgler et sted hvor de ikke hører hjemme? Og kan koden reddes, eller skal den skrives om? Svaret på det sidste flytter prisen mere end noget andet i dette indlæg.

Spændet afhænger mest af appens størrelse. En app med én brugertype og ingen betaling kan gennemgås på en dag. En app med roller, betaling og flere integrationer tager længere tid, fordi hver adgangsregel skal afprøves og ikke kun læses.

Sikkerhedsoprydning: 15-40 timer

Her lukkes de huller der kan koste dig data og tillid. Typisk drejer det sig om:

• Adgangsregler på alle tabeller, så hver bruger kun ser sine egne data. I Supabase, som Lovable ofte bruger som database, hedder det Row Level Security.
• Hemmelige nøgler der flyttes væk fra browseren og skiftes ud, hvis de har ligget offentligt.
• Login der gøres klar til rigtige brugere med bekræftelse af e-mail, nulstilling af adgangskode og korrekte omdirigeringer.
• Betaling der kontrolleres på serveren, så ingen kan give sig selv adgang ved at snyde i browseren.

Problemet er ikke særligt for ét værktøj. Da Veracode testede kode fra over 100 sprogmodeller, bestod 45 % af kodeeksemplerne ikke en sikkerhedstest, og nyere modeller klarede sig ikke bedre end ældre (Veracodes GenAI Code Security Report 2025). Regn derfor med at der er sikkerhedsarbejde, også selvom appen virker fint.

Produktionsklar oprydning: 40-120 timer

Her får appen det der skal til for at holde i måneder og år efter demoen. Tabellen viser hvor timerne typisk går hen.

Betaling står til 0 timer i den lave ende, fordi mange apps endnu ikke tager imod penge. Har du abonnementer med prøveperioder, opsigelser og afviste kort, ryger du mod den høje ende.

Den post der tit overrasker, er datamodellen. Har AI-værktøjet gemt de samme oplysninger tre steder, eller lagt flere kunders data i én tabel uden noget der skiller dem ad, skal det rettes før der kommer flere data ind. Det bliver kun dyrere jo længere du venter.

Genskrivning: 100-400 timer

Er datamodellen forkert, eller skal appen kunne langt mere om et år end i dag, kan det være billigst at bygge den forfra i et etableret framework som Laravel eller Next.js. Prisen ligger på niveau med en ny MVP, som jeg har regnet igennem i indlægget om hvad en MVP koster.

To ting gør en genskrivning af en AI-prototype billigere end et projekt helt fra bunden. Prototypen viser præcis hvad appen skal kunne, så afklaringen går hurtigere. Og skærme og flows er allerede afprøvet, så der går færre timer til design. Til gengæld kommer der timer oveni til at flytte brugere og data, hvis appen allerede er i brug.

Der findes også en mellemvej: du udskifter appen bid for bid, fx login og betaling først, mens resten kører videre. Prismæssigt lander den mellem oprydning og fuld genskrivning.

Det der driver prisen op eller ned

Det er sjældent antallet af skærme der afgør prisen. Det er hvor meget der står på spil, hvis noget går galt, og hvor rodet fundamentet er.

Brugerroller og datamodel flytter prisen mest. Hver rolle skal have sine egne regler, og hver regel skal afprøves med en bruger der ikke må se noget, ikke kun med én der må.

Hvilket værktøj appen er bygget med, betyder mindre end mange tror. Lovable, Bolt og v0 laver typisk en React-frontend med en hostet database bag, og problemerne ligner hinanden på tværs. Cursor er en anden sag, fordi det er en editor, og koden kan være skrevet i næsten hvad som helst. Der afhænger prisen mere af hvilken stack der er valgt, og hvor konsekvent den er brugt.

Din egen rolle tæller også. Kan du hurtigt svare på hvem der må se hvad, og hvad appen skal kunne om et halvt år, går der færre timer til afklaring.

Hvad det koster at vente

Det billigste er ikke altid at udskyde oprydningen. Tre regninger kommer, hvis appen går i luften som den er:

• Et datalæk. Har personoplysninger ligget åbent, kan du have pligt til at anmelde bruddet til Datatilsynet og forklare dine brugere hvad der er sket. Den regning kan ikke måles i timer.
• Prompts der går i ring. Når hver rettelse ødelægger noget andet, betaler du for credits og din egen tid uden at komme fremad.
• Oprydning med brugere om bord. Det er dyrere at rette datamodellen når der ligger rigtige data i den, fordi alt skal flyttes uden at noget går tabt.

Min tommelfingerregel er enkel: få lavet en gennemgang før du inviterer de første rigtige brugere, og få lukket sikkerhedshullerne før du tager imod betaling eller persondata.

Hvornår du ikke skal betale for det endnu

Det er ikke alle AI-apps der skal ryddes op i nu. Vent med pengene i disse situationer:

• Appen kører på testdata og bruges til at vise idéen frem for kunder eller investorer.
• 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. Slå adgangsreglerne til, og vent med resten.

En freelancer som mig er heller ikke det rigtige valg i alle tilfælde. Skal appen udvikles videre af et helt team på fuld tid fra dag ét, eller skal den samtidig have nyt design, nye tekster og markedsføring, passer et bureau eller en fastansat udvikler bedre.

Løbende udgifter når appen er i drift

Oprydningen er en engangsudgift. Bagefter kommer de faste udgifter:

• Hosting og database. Supabases gratisplan har ingen backup og sætter projekter på pause efter en uges inaktivitet. En app med rigtige brugere hører derfor til på Pro-planen, der koster fra 25 dollars om måneden ifølge Supabases prisside. Dertil kommer hosting af frontend, afsendelse af e-mails og eventuelle AI-kald.
• Værktøjet. Vil du blive ved med at bygge i Lovable eller Bolt, fortsætter abonnementet.
• Vedligehold. Pakker skal opdateres, og nye sikkerhedshuller skal lukkes. Groft skønnet går der 3-10 timer om måneden til en mindre app, mere hvis du samtidig bygger nyt. En fast aftale gør udgiften forudsigelig, og jeg har beskrevet de typiske modeller i indlægget om retainer og klippekort.

Næste skridt: sådan får du en pris du kan stole på

1. Få koden ind på GitHub. Lovable kan eksportere og synkronisere koden begge veje med GitHub (Lovables dokumentation om GitHub-integrationen), og det er den nemmeste måde at give en udvikler adgang uden at dele dit login.
2. Skriv på en halv side hvem der bruger appen, hvilke data den gemmer, og om den tager imod betaling.
3. Bestil en gennemgang til fast pris, før du siger ja til en oprydning. Det er samme logik som et forprojekt, og jeg har forklaret hvorfor en afgrænset discovery-fase betaler sig.
4. Bed om estimatet fordelt på dele som i tabellen ovenfor, så du selv kan vælge hvad der skal laves nu, og hvad der kan vente.
5. Luk sikkerhedshullerne først, og tag resten i faser.

På siden om gennemgang og oprydning af AI-apps kan du se hvordan jeg griber opgaven an. Du taler direkte med mig, der læser og skriver koden, og du ejer koden fra første dag.

Ofte stillede spørgsmål

Kan jeg få en fast pris på oprydningen uden en gennemgang først?+

Det kan du godt, men den bliver sjældent billig. Uden en gennemgang ved udvikleren ikke om datamodellen holder, eller hvor mange regler der mangler, så en fast pris må indeholde en stor buffer for det ukendte. En gennemgang til fast pris først giver et estimat med langt mindre luft i, og du kan bruge rapporten til at indhente flere tilbud.

Kan jeg blive ved med at bygge i Lovable efter en oprydning?+

Ja, i de fleste tilfælde. Med GitHub-synkronisering kan du og en udvikler arbejde i den samme kode. Aftal en klar arbejdsdeling: ændringer i database, adgangsregler og betaling går gennem udvikleren, mens du gerne må prompte tekster, layout og nye skærme. Ellers kan én prompt rulle en del af sikkerhedsarbejdet tilbage, uden at nogen opdager det.

Er det billigere at få appen ryddet op af en udvikler i udlandet?+

Timeprisen er ofte lavere, men den samlede regning er det ikke altid. Sikkerhedsarbejde forudsætter at udvikleren forstår hvad appen gør, og hvem der må se hvad, og det kræver tæt dialog. Vælger du den vej, så bed om en skriftlig rapport fra gennemgangen, kræv at koden ligger i dit eget GitHub, og få en du stoler på til at se resultatet efter.

Hvad sker der hvis gennemgangen finder et datalæk?+

Så lukkes hullet først, og nøgler der kan være lækket, bliver skiftet ud. Har personoplysninger været tilgængelige for uvedkommende, siger GDPR artikel 33 at bruddet skal anmeldes til Datatilsynet uden unødig forsinkelse og om muligt senest 72 timer efter at du har opdaget det. Undtagelsen er brud der sandsynligvis ikke udgør en risiko for de berørte. Det her er ikke juridisk rådgivning, så tal med en rådgiver ved tvivl.