10 faldgruber ved SaaS-udvikling og hvordan du undgår dem

De dyreste SaaS-fejl er sjældent tekniske. De fleste handler om at bygge for meget, før nogen har sagt ja til at betale, at sætte prisen for lavt og at glemme, at betaling, drift og salg også er en del af produktet. Her er ti faldgruber og forslag til at undgå dem.

[PLACEHOLDER: Simon bekræfter at de ti punkter er fejl han selv har lavet med Remotefitness. Punkter der ikke passer, skiftes ud med fejl han faktisk lavede. Tilføj én sætning om hvad Remotefitness er, og hvilke tal der må deles.]

Som udvikler er det fristende at løse ethvert problem med mere kode. Flere af fejlene herunder handler om netop det, så læs listen som en tjekliste til din egen plan.

Den korte version: de ti fejl på én side

Tabellen er oversigten. Herunder gennemgår jeg hver fejl, grupperet efter hvornår i forløbet den typisk opstår. Vil du se hele forløbet fra idé til drift, kan du læse fra idé til SaaS: valg og prioriteringer.

Fejl før første linje kode

1. Jeg byggede før jeg havde valideret idéen

Det er udviklerens klassiske refleks: du får en idé, kan se løsningen for dig og begynder at bygge samme aften. Problemet er at koden ikke fortæller dig om nogen vil betale. Det kan kun kunderne. Hver uge du bygger uden at tale med dem, er en uge hvor du kan være på vej i den forkerte retning.

Det er ikke kun en mavefornemmelse. CB Insights gennemgik i 2026 431 venturefinansierede startups der var lukket, og dårligt product-market fit (at produktet ikke rammer et reelt behov i markedet) var en af årsagerne i 43 % af dem. Det var større, finansierede virksomheder, men mekanismen er den samme for et lille SaaS-produkt.

Min anbefaling er at tale med mindst ti mulige kunder før du skriver kode. Spørg hvordan de løser problemet i dag, og hvad det koster dem i tid eller penge. Det stærkeste signal er en forudbetaling eller en aftale om at blive testkunde til en konkret pris, ikke et høfligt "det lyder spændende". Metoderne har jeg samlet i en guide til at validere en SaaS-idé.

[PLACEHOLDER: Simons egen version. Hvor længe byggede du på Remotefitness før du talte med de første mulige kunder, og hvad viste samtalerne? 30-50 ord.]

2. Den første version var for stor

En MVP (en første, enkel version af produktet) skal teste én antagelse: at en bestemt gruppe vil betale for at få løst et bestemt problem. Den skal ikke vise alt hvad du kan bygge. Alligevel ender mange første versioner med brugerprofiler, rapporter, integrationer og en stor administrationsflade før den første kunde har logget ind.

Hver ekstra funktion forsinker lanceringen. Den gør det også dyrere at skifte kurs når de første kunder fortæller dig hvad de egentlig har brug for, og det gør de altid.

Skriv den ene sætning produktet skal leve op til, fx "en håndværker kan sende et tilbud til en kunde på under fem minutter". Skær derefter alt væk som ikke er nødvendigt for den sætning, og sæt resten på en liste til senere. Sådan holder jeg selv omfanget nede i min MVP-proces uge for uge.

[PLACEHOLDER: Hvilke funktioner var med i Remotefitness' første version som du i dag ville have ventet med? 30-50 ord.]

3. Målgruppen var for bred

"Til alle der ..." er et dårligt udgangspunkt for en SaaS. Jo bredere målgruppen er, jo mere generisk bliver dit budskab, og jo sværere er det at finde de steder hvor kunderne samles. Du ender med at konkurrere med store, generelle værktøjer på deres hjemmebane.

En smal målgruppe føles som en begrænsning, men den gør næsten alt lettere. Du ved hvilke ord kunderne bruger, hvilke systemer de i forvejen har, og hvor du kan møde dem. Du kan altid udvide senere når du har fodfæste.

Et godt tjek: kan du nævne fem konkrete virksomheder eller personer i målgruppen og skrive til dem i morgen? Hvis ikke, er målgruppen sandsynligvis for bred eller for svær at nå.

[PLACEHOLDER: Hvem var Remotefitness' målgruppe i starten, og blev den smallere eller bredere undervejs? 20-40 ord.]

Fejl i selve produktet

4. Jeg byggede til 10.000 brugere før jeg havde 10

Udviklere elsker at løse fremtidens problemer: mikrotjenester, køer, avanceret caching og en arkitektur der kan klare en storm af brugere. Det føles ansvarligt. I praksis betyder det mere kode at vedligeholde, flere ting der kan gå i stykker og langsommere udvikling, netop i den periode hvor du skal kunne ændre produktet hurtigt.

Et modent framework som Laravel på én server kan typisk bære langt mere trafik end en ny SaaS får i sit første år. Det kedelige valg er som regel det rigtige: én database, én kodebase og en hosting du kender.

Det betyder ikke at arkitekturen er ligegyldig. Nogle beslutninger er dyre at lave om senere, fx hvordan kundernes data holdes adskilt fra hinanden, og hvordan brugerroller og rettigheder er bygget. Brug tænketiden der, og vent med resten til tallene kræver det.

[PLACEHOLDER: Byggede du noget i Remotefitness for tidligt med tanke på skala? Hvad var det, og hvad kostede det? 20-40 ord. Skift punktet ud hvis det ikke passer.]

5. Jeg undervurderede betaling, moms og fakturering

At tage imod et kortnummer er den lette del. Bagved ligger abonnementer, prøveperioder, opgraderinger midt i en periode, mislykkede betalinger, kvitteringer, kreditnotaer, opsigelser og moms. Hver del er en lille opgave, men tilsammen kan de tage lige så lang tid som kernen i produktet.

Momsen er især let at undervurdere. Sælger du til en virksomhed med gyldigt momsnummer i et andet EU-land, opkræver du som udgangspunkt ikke selv moms. Sælger du til private forbrugere i andre EU-lande, gælder der særlige regler, og over EU's tærskel på 10.000 euro skal du typisk opkræve moms efter kundens land og kan indberette den samlet via One Stop Shop-ordningen (OSS).

Brug en etableret betalingsudbyder til abonnementer, og byg ikke din egen faktureringsmotor. Har du personoplysninger i systemet, hører GDPR og databehandleraftaler med i samme bunke af kedelige, men nødvendige opgaver.

[PLACEHOLDER: Hvordan håndterede du betaling og moms i Remotefitness, og hvad tog længere tid end forventet? 20-40 ord.]

6. Onboarding kom til sidst

Onboarding er den første oplevelse en ny bruger har med produktet, fra oprettelse til det øjeblik hvor problemet bliver løst første gang. Det er ofte den del der bliver bygget sidst og i en fart lige før lanceringen. Det er den omvendte prioritering. En bruger der ikke forstår produktet i første session, kommer sjældent tilbage, og du får aldrig at vide hvorfor.

Bestem hvad "aktiveret" betyder for dit produkt, fx at brugeren har oprettet sit første projekt og inviteret en kollega. Byg derefter den korteste vej dertil: færre felter ved oprettelse, eksempeldata i stedet for en tom skærm og en mail der hjælper videre hvis brugeren går i stå.

Det bedste værktøj er også det billigste. Sæt dig ved siden af tre rigtige brugere, eller del skærm med dem, og se dem prøve produktet uden at hjælpe.

[PLACEHOLDER: Hvordan så Remotefitness' første onboarding ud, og hvad ændrede du da du så rigtige brugere prøve den? 20-40 ord.]

Fejl i pris og salg

7. Prisen var for lav

En lav pris føles som en måde at sænke risikoen på, fordi flere siger ja. Men regnestykket er hårdt. Vil du have en omsætning på 50.000 kr. om måneden, skal du bruge omkring 500 kunder ved 99 kr. om måneden, men kun cirka 100 ved 499 kr. Hver kunde koster nogenlunde det samme i support og salgsarbejde, uanset hvad de betaler.

En lav pris tiltrækker også ofte de kunder der er mest prisfølsomme og hurtigst til at opsige. Og det er langt lettere at give en tidlig kunde rabat end at hæve prisen for alle eksisterende kunder bagefter.

Prissæt ud fra hvad problemet koster kunden i dag, ikke ud fra hvad du selv ville betale. Start højere end du tør, og hold øje med hvor mange der siger nej på grund af prisen. Siger ingen nej, er prisen sandsynligvis for lav.

[PLACEHOLDER: Hvordan satte du Remotefitness' første pris, og har du ændret den siden? Del kun tal du vil offentliggøre. 20-40 ord.]

8. Jeg troede produktet ville sælge sig selv

"Hvis produktet er godt nok, skal kunderne nok komme" er en af de mest udbredte fejl blandt iværksættere med teknisk baggrund. Et nyt produkt har ingen trafik, ingen anmeldelser og ingen der søger efter det ved navn. Uden en plan for hvordan kunderne finder dig, lancerer du for en tom sal.

Vælg én eller to kanaler som passer til din målgruppe, og begynd på dem mens du bygger. Det kan være direkte henvendelser, en brancheforening, et fagligt netværk, indhold der svarer på kundernes spørgsmål, eller partnere der allerede har kunderne. Kanalen behøver ikke kunne skalere i starten. De første kunder kommer ofte fra hårdt, manuelt arbejde.

Min tommelfingerregel er at bruge lige så meget tid på salg og markedsføring som på udvikling, også selv om det føles forkert for en udvikler. Hvordan de første kunder rent faktisk kom til, har jeg skrevet om i indlægget om de første betalende kunder til Remotefitness.

[PLACEHOLDER: Hvad var din plan for at finde kunder ved lanceringen, og hvad virkede faktisk? 20-40 ord.]

Fejl i driften

9. Jeg undervurderede drift og support

En SaaS er ikke færdig når den er lanceret. Den skal have sikkerhedsopdateringer, backups der faktisk bliver testet, overvågning der siger til når noget går ned, og en plan for mislykkede betalinger. Dertil kommer support: spørgsmål, fejlrapporter og ønsker til nye funktioner. Det hele lander i den samme indbakke og den samme kalender som din udvikling.

Hosting, mailudsendelse, fejlovervågning og backup er hver for sig ofte små beløb, men de løber hver måned, også før du har kunder. Den største post er som regel din egen tid. Hver time på drift er en time du ikke bygger eller sælger.

Budgettér drift fra dag ét. Vælg en hosting hvor opdateringer og backups er en del af opsætningen, sæt fejlovervågning op før lanceringen, og skriv faste svar på de spørgsmål der kommer igen. Jeg har lagt mine faktiske månedlige udgifter til at drive en SaaS frem i et separat indlæg.

[PLACEHOLDER: Hvilken del af driften tog mest tid som du ikke havde regnet med? 20-40 ord.]

10. Jeg målte for lidt, og for sent

I starten er der så få brugere at det føles unødvendigt at måle noget. Men netop i starten er hver bruger mest værdifuld som kilde til viden. Uden tal ved du ikke om nye brugere når frem til det punkt hvor produktet hjælper dem, eller hvornår og hvorfor de opsiger.

Du behøver ikke et stort dashboard. Tre tal er nok i begyndelsen: hvor mange der opretter sig, hvor mange af dem der bliver aktiveret (se fejl 6), og hvor mange der opsiger hver måned (churn). Send desuden en kort mail til alle der opsiger, med ét spørgsmål: hvad fik dig til at stoppe?

Tallene fortæller hvad der sker. Samtalerne fortæller hvorfor. Du har brug for begge dele, og de er billigst at sætte op før du har mange kunder.

[PLACEHOLDER: Hvad målte du i Remotefitness fra start, og hvad ville du ønske du havde målt tidligere? 20-40 ord.]

Hvornår du ikke skal hyre en udvikler (endnu)

Jeg lever af at bygge software, så læs afsnittet med det forbehold. Men flere af fejlene ovenfor bliver dyrere, ikke billigere, af at du betaler en udvikler for at lave dem hurtigere.

Vent med at hyre en udvikler, også mig, hvis:

• du endnu ikke har talt med mulige kunder, eller ingen har vist at de vil betale
• idéen kan testes med en landingsside, et regneark eller en manuel service hvor du selv udfører det produktet senere skal gøre
• et standardsystem dækker det meste af behovet, og din forskel ligger i service eller salg, ikke i software
• du ikke har budget til at drive og markedsføre produktet i mindst et år efter lanceringen

En udvikler er den rigtige investering når idéen er valideret, der er kunder der venter, og produktet kræver logik, integrationer eller data som et standardværktøj ikke kan håndtere. Så er det til gengæld vigtigt at bygge fundamentet ordentligt fra start, så du ikke skal skrive det hele om når kunderne kommer.

Næste skridt: hvis jeg skulle starte forfra i dag

Hvis jeg skulle bygge en ny SaaS i morgen, ville jeg ikke starte i kodeeditoren. Jeg ville starte med de seks punkter herunder og først åbne editoren når de alle er krydset af.

Har du styr på listen, og skal produktet bygges, kan du se hvordan jeg arbejder med udvikling af SaaS-produkter. Større forløb starter med et betalt forprojekt til fast pris, og du ejer koden fra første dag.

Ofte stillede spørgsmål

Hvor lang tid går der før en SaaS tjener penge?+

For de fleste tager det længere end planlagt. Abonnementsindtægter vokser langsomt, da hver ny kunde kun betaler et mindre beløb om måneden, mens udgifterne til drift og markedsføring løber fra første dag. Læg et budget der kan bære produktet et godt stykke tid efter lanceringen, og sæt delmål som de første ti betalende kunder i stedet for en fast dato for overskud.

Kan man rette fejlene efter lanceringen?+

De fleste, ja. Funktioner, onboarding og markedsføring kan du justere løbende, og det skal du også. Det der er dyrt at rette, er de grundlæggende valg: datamodellen, hvordan kundernes data holdes adskilt, og prisen over for eksisterende kunder. Brug derfor mest tid på de beslutninger før lanceringen, og vær mere afslappet med resten.

Er det en fejl at bygge en SaaS alene?+

Nej, men det kræver at du dækker mere end koden. Alene skal du både bygge, sælge, supportere og drive produktet, og det er typisk salget udviklere undervurderer. Et lille, smalt produkt kan sagtens drives af én person hvis du automatiserer driften, holder produktet enkelt og siger nej til funktioner som kun én kunde har bedt om.

Hvilken teknologi skal man vælge til en ny SaaS?+

Vælg den teknologi du eller din udvikler kender bedst, og som har et stort, aktivt økosystem. I en ny SaaS er det vigtigere at kunne ændre produktet hurtigt end at have den perfekte arkitektur. Et modent framework som Laravel eller Next.js med én database dækker de fleste behov længe. Det vigtigste er at koden kan vedligeholdes, og at andre udviklere kan arbejde i den.