Kan du bygge en SaaS med AI alene? Et ærligt svar

Ja, du kan bygge en SaaS med AI alene så længe der er tale om en prototype: en app med login, database og de skærme der viser idéen. Et produkt som kunder betaler for hver måned, kræver mere end kode. Abonnementsbetaling, moms, adskillelse mellem kunder, GDPR, drift og support er de dele AI-værktøjerne ikke tager ansvar for, og det er typisk der AI-byggede SaaS-projekter går i stå.

Jeg udvikler software for virksomheder og har derfor en interesse i svaret. Jeg skriver også, hvornår du roligt kan fortsætte alene.

Den korte version: hvad AI klarer, og hvad det ikke klarer

Min tommelfingerregel: AI kan bygge alt det en bruger ser. Det en bruger ikke ser, men stoler på, kræver at nogen forstår koden og tager ansvar for den. Det gælder især at betalingen går igennem, at data er adskilt, og at der findes en backup der virker.

Har du allerede en prototype, så start med min guide til at gøre en AI-app klar til produktion. Her handler det om det der kommer oveni når appen også skal være en abonnementsforretning.

Hvad AI-værktøjerne faktisk er gode til

Lovable, Bolt, v0 og Cursor kan på få timer gøre en beskrivelse til en app du kan klikke rundt i. Det er et stort skifte. Før skulle du bruge penge på en udvikler for at se om idéen holdt. Nu kan du vise en fungerende prototype til potentielle kunder og høre om de vil betale før du har brugt mere end et abonnement. Hvis du er i tvivl om værktøjet, har jeg sammenlignet Lovable, Bolt, v0 og Replit ud fra hvor let koden er at bygge videre på.

"Alene" kan dog betyde to ting. Det kan være en founder uden teknisk baggrund der prompter sig frem. Eller det kan være en udvikler der bruger AI som værktøj. Det her indlæg handler mest om det første. Forskellen er at en udvikler ved hvad der skal spørges om og kan vurdere svaret.

AI-værktøjer bygger det du beder om, og ikke ret meget andet. Problemet er at du ikke beder om det du ikke ved findes: håndtering af en betaling der fejler på dag 31, et testet gendannelsesforløb for databasen eller en regel der sikrer at én kunde aldrig ser en anden kundes data. Værktøjet siger heller ikke nej. Det bygger gerne en betalingsside til en app der ikke er klar til at tage imod penge.

Det en SaaS kræver ud over koden

Her er de fem områder der typisk mangler i AI-byggede SaaS-projekter. Ingen af dem kan ses i en demo.

Abonnementsbetaling og fejlede betalinger

Den første betaling er nem. Med Stripe Checkout kan du tage imod et kort på en eftermiddag, og flere AI-værktøjer tilbyder at sætte det op for dig. Det svære er alt det der sker bagefter: kortet udløber, betalingen fejler, kunden opgraderer midt i måneden, opsiger eller vil have pengene tilbage.

Stripe forsøger selv at trække en fejlet betaling igen. Ifølge Stripes dokumentation om automatiske genforsøg er den anbefalede standard 8 forsøg inden for 2 uger. Din app skal dog selv lytte efter beskeder fra Stripe (webhooks) og beslutte hvad der sker med kundens adgang når abonnementet ender som ubetalt, sat på pause eller opsagt. Lytter appen ikke, beholder kunder adgangen uden at betale, eller mister den selvom de har betalt.

Mit råd er at lægge så lidt af betalingslogikken som muligt i din egen kode. Brug Stripes færdige betalingssider og kundeportal, eller en løsning som Paddle der optræder som sælger over for kunden. Så skal din app kun slå adgang til og fra. Prismodeller og betalingsflow er beskrevet mere bredt i min guide til at bygge en SaaS fra idé til betalende kunder.

Moms, fakturaer og bogføring

Sælger du til privatpersoner i andre EU-lande, skal du som dansk virksomhed opkræve moms efter kundens land når dit samlede salg af digitale ydelser til forbrugere i andre EU-lande overstiger 10.000 euro om året. Momsen kan indberettes samlet via EU's One Stop Shop-ordning (OSS). Sælger du til virksomheder i andre EU-lande, gælder typisk omvendt betalingspligt, og så skal du kontrollere at kundens momsnummer er gyldigt.

Bruger du almindelig Stripe Billing, er du selv sælger og har selv ansvaret for momsen. Stripe kan beregne den for dig mod betaling. Vælger du en løsning der optræder som sælger (merchant of record), fx Paddle eller Stripes egen Managed Payments, tager den det ansvar, typisk mod et højere gebyr. Spørg en revisor før du vælger. En AI-genereret fakturaskabelon gør ikke momsen rigtig.

Adskillelse mellem kunder

I en B2B-SaaS har hver kunde, typisk en virksomhed, sine egne data, og kundens medarbejdere må kun se dem. Det kaldes multi-tenancy. I AI-byggede apps sker adskillelsen ofte kun i brugerfladen: listen viser kun din virksomheds data, men databasen udleverer gerne det hele hvis nogen spørger direkte.

Supabase skriver selv at en tabel uden adgangsregler (Row Level Security) kan læses og ændres af alle roller med adgang til den. Og det er ikke kun et Supabase-problem. Veracode testede kode fra over 100 sprogmodeller i 2025 og fandt at 45 % af kodeeksemplerne fejlede deres sikkerhedstest. De typiske fund har jeg samlet i oversigten over sikkerhedshuller i AI-genereret kode.

I B2B er et læk mellem to kunder ikke en fejl du retter i næste version. Det kan koste dig begge kunder og dit omdømme i branchen.

GDPR og databehandleraftaler

Når virksomheder lægger deres kunders eller medarbejderes persondata ind i din SaaS, er du som regel databehandler, og kunden er dataansvarlig. Så kræver GDPR artikel 28 en databehandleraftale mellem jer. Datatilsynet har en standardaftale og en vejledning om valget mellem dansk og EU-skabelon.

B2B-kunder vil spørge hvor data ligger, hvilke underleverandører du bruger (hosting, e-mail, AI-API'er), og hvordan data slettes når de opsiger. Et AI-værktøj kan skrive en privatlivspolitik, men det ved ikke hvor dine data faktisk ender. Jeg er udvikler, ikke jurist, så få rådgivning hvis du behandler følsomme oplysninger.

Drift, backup og support

En SaaS er et løfte om at produktet også virker i morgen. Nogen skal få besked når siden er nede, teste at backuppen kan gendannes, opdatere pakker når der kommer sikkerhedsrettelser, og svare på supportmails. Det arbejde stopper ikke så længe produktet har kunder.

Det er også her prompting bliver risikabelt. At prompte en rettelse ind i en prototype er harmløst. At prompte en rettelse direkte ind i den kode betalende kunder bruger, sent om aftenen og uden test, er noget helt andet.

Hvornår du skal have en udvikler med, og hvornår ikke

Du har brug for en udvikler, eller i hvert fald en grundig gennemgang, når et af disse punkter passer på dig:

• Du skal til at tage imod den første betaling.
• Flere virksomheder skal bruge det samme system med hver deres data.
• En B2B-kunde beder om en databehandleraftale eller spørger til sikkerhed.
• Appen skal tale med andre systemer eller køre opgaver i baggrunden.
• Hver ny prompt ødelægger noget der virkede før.

Flere advarselstegn har jeg samlet i 10 tegn på at du skal stoppe med at prompte og hyre en udvikler.

Du har til gengæld ikke brug for en udvikler endnu hvis ingen har betalt og du stadig er ved at finde ud af hvad produktet skal være. Brug pengene på at tale med kunder. Det samme gælder et internt værktøj for få kolleger uden persondata.

Og ærligt: en freelancer som mig er ikke svaret hvis produktet skal udvikles af et helt team på fuld tid fra dag ét. Så skal du ansætte eller bruge et bureau. Er koden allerede så rodet at du overvejer at starte forfra, så læs min beslutningsguide til at genskrive eller redde en AI-app først.

Sådan bygger du en SaaS med AI uden at bygge dig ind i et hjørne

Vil du bygge selv med AI så længe som muligt, så følg de her seks trin. De holder døren åben for en udvikler senere uden at du skal starte forfra.

1. Valider med prototypen før du bygger mere. Vis den til potentielle kunder, og find ud af om nogen vil betale. Hver funktion du bygger før det, er et gæt.
2. Læg koden i dit eget repository (kodearkiv) fra dag ét. Synkronisér til en GitHub-konto din virksomhed ejer. Så kan en udvikler læse koden, og du er ikke låst til ét værktøj.
3. Tegn datamodellen før de første betalende kunder kommer. Skriv ned hvilke tabeller der findes, og hvilke der tilhører en bestemt kunde. Det er billigt at ændre nu og dyrt at ændre med rigtige data.
4. Lån betalingen. Brug færdige betalingssider og kundeportal fra Stripe, eller en løsning som Paddle. Din kode skal kun lytte efter beskeder og slå adgang til og fra.
5. Få sikkerheden gennemgået før lancering. En scanner er en god start, men en person skal teste med to testkunder om den ene kan se den andens data.
6. Beslut hvem der har ansvaret for drift og support. Også selvom det er dig: overvågning, testet backup og en plan for når du holder ferie.

Den blandede model: du prompter, en udvikler holder fundamentet

For en del founders er det bedste svar ikke at vælge mellem AI og en udvikler. Du kan sagtens fortsætte med at bygge skærme og afprøve idéer i Lovable eller Cursor. Udvikleren ejer så de dele der er dyre at tage fejl af: datamodellen, adgangsreglerne, betalingen og driften.

Det kræver et par faste regler. Ændringer laves i en separat gren i Git, ikke direkte i den kode der kører. Alt der rører adgangsregler eller betaling, bliver gennemgået af udvikleren før det går i drift. Og de vigtigste flows, fx oprettelse, login og betaling, har automatiske test der kører ved hver ændring.

Det er den model jeg typisk anbefaler til en lille SaaS i starten. Den er som regel billigere end at få hele produktet bygget fra bunden fordi udvikleren kun bruger tid på fundamentet. Og du beholder farten fra AI-værktøjerne der hvor den gør mest gavn.

Næste skridt

Brug tjeklisten her før du åbner for betalende kunder. Mangler du flere punkter, er det et godt tidspunkt at få en udvikler til at kigge med.

Vil du have hjælp til fundamentet, kan du se hvordan jeg arbejder med SaaS-udvikling fra prototype til betalende kunder. Ved større opgaver starter jeg med et betalt forprojekt til fast pris, og du ejer koden fra første dag.

Ofte stillede spørgsmål

Hvor lang tid tager det at gøre en AI-prototype klar til betalende kunder?+

Det afhænger af prototypens størrelse og tilstand, men regn med uger frem for dage. En gennemgang af en mindre app tager typisk nogle dage. Sikkerhed, adskillelse mellem kunder, betaling og opsætning af drift tager derefter fra et par uger og op. Har appen mange roller, integrationer eller en rodet datamodel, tager det længere. Du kan først få et præcist estimat efter en gennemgang.

Ejer jeg koden hvis min SaaS er bygget med Lovable eller Bolt?+

Som regel ja, men tjek vilkårene for det værktøj du bruger. Det vigtigste er det praktiske ejerskab: at koden ligger i et repository din virksomhed ejer, og at appen kan køre uden for værktøjet. Bruger du værktøjets egen database eller hosting, så tjek også hvordan du får dine data ud hvis du skifter leverandør eller værktøjet ændrer pris.

Kan en AI-agent ikke klare support og drift for mig?+

Delvist. AI kan skrive udkast til supportsvar, opsummere fejllogs og foreslå rettelser, og det sparer tid. Men nogen skal stadig beslutte hvad der skal ske og stå inde for det over for kunden. At give en agent fri adgang til produktionsdatabasen er en reel risiko. Brug AI som hjælp til en person, ikke som erstatning for en.

Kan jeg bruge AI i selve produktet, ikke kun til at bygge det?+

Ja, og det kan være en stærk funktion, fx til at opsummere, kategorisere eller udfylde data. Husk at hvert kald til en sprogmodel koster penge, så prisen pr. kunde skal regnes igennem før du fastsætter din abonnementspris. Sender du persondata til OpenAI eller Anthropic, er de også underleverandører, og det skal fremgå af din databehandleraftale.