10 tegn på at du skal stoppe med at prompte og hyre en udvikler til din Lovable-app

Det er tid til at hyre en udvikler til din Lovable-app, når hver ny prompt ødelægger noget andet, når appen skal håndtere rigtige penge eller persondata, eller når du ikke længere tør ændre noget før en demo. Indtil da er prompting ofte det billigste og hurtigste værktøj du har, og der er ingen grund til at stoppe for tidligt.

Jeg er selv freelanceudvikler og hjælper med at gøre AI-byggede apps klar til produktion, så læs listen med det i baghovedet. Derfor er der også et afsnit om hvornår du ikke skal hyre nogen. Listen gælder lige så meget for Bolt, Cursor, v0 og Replit som for Lovable.

Den korte version

Min tommelfingerregel: Kan du sætte kryds ved ét af de første fire tegn, og har appen rigtige brugere, så stop med at bygge nyt og få koden gennemgået. Tegn 5-10 er et regnestykke om tid og penge, ikke en akut risiko. Men tre eller flere af dem på én gang betyder som regel at prompting er blevet den dyre løsning.

Vil du se hele vejen fra prototype til drift, så har jeg skrevet en trinvis guide til at gøre din AI-prototype klar til rigtige brugere. Her holder jeg fokus på spørgsmålet om hvornår.

Fire tegn på at det haster

De første fire tegn har én ting til fælles: Fejlen kan koste dig penge, kunder eller en sag hos Datatilsynet, og du opdager den sjældent selv, før det er sket.

1. Du skal til at tage imod betaling

En Stripe-integration ser ofte rigtig ud i en AI-bygget app. Knappen virker, checkout åbner, og kunden betaler. Problemet ligger i det der sker bagefter. Et typisk mønster i genereret kode er at brugeren får adgang, fordi browseren lander på en "tak for dit køb"-side, ikke fordi Stripe har bekræftet betalingen. Den side kan alle åbne direkte.

Den rigtige vej er at din server modtager besked fra Stripe via en webhook (en automatisk besked mellem to systemer) og tjekker at beskeden faktisk kommer fra Stripe. Stripes dokumentation om webhooks skriver direkte at en angriber uden den kontrol kan sende falske beskeder og give sig selv adgang. Dertil kommer abonnementer der udløber, betalinger der fejler, og at den samme besked kan komme mere end én gang.

Sælger du enkeltstående produkter i lille skala, kan Stripes færdige betalingsside og et betalingslink række langt. Så snart adgang eller abonnementer afhænger af betalingsstatus, bør en udvikler have set flowet igennem.

2. Appen gemmer persondata eller kunders data

De fleste Lovable-apps bruger Supabase som database. Her er det Row Level Security (regler i databasen der bestemmer hvilke rækker hver bruger må se) der beskytter dataene. Supabases egen dokumentation er klar: En tabel uden de regler kan læses og ændres af alle der har adgang til API'et. AI-værktøjerne slår ofte reglerne til, men skriver dem tit så brede at alle indloggede brugere kan læse alt.

Du kan lave en simpel test selv: Opret to testbrugere, log ind som den ene, og prøv at åbne den andens data, fx ved at ændre et id i adresselinjen. Virker det, har du et problem.

Sker der et brud, skal du som dataansvarlig anmelde det uden unødig forsinkelse og om muligt inden 72 timer. Undtagelsen er hvis det er usandsynligt at bruddet medfører en risiko for de berørte (se Datatilsynet om anmeldelse af sikkerhedsbrud). De konkrete punkter du kan tjekke, har jeg samlet i tjeklisten til Lovable og Supabase før lancering.

3. Du har fundet nøgler eller hemmeligheder i koden

Alt hvad der ligger i frontend-koden, kan læses af alle der åbner browserens udviklerværktøjer. Det er fint for Supabases offentlige nøgle, som er lavet til formålet. Det er ikke fint for din OpenAI-nøgle, din hemmelige Stripe-nøgle eller Supabases hemmelige nøgle (service_role), som ifølge Supabase går uden om adgangsreglerne og aldrig må bruges i browseren.

Konsekvensen er konkret: Andre kan bruge din AI-konto på din regning eller læse hele databasen. Det er også det eneste punkt på listen hvor du selv kan gøre det vigtigste i dag. Deaktivér de lækkede nøgler, lav nye, og læg ikke de nye samme sted. Det er ikke nok at flytte de gamle, hvis de allerede er kopieret. At flytte logikken der bruger nøglerne over på serveren er derimod udviklerarbejde. Flere af de typiske huller står i oversigten over sikkerhedshuller i AI-genereret kode.

4. Data forsvinder eller bliver forkert

Symptomerne er tit små: En brugers indstillinger nulstilles, poster bliver dubleret, eller en kolonne forsvinder efter en prompt. Årsagen er ofte at AI-værktøjet har ændret databasens struktur som en del af en helt anden opgave, eller at to dele af koden skriver til det samme felt.

Det vigtige spørgsmål er: Har du en backup, og har du prøvet at gendanne den? Historikken i værktøjet ruller typisk kun koden tilbage, ikke dataene i databasen. Tjek hvilke backups din databaseudbyder faktisk tager på din plan, og hvor langt tilbage de går. Datatab er den ene fejl du ikke kan prompte dig ud af.

Fire tegn på at prompting er holdt op med at virke

De næste fire tegn er ikke farlige på samme måde. De handler om at du bruger mere og mere tid på at holde appen kørende og mindre på at gøre den bedre.

5. Hver prompt ødelægger noget andet

Du retter login, og så går oversigten i stykker. Du retter oversigten, og så bliver mails ikke sendt. Det sker fordi AI-værktøjet kun arbejder med en del af koden ad gangen, og fordi der ikke er automatiske tests der siger fra, når noget andet går i stykker. Jo større appen bliver, jo oftere ændrer værktøjet noget uden at kunne se konsekvensen.

Har du prøvet at rette den samme fejl tre gange, og flytter den sig bare rundt, så stop. Fjerde forsøg bliver sjældent bedre, og hvert forsøg efterlader lidt mere rod som næste person skal rydde op i.

6. Fejl dukker kun op når flere bruger appen samtidig

Alt virker når du tester alene, men det går galt den dag 30 personer opretter sig efter et nyhedsbrev. Typiske årsager er at to brugere ændrer de samme data på én gang, at appen henter alle rækker fra databasen og lader browseren sortere dem, manglende indeks på tabeller, eller at en ekstern tjeneste (fx en AI-model eller en mailudbyder) begrænser hvor mange kald du må lave.

Den slags fejl er svære at beskrive i en prompt, fordi du ikke selv kan genskabe dem. En udvikler kan simulere belastning, læse logfiler og finde årsagen.

7. Du tør ikke ændre noget før en demo

Holder du vejret før hver prompt dagen før et vigtigt møde, mangler du to ting: et testmiljø (staging) der er adskilt fra den rigtige app, og en sikker vej tilbage. Værktøjets historik hjælper på koden, men har en prompt ændret databasen, får du ikke dataene tilbage ved at gendanne koden.

En udvikler sætter et testmiljø op, gør GitHub til den samlede kopi af koden og laver en fast måde at udgive ændringer på. Det kræver ikke at du forlader værktøjet. Lovable kan synkronisere begge veje med GitHub, så ændringer fra en udvikler ender i dit projekt igen (Lovables dokumentation om GitHub).

8. Rettelser fylder mere end nye funktioner

Kig på den seneste måned. Hvor meget af din tid og dine credits gik til nye funktioner, og hvor meget gik til at rette det der var gået i stykker? Når rettelserne fylder mest, er værktøjet blevet en dyr måde at vedligeholde kode på.

Lav et groft regnestykke: dine egne timer ganget med hvad din tid er værd, plus abonnement og ekstra credits, sammenlignet med nogle dages udviklerhjælp. Det falder ikke altid ud til udviklerens fordel. Bruger du et par hundrede kroner ekstra om måneden og har ingen brugere endnu, så byg videre. Hvad det koster at lade AI-kode vokse uden opsyn i længere tid, har jeg skrevet om i indlægget om vedligehold af AI-genereret kode.

To tegn på at appen er vokset fra værktøjet

De sidste to tegn er egentlig gode nyheder. De betyder at appen er ved at blive en forretning.

9. Appen skal tale med andre systemer eller køre ting i baggrunden

Det kan være e-conomic, Dinero, HubSpot eller et bookingsystem. Eller opgaver der skal køre uden at nogen klikker: påmindelser om natten, fakturaer den første i måneden, synkronisering af data. AI-værktøjerne er stærkest i det du kan se på skærmen. Logik der kører i baggrunden, er der hvor de bliver svage.

Resultatet bliver ofte logik spredt ud over små serverfunktioner, frontend-kode og regler i databasen, uden at nogen har overblikket. Og fejlene sker lydløst om natten. Én simpel integration, som at sende en mail via en mailtjeneste, kan sagtens promptes. Når penge eller data flyder automatisk mellem systemer, bør en udvikler designe det med logning og nye forsøg når noget fejler.

10. Kunder eller investorer stiller spørgsmål du ikke kan svare på

En erhvervskunde sender et spørgeskema om sikkerhed eller beder om en databehandleraftale. En investor spørger hvem der ejer koden, og hvor den kører. Og du opdager at du ikke kan forklare hvordan din egen app virker.

Det er her appen går fra eksperiment til en del af din forretning. Du behøver ikke forstå hver linje, men nogen du stoler på, skal. Og du skal kunne svare på fire ting: hvor data ligger, hvem der har adgang, hvad der sker hvis appen går ned, og hvordan du gendanner den.

Hvornår du ikke skal hyre en udvikler endnu

En udvikler er ikke altid svaret. Jeg vil hellere sige det her end sælge dig noget du ikke har brug for.

• Du validerer stadig idéen. Ingen betaler, og ingen afleverer persondata. Så er prompting det rigtige værktøj, og pengene er bedre brugt på at tale med mulige kunder.
• Det er et internt værktøj for få personer uden følsomme data, og det gør ikke noget at det går ned en gang imellem.
• Budgettet rækker til et par dage. Det kan dække de akutte rettelser, men det gør ikke en ustabil app stabil. Få i stedet en gennemgang der fortæller hvad der haster, og byg selv videre på resten.
• Du vil have nogen til at prompte for dig. Skal der bare køres hurtigere i Lovable, er en freelanceudvikler som mig en dyr løsning. En erfaren no-code-bygger passer bedre.
• Problemet er design eller tekst. Så har du brug for en designer eller en tekstforfatter, ikke en udvikler.

Hvad der sker når en udvikler kommer ind

Det behøver ikke være en stor omvæltning. Sådan ser forløbet typisk ud:

1. Gennemgang. Udvikleren læser koden, databasestrukturen, login, betaling og nøgler. Resultatet er en prioriteret liste: skal rettes nu, bør rettes, kan vente.
2. Beslutning. Skal appen reddes eller skrives om? Ofte kan store dele bevares. Kriterierne står i beslutningsguiden om at genskrive eller redde en AI-app.
3. Akutte rettelser. Nye nøgler, strammere adgangsregler, betaling via bekræftede webhooks og en backup der er prøvet af.
4. Fundament. GitHub som samlet kopi, et testmiljø, tests på de vigtigste flows (oprettelse, betaling og appens kernefunktion) og logning af fejl.
5. Arbejdsdeling. Du kan godt blive ved med at prompte, typisk på skærmbilleder og tekster. Aftal bare hvilke dele udvikleren ejer, så en prompt ikke stille og roligt fjerner en rettelse.

Du kan gøre forløbet hurtigere og billigere ved at forberede dig lidt.

Næste skridt: fra prompts til en app du kan stole på

Gå de ti tegn igennem og tæl. Ét af de første fire: få koden gennemgået før næste lancering. Tre eller flere af de øvrige: regn på hvad dine rettelser koster dig i dag. Ingen af dem: byg videre, og kom tilbage til listen når appen får betalende brugere.

Hvordan jeg arbejder med AI-byggede apps, kan du se på siden om at få din AI-app i produktion. Du skriver direkte med den udvikler der skal læse koden, du ejer koden fra dag ét, og du får svar inden for én hverdag.

Ofte stillede spørgsmål

Hvad koster det at få en udvikler til at overtage en Lovable-app?+

Det afhænger mere af kodens tilstand end af hvor mange skærme appen har. En gennemgang kan som regel prissættes fast, fordi omfanget er kendt på forhånd. Selve rettelserne afhænger af hvad gennemgangen finder. Derfor starter jeg med et forprojekt til fast pris, så du kender prisen på næste skridt, før du forpligter dig til mere. Hvordan jeg prissætter, kan du se på siden om priser.

Kan jeg fortsætte med at bruge Lovable, når en udvikler er med?+

Ja. Lovable synkroniserer begge veje med GitHub, men kun med én branch (en gren af koden), som standard hovedbranchen. En god arbejdsgang er derfor at udvikleren arbejder i sin egen branch og fletter ændringerne ind, når de er testet, mens du prompter videre i Lovable. Aftal samtidig hvem der ejer hvad, fx at du tager skærmbilleder og tekster, og udvikleren tager database, betaling og adgangsregler.

Skal min app skrives om fra bunden?+

Sjældent helt, men det ved ingen før koden er læst. Ofte kan skærmbillederne bevares, mens datamodel, adgangsregler og betaling rettes eller bygges om. En genskrivning er typisk kun billigere, hvis datamodellen er forkert fra starten, eller hvis appen skal kunne noget helt andet end prototypen blev bygget til.

Hvor lang tid tager det at gøre en AI-bygget app klar til rigtige brugere?+

Gennemgangen er den hurtige del og tager typisk få dage. De akutte rettelser af nøgler, adgangsregler og betaling kan ofte klares på kort tid, mens fundamentet med testmiljø, tests og overvågning afhænger af appens størrelse. Som groft skøn skal du regne i uger, ikke dage, hvis appen allerede har betalende brugere.

Bruger udviklere ikke bare selv AI?+

Jo, de fleste gør, og det er en fordel for dig. Forskellen er at en udvikler kan læse og vurdere det AI'en skriver, opdage når den tager en genvej, og vide hvilke dele der skal skrives omhyggeligt i hånden. AI gør udvikleren hurtigere. Den erstatter ikke vurderingen af om koden er sikker og holdbar.