Sådan bygger du en SaaS: den komplette guide fra idé til betalende kunder

Hvordan bygger man en SaaS der ender med betalende kunder? Du validerer problemet hos rigtige kunder, afgrænser en lille første version, vælger en udbredt tech stack, bygger login, roller og betaling ordentligt fra start og lancerer til få kunder før du bygger mere. Rækkefølgen betyder mere end man skulle tro: de dyreste fejl opstår typisk når der bliver bygget før valideringen, eller når betaling og rettigheder bliver skubbet til "senere".

Jeg er freelanceudvikler og skriver guiden ud fra de opgaver, et SaaS-produkt kræver: udvikling, betaling, brugeroplevelse og drift. Hvert trin har sit eget, mere detaljerede indlæg, som jeg linker til undervejs.

Den korte version: otte trin fra idé til betalende kunder

Hele forløbet kan koges ned til otte trin fordelt på fire faser. Tabellen viser hvad du skal have ud af hvert trin og hvor det oftest går galt.

Trin 1-3 handler om at undgå at bygge det forkerte. Trin 4-6 handler om at bygge det rigtige, så det holder. Trin 7-8 handler om at få kunder og beholde dem. Er du helt ny i begreberne, så start med hvad SaaS er, forklaret uden teknisk jargon.

Fase 1: før du skriver en linje kode

De tre første trin koster næsten intet i udvikling, men de afgør om resten af pengene er givet godt ud. Det er også her jeg oftest anbefaler at sætte farten ned.

Trin 1: Forstå forretningsmodellen

En SaaS (software as a service) er software som kunderne betaler løbende for at bruge, typisk via et månedligt eller årligt abonnement. Du står for drift, opdateringer og sikkerhed. Modellen har en konsekvens som mange først mærker efter lanceringen: du tjener pengene hjem over måneder og år, ikke ved første salg. En kunde der opsiger efter to måneder, har måske ikke engang dækket det, det kostede at skaffe vedkommende.

Svar derfor på tre spørgsmål før du gør noget andet:

• Hvem betaler? En virksomhed, en afdeling eller en privatperson. Erhvervskunder betaler ofte mere og bliver længere, men salget tager som regel længere tid.
• Hvad betaler de for? Pr. bruger, pr. lokation, efter forbrug eller for en fast pakke.
• Hvorfor bliver de? Hvad får kunden ud af at fortsætte måned efter måned?

Der findes mange måder at tjene penge på en SaaS, og jeg har samlet dem i en oversigt over SaaS-forretningsmodeller og hvordan de tjener penge. Har du allerede en serviceforretning, er det ofte den korteste vej at gøre den til software, fordi du kender kunderne og problemet indefra. Det har jeg skrevet om i guiden til at produktisere din viden som SaaS. Overvejer du et smalt produkt til én branche, så se hvorfor vertikal SaaS ofte klarer sig godt i Norden. Og vil du bygge noget lille og profitabelt helt alene, gælder der andre regler som jeg gennemgår i indlægget om micro-SaaS.

Trin 2: Valider at nogen vil betale

Validering betyder at du skaffer bevis for at problemet er stort nok til at nogen vil betale for at få det løst. "Det lyder smart" er ikke bevis. Det er en høflig samtale.

Gode tegn er mere konkrete:

• Potentielle kunder beskriver problemet uden at du har nævnt det, og de bruger allerede tid eller penge på en dårlig løsning, fx regneark, manuelle processer eller et dyrt system de ikke er glade for.
• De vil gerne bruge en time på at se en klikbar prototype og give feedback.
• De vil forudbetale, skrive under på en hensigtserklæring eller være pilotkunde til en rigtig pris.

Det sidste er det stærkeste signal. Penge eller en underskrift siger mere end ti positive samtaler. Du kan validere med interviews, en landingsside, en prototype i Figma eller en manuel version af løsningen hvor du selv udfører det arbejde som softwaren senere skal automatisere.

Fremgangsmåden står trin for trin i guiden til at validere en SaaS-idé før du skriver kode. Mangler du stadig selve idéen, har jeg samlet SaaS-idéer til danske nicher og hvordan du tester dem.

Trin 3: Afgræns din MVP

En MVP (minimum viable product) er den mindste version af produktet som løser kerneproblemet godt nok til at nogen vil betale for den. Det er ikke en halvfærdig udgave af det endelige produkt, og det er heller ikke en prototype du smider ud. Er du i tvivl om forskellen, har jeg skrevet om hvad en MVP er, og hvad den ikke er.

Min tommelfingerregel er at en SaaS-MVP skal kunne fire ting: en kunde kan oprette sig, bruge den ene funktion der løser problemet, betale og få hjælp hvis noget går galt. Alt andet skal gøre sig fortjent til en plads. Det gælder også ting der føles obligatoriske, som avancerede rapporter, integrationer til fem systemer, mørk tilstand og en mobilapp.

En god metode er at skrive kundens forløb ned fra første besøg til første faktura og strege alt over som ikke er nødvendigt for at den første kunde får løst sit problem og betaler. Resten kommer på en liste over "senere". Hvordan du gør i praksis, står i guiden til at afgrænse en SaaS-MVP. Har du svært ved at sige nej, så brug min liste over funktioner din SaaS ikke har brug for ved lancering.

Hvem skal bygge din SaaS?

Når du har en afgrænset MVP, er næste spørgsmål hvem der skal bygge den. Der er fire realistiske veje, og ingen af dem passer til alle.

AI-værktøjer som Lovable, Bolt og Cursor er blevet gode til at lave noget der ser færdigt ud, og til validering kan det være et fint valg. Men en SaaS med rigtige kunder skal også have styr på adgangskontrol, adskillelse af kundernes data, betaling, backup og sikkerhedsopdateringer. Det er netop de dele der er sværest at se på overfladen og hvor fejl bliver dyre.

En freelanceudvikler som mig passer bedst til en afgrænset første version når du vil tale direkte med den der bygger, og omfanget skal kunne skrues op og ned. Du skal ikke vælge en freelancer hvis du har brug for design, brugerresearch, marketing og udvikling på samme tid. Så er et bureau bedre. Og er softwaren hele din forretning, og ved du at der skal udvikles på fuld tid i mange år, er en teknisk medstifter eller en fastansat udvikler det rigtige på længere sigt. En freelancer kan sagtens bygge første version og hjælpe den person godt i gang.

Vælg den vej der passer, men kræv altid at koden ligger i dit eget repository (kodearkiv) fra første dag og at du ejer rettighederne til den. Prisen afhænger mest af omfanget. Jeg har lavet en gennemgang af hvad det koster at få udviklet en SaaS så du kan sætte et realistisk budget.

Fase 2: de tekniske beslutninger der er dyre at fortryde

De fleste valg i en SaaS kan ændres senere. Nogle få kan ikke, eller kun med en større ombygning. Dem skal du træffe bevidst fra start, også selvom du ikke selv skriver koden.

Trin 4: Vælg en kedelig tech stack

Din tech stack er de programmeringssprog, frameworks og tjenester produktet bygges med. Mit råd er at vælge kedeligt: en udbredt stack med god dokumentation, et stort økosystem og mange udviklere der kan overtage hvis din første udvikler stopper. Det er ikke her du skal være nyskabende. Det skal produktet være.

Jeg arbejder selv primært med Laravel (PHP) i backend og React eller Next.js i frontend, så tag min anbefaling med det forbehold. Laravel har mange af de ting en SaaS skal bruge, indbygget eller som officielle pakker, blandt andet login, køer til baggrundsjob og Laravel Cashier til abonnementsbetaling via Stripe. Der findes andre fornuftige valg, fx Ruby on Rails, Django eller Next.js med en hostet database. Det vigtigste er at stacken er udbredt og at din udvikler kender den godt. Mine overvejelser står i min anbefaling af tech stack til SaaS.

Hosting hører med til samme beslutning. En ny SaaS har sjældent brug for en kompleks opsætning hos en af de store cloududbydere. En administreret platform hvor udgivelser, SSL-certifikater og backup er sat op for dig, er som regel nok i lang tid. Vil du sammenligne mulighederne, så se min gennemgang af hosting til SaaS.

Trin 5: Få kundekonti, roller og data rigtigt fra start

Næsten alle B2B-produkter har flere kunder i samme system, og hver kunde har flere brugere. Det kaldes multi-tenancy (flere lejere i samme software), og det rejser tre spørgsmål som er langt billigere at besvare før første linje kode end efter de første hundrede kunder:

1. Hvordan holdes kundernes data adskilt? Én fælles database med et kunde-id på hver række, én database pr. kunde eller noget midt imellem. Den fælles database er den mest almindelige og billigste at drive, men den kræver disciplin så en kunde aldrig kan se en andens data. Fordele og ulemper står i min forklaring af multi-tenant arkitektur.
2. Hvem må hvad? Ejer, administrator, almindelig bruger, måske en gæst eller en revisor. Selv hvis første version kun har to roller, skal koden være bygget så der kan komme flere. Se hvordan du designer brugerroller og rettigheder fra start.
3. Hvordan overholder du GDPR? Når dine kunder lægger persondata om deres medarbejdere eller kunder ind i dit system, er du typisk databehandler for dem, og så skal der være en databehandleraftale. Datatilsynet har en standardskabelon som mange bruger som udgangspunkt. Du skal også kunne eksportere og slette data og vide hvor dine underleverandører gemmer dem. De tekniske krav har jeg samlet i GDPR-tjeklisten til SaaS.

Det er ikke juridisk rådgivning, så tal med en rådgiver hvis du er i tvivl om din rolle. Og skal andre virksomheder kunne sælge dit produkt under eget navn, påvirker det også arkitekturen fra start. Det har jeg skrevet om i indlægget om white-label SaaS.

Fase 3: betaling, priser og moms

Trin 6: Få betaling og prissætning på plads

Byg aldrig betaling selv fra bunden. Brug en betalingsudbyder der håndterer kort, abonnementer, fornyelser, afviste betalinger og fakturaer. To af de mest brugte valg til SaaS er Stripe og Paddle. Med Stripe er du som udgangspunkt selv sælger og har ansvaret for moms. Paddle er såkaldt merchant of record: Paddle sælger formelt produktet til dine kunder og håndterer moms og afgifter for dig, mod et højere gebyr. Der findes også danske løsninger, og jeg har sammenlignet mulighederne i guiden til abonnementsbetaling i SaaS.

Moms bliver ofte overset. Sælger du til virksomheder i andre EU-lande, skal du som udgangspunkt ikke lægge moms på fordi kunden selv afregner den efter reglerne om omvendt betalingspligt. Sælger du til private, beskattes digitale tjenester i kundens land når dit samlede salg til private i andre EU-lande overstiger 10.000 euro om året. Til det kan du bruge EU's One Stop Shop-ordning og indberette det hele ét sted. Reglerne er beskrevet på EU's portal Your Europe, men tjek altid din konkrete situation med din revisor.

Prisen er et produktvalg, ikke kun et tal. Du skal beslutte om der betales pr. bruger, efter forbrug eller for en fast pakke og om du vil have freemium, en gratis prøveperiode eller betaling fra første dag. Mit råd til en ny B2B-SaaS er at tage betaling tidligt, også selvom prisen er lav. En betalende kunde giver dig bedre feedback end hundrede gratis brugere. Byg samtidig betalingen så priser og pakker kan ændres uden at kode skal skrives om, for din første pris er næsten aldrig din endelige.

Jeg har gennemgået de mest brugte prismodeller og hvordan du vælger og valget mellem freemium, prøveperiode og betaling fra dag ét i hver sit indlæg.

Fase 4: lancering og tiden efter

Trin 7: Lancér til få kunder og gør onboarding god

Vent ikke på at produktet er færdigt. Det bliver det aldrig. Lancér når MVP'en løser kerneproblemet, betalingen virker og du kan hjælpe kunderne hvis noget går galt. Start gerne med de pilotkunder du fandt under valideringen, og åbn derefter gradvist for flere.

Før du åbner, skal det basale være på plads: backup der er testet, overvågning af fejl og oppetid, vilkår og privatlivspolitik, en måde at få fat i dig på og et betalingsflow du har gennemspillet. Jeg har samlet en lanceringstjekliste med 30 punkter til SaaS som du kan gå igennem ugen før.

Den første tid efter en kunde har oprettet sig, afgør om kunden bliver. Mål hvor mange der når frem til det øjeblik hvor produktet løser deres problem første gang, og fjern alt der står i vejen. Det kan være et tomt dashboard, en for lang opsætning eller en import der ikke virker. Se mine 11 greb til bedre onboarding i SaaS.

Trin 8: Mål, lær og skaler

Når de første kunder betaler, skifter arbejdet karakter. Nu handler det om at forstå hvad der sker og prioritere ud fra det. De vigtigste tal er MRR (månedlig tilbagevendende omsætning), churn (andelen af kunder eller omsætning du mister pr. måned) og forholdet mellem hvad det koster at skaffe en kunde og hvad kunden er værd over tid. De er forklaret på dansk i SaaS-nøgletal: MRR, churn, LTV og CAC.

Kundeafgang har ofte tekniske årsager som er lette at overse: langsomme sider, fejl i betalingen der får kort afvist, manglende eksport eller e-mails der havner i spam. Jeg har samlet 10 tekniske årsager til at SaaS-kunder opsiger.

Skalering er sjældent det første problem. En velbygget SaaS på en udbredt stack kan typisk klare langt flere kunder end de fleste har det første år, og når flaskehalsene kommer, ligger de som regel i databasen eller i baggrundsjob, ikke i valget af framework. Byg til de kunder du har, og hold øje med tallene. Hvordan du griber det an når det bliver aktuelt, står i guiden til at skalere en SaaS teknisk.

Næste skridt: fra idé til første samtale med en udvikler

Det svære ved at bygge en SaaS er sjældent koden. Det er at bygge det rigtige, i den rigtige rækkefølge, og at holde første version lille nok til at komme ud til kunderne. Gå listen igennem før du kontakter en udvikler. Jo flere punkter du kan krydse af, jo mere præcist bliver det tilbud du får.

Mangler du nogle af svarene, er det helt normalt. Før større projekter laver jeg et betalt forprojekt til fast pris. Her afgrænser du og jeg sammen MVP'en, træffer de tekniske beslutninger og laver et estimat på resten. Du kan se hvordan jeg arbejder med udvikling af SaaS-produkter, fra forprojekt til lancering og videreudvikling.

Ofte stillede spørgsmål

Hvor lang tid tager det at bygge en SaaS?+

Det afhænger mest af hvor stramt MVP'en er afgrænset. En første version med én kernefunktion, få roller og standardbetaling er typisk et spørgsmål om måneder, mens mange integrationer, komplekse regler og flere brugertyper hurtigt forlænger forløbet. Den mest effektive måde at forkorte tiden på er at skære i omfanget, ikke at presse udvikleren. Et forprojekt giver dig et estimat på netop dit projekt.

Kan jeg bygge en SaaS uden at kunne kode?+

Ja. Mange SaaS-produkter er startet af folk der kender branchen og problemet, ikke koden. Du kan validere med no-code- og AI-værktøjer og derefter få en udvikler eller en teknisk medstifter til at bygge den version som rigtige kunder skal betale for. Din vigtigste opgave er at eje produktbeslutningerne: hvem kunden er, hvad der skal med og hvad der må vente.

Hvad koster det at drive en SaaS efter lanceringen?+

Løbende udgifter dækker typisk hosting, gebyrer til betalingsudbyderen, e-mailudsendelse, fejlovervågning, eventuelle licenser og tid til vedligehold og sikkerhedsopdateringer. Hosting er ofte en lille post i starten. Den største post er som regel udviklingstiden til rettelser og nye funktioner, så sæt et månedligt budget af til det fra første dag i stedet for at tage det som det kommer.

Skal min SaaS have en mobilapp fra start?+

Sjældent. En webapp der fungerer godt på mobilen, dækker de fleste behov i første version, især for erhvervskunder der primært arbejder ved en computer. En native app til iOS og Android betyder to ekstra platforme at vedligeholde og godkendelser i app-butikkerne. Vent til dine kunder efterspørger det og til du ved hvilke funktioner de faktisk bruger på farten.