Fra idé til SaaS: valg, prioriteringer og drift

Denne guide gennemgår arbejdet fra SaaS-idé til drift. Koden er kun en del af opgaven: validering, betaling, drift og de første kunder kræver også opmærksomhed.

Til daglig bygger jeg software for virksomheder. Her er fokus på udvikling, prioriteringer og de opgaver, et SaaS-produkt kræver efter lancering.

Den korte version: fra idé til drift i syv faser

[PLACEHOLDER: 2-3 sætninger om hvad Remotefitness er, hvem kunden er, hvordan kunden betaler, og om produktet kører i dag.]

Leder du efter en generel opskrift trin for trin, står den i min komplette guide til at bygge en SaaS. Her handler det om beslutningerne i ét konkret produkt og om hvad jeg tager med mig ind i projekter for kunder.

Fra problem til produktidé

[PLACEHOLDER: hvor idéen kom fra, hvilket problem Remotefitness løser, og for hvem. Gerne en konkret situation: en samtale, en kunde eller noget du selv manglede. Og hvorfor du byggede selv i stedet for at bruge et eksisterende værktøj.]

Mange udviklere får idéen til deres første SaaS på samme måde: de ser et problem de kan løse med kode, og så går de i gang. Det er både styrken og fælden. Du kan bygge en første version hurtigere og billigere end de fleste, men det gør det også fristende at springe det kedelige over: at finde ud af om nogen vil betale.

"Det kan jeg bygge" er nemlig ikke det samme som "det vil nogen købe". Det første er et teknisk spørgsmål som en udvikler kan svare på i løbet af en eftermiddag. Det andet kræver samtaler med mennesker der ikke kender dig, og det er langt mindre behageligt for de fleste der hellere vil sidde med koden.

Validering før den første linje kode

Validering betyder at finde ud af om problemet er stort nok til at nogen vil betale for at få det løst. Det handler ikke om hvorvidt folk synes idéen er god. Venner, familie og tidligere kolleger siger næsten altid ja til en god idé fordi det ikke koster dem noget.

Hvis jeg skulle validere en SaaS-idé i dag, ville jeg stille potentielle kunder fire spørgsmål:

1. Hvordan løser du problemet i dag, og hvad koster det dig i tid eller penge?
2. Hvornår skete det sidst?
3. Hvad har du allerede prøvet, og hvorfor holdt du op?
4. Hvis jeg løste det næste måned, hvad ville det så være værd for dig?

Svarene på de første tre fortæller dig om problemet er ægte. Det fjerde viser om der er en forretning. Det stærkeste signal er en kunde der vil betale på forhånd eller skrive under på en pilotaftale (en aftale om at bruge produktet tidligt, ofte til nedsat pris, mod at give feedback).

[PLACEHOLDER: hvordan du testede idéen bag Remotefitness før du byggede (samtaler, venteliste, forudsalg eller slet ikke), og hvad du ville gøre anderledes i dag.]

Første version: hvad kom med, og hvad blev skåret fra

En MVP (minimum viable product) er den mindste version af produktet der løser kerneproblemet godt nok til at nogen vil betale for det. Ordet "mindste" er det svære. Næsten alle første versioner bliver større end planlagt fordi hver ekstra funktion virker lille når du ser på den alene.

For en SaaS er der nogle ting der næsten altid skal med fra start:

• Oprettelse, login og nulstilling af adgangskode
• Kernefunktionen, altså det kunden betaler for
• Betaling og styring af hvad kunden har adgang til
• Mails der bekræfter oprettelse, betaling og opsigelse
• Et simpelt administrationspanel til dig selv så du kan hjælpe kunder uden at åbne databasen

Til gengæld kan meget vente: avancerede rapporter, integrationer til andre systemer, en app til telefonen, flere prisplaner og fuld selvbetjening. De første kunder accepterer manuelle løsninger hvis kernen virker og du svarer hurtigt.

[PLACEHOLDER: hvad var med i første version af Remotefitness, hvad blev bevidst skåret fra, og hvor lang tid det tog fra første linje kode til første kunde (kun hvis tallet må deles).]

Hos kunder planlægger jeg forløbet i små, faste bidder, og min MVP-proces uge for uge viser hvordan en første version bliver til fra kickoff til lancering.

De tekniske valg der er dyre at lave om

Det meste i en SaaS kan ændres senere uden større drama: design, tekster, prisplaner og de fleste funktioner. Nogle få beslutninger er anderledes fordi alt andet bliver bygget oven på dem. Laver du dem om efter lanceringen, rører du ved data der tilhører rigtige kunder.

Stack: kedelig teknologi med vilje

Til kundeprojekter arbejder jeg typisk med Laravel og PHP på serversiden og React eller Next.js i browseren, med Tailwind CSS til design. Grunden er at teknologien er udbredt, veldokumenteret og let at finde andre udviklere til hvis det en dag ikke er mig der skal vedligeholde koden. Det er et bedre kriterium end det der er nyest.

[PLACEHOLDER: hvilken stack, hosting og betalingsudbyder Remotefitness kører på, og om du ville vælge det samme i dag.]

Resten af værktøjskassen, fra editor til databaseværktøj, har jeg samlet i listen over de værktøjer jeg bruger som freelanceudvikler.

Kundedata og brugerroller

Når flere virksomheder bruger det samme system, skal hver kundes data holdes adskilt. Det kaldes multi-tenancy (flere lejere i samme system). Beslutningen om hvordan data adskilles, træffes bedst før den første kunde er oprettet fordi den påvirker næsten hver eneste tabel i databasen.

Det samme gælder brugerroller. Selvom første version kun har én type bruger, bør datamodellen kunne rumme at en konto har flere brugere med forskellige rettigheder. Det er billigt at forberede og dyrt at bygge ind bagefter.

Betaling og abonnement

Abonnementsbetaling er mere end en betalingsknap. Der er prøveperioder, opgradering midt i en periode, kort der udløber, betalinger der fejler, kreditnotaer, moms og opsigelser. En etableret betalingsudbyder klarer selve transaktionerne, men du skal stadig bygge logikken der styrer hvad kunden har adgang til og hvad der sker når en betaling fejler.

Min anbefaling er at tage imod betaling fra første dag, også selvom de første kunder får rabat. Det er den eneste ægte validering, og det tvinger dig til at bygge betalingsflowet før det bliver uoverskueligt.

GDPR og hosting

Lægger dine kunder persondata om deres egne medlemmer, kunder eller medarbejdere i dit system, er du typisk deres databehandler. Ifølge Datatilsynets vejledning om dataansvarlig og databehandler skal der så være en databehandleraftale mellem jer. I praksis skal du vide hvor data ligger, hvilke underleverandører du bruger og hvordan du sletter en kunde helt. Det er nemmest at have styr på fra start, og hosting i EU gør samtalen med danske erhvervskunder kortere.

[PLACEHOLDER: hvilken af de fire beslutninger der var sværest i Remotefitness, eller som du måtte lave om senere.]

Lancering og de første betalende kunder

Den første lancering behøver ikke være stor. Den skal give dig nogle få kunder du kan tale med. Så kan du se hvor produktet virker og hvor det ikke gør. Lancerer du stort før du ved det, får du mest støj.

Tre ting at holde øje med fra første uge

Hvis jeg skulle lancere en ny SaaS i dag, ville jeg holde øje med de her tre:

1. Aktivering: bruger nye kunder kernefunktionen inden for de første dage, eller opretter de sig og forsvinder igen?
2. Opsigelser: hvor mange stopper, og hvorfor? Spørg hver eneste kunde der opsiger.
3. Henvendelser: hvad spørger kunderne om? Gentagne spørgsmål peger på steder hvor produktet er uklart.

Den klassiske fælde for en udvikler er at bygge flere funktioner når salget går langsomt. Nye funktioner føles som fremskridt, men hvis kunderne ikke bruger dem der allerede findes, løser flere funktioner sjældent problemet. Samtaler med kunderne gør det til gengæld ofte.

[PLACEHOLDER: hvordan Remotefitness fik sine første betalende kunder: kanal, omtrentlig tid fra lancering til første betaling, og hvad der ikke virkede.]

Hele historien om kanaler, salg og de første aftaler står i hvordan Remotefitness fandt sine første betalende kunder.

Prisen er en del af produktet

Som udvikler er det let at sætte prisen for lavt fordi du tænker på hvad systemet koster at drive og ikke på hvad det er værd for kunden. En lav pris gør det sværere at se om produktet løser et vigtigt problem, og den er svær at hæve over for kunder der allerede betaler. Min tommelfingerregel er at starte med få prisplaner, gerne én eller to, og prissætte efter den værdi kunden får frem for dine egne omkostninger.

[PLACEHOLDER: hvordan Remotefitness er prissat (model, ikke nødvendigvis beløb), og om prisen er blevet ændret siden lanceringen.]

Drift efter lanceringen: tid, penge og fejl

Når produktet er lanceret, skifter arbejdet karakter. Der kommer færre store opgaver og mange små, og de stopper ikke selvom du holder pause med nye funktioner.

Det der fylder i hverdagen

• Opdateringer af framework, pakker og serversoftware, især sikkerhedsopdateringer
• Backup og test af at den faktisk kan gendannes
• Overvågning af oppetid og en fejllog der fortæller dig om problemer før kunderne gør
• Support, betalingsfejl og spørgsmål til fakturaer
• Små ønsker fra kunderne, som hurtigt bliver til en lang liste

Ingen af opgaverne er svære hver for sig. Tilsammen er de et fast job.

De faste udgifter

Selv en lille SaaS har udgifter hver måned: hosting, domæne, mailudsendelse, fejlovervågning, betalingsgebyrer og abonnementer på diverse værktøjer. Beløbene er ofte små hver for sig, men de løber hver måned, også når der ingen kunder er.

[PLACEHOLDER: hvilke faste udgifter Remotefitness har, med tal hvis du vil dele dem, ellers en kvalitativ beskrivelse af de største poster.]

De konkrete poster gennemgår jeg i hvad det koster at drive en SaaS hver måned.

Fejlene jeg ville undgå i dag

[PLACEHOLDER: de 2-3 største fejl du lavede med Remotefitness, med én eller to sætninger hver. Resten hører hjemme i fejl-indlægget.]

Den fulde liste står i 10 faldgruber ved SaaS-udvikling, skrevet så du kan undgå dem i dit eget produkt.

Flere cases: kundeprojekter og bag kulissen

De øvrige cases handler om projekter og arbejdsgange. Hver case er skrevet, så du kan se, om opgaven ligner din.

[PLACEHOLDER: bekræft at kunderne må nævnes ved navn, og at beskrivelserne nedenfor passer til det du faktisk har lavet.]

• Ziik: nye funktioner til en medarbejderplatform i vækst. Relevant hvis du har et produkt med brugere i forvejen og skal have bygget nyt uden at forstyrre dem.
• Fitness World: digitale løsninger til en fitnesskæde. Relevant hvis din virksomhed er stor og nye systemer skal passe ind i en eksisterende organisation.
• Webløsninger til fiber- og teleselskaber. En samlet case på tværs af flere selskaber i samme branche.
• Dronelog: en platform til droneoperatører. Relevant hvis din SaaS henvender sig til en smal branche med egne regler og arbejdsgange.
• Meeshop: en e-handelsløsning. Relevant hvis du overvejer om din webshop skal bygges custom eller på en standardplatform.
• Eiland EL: en ny hjemmeside til en mindre virksomhed. Relevant hvis hjemmesidens vigtigste opgave er at skaffe henvendelser.

Vil du se mit håndværk uden en kunde imellem, har jeg også skrevet om hvordan jeg byggede min egen hjemmeside, simonij.com, med stack, hastighed og SEO.

Næste skridt: hvis du selv vil bygge en SaaS

Det jeg tager med ind i kundeprojekter

Når jeg hjælper en virksomhed eller en founder med en SaaS, stiller jeg de spørgsmål jeg selv har skullet svare på. Hvem betaler, og hvorfor? Hvad skal med i første version, og hvad kan vente? Hvem holder systemet kørende om et år, og hvad koster det?

Større projekter starter med et betalt forprojekt til fast pris, hvor du og jeg afgrænser første version, træffer de dyre tekniske valg og sætter pris på resten. Du har direkte kontakt med mig, der skriver koden, og du ejer koden fra første dag.

[PLACEHOLDER: én konkret ting du gør anderledes i kundeprojekter fordi du selv har bygget og drevet Remotefitness.]

Hvornår du ikke skal hyre en som mig

Det er ikke altid en udvikler du har brug for først:

• Har du ikke talt med potentielle kunder endnu, så start dér. Samtaler, en landingsside eller en klikbar prototype er billigere end kode.
• Løser et eksisterende værktøj det meste af problemet, så køb det og brug pengene på salg.
• Vil du teste idéen med et no-code- eller AI-værktøj først, er det ofte et fornuftigt første skridt. Koden kan bygges ordentligt når du ved at nogen betaler.
• Har du en teknisk medstifter der vil bygge produktet, har du måske kun brug for sparring eller en ekstern gennemgang af koden undervejs.

Er du klar til at bygge, kan du læse om hvordan jeg udvikler SaaS-produkter for virksomheder og founders og om hvordan et projekt med mig foregår fra første opkald til lancering.

Ofte stillede spørgsmål

Skal man selv være udvikler for at bygge en SaaS?+

Nej. Mange SaaS-produkter er startet af folk uden teknisk baggrund som har hyret en freelanceudvikler eller et bureau eller fundet en teknisk medstifter. Fordelen ved selv at kunne kode er at første version bliver billigere. Ulempen er at det er fristende at bygge i stedet for at sælge. Det afgørende er at du kender kunden og problemet bedre end nogen anden.

Hvad er forskellen på en SaaS og en almindelig webapp?+

En SaaS er en webapp som mange kunder betaler abonnement for at bruge, typisk i det samme system. Det stiller ekstra krav: kundernes data skal holdes adskilt, betaling og adgang skal styres automatisk, og nye kunder skal kunne komme i gang uden hjælp. En intern webapp til én virksomhed har sjældent de krav og er derfor ofte enklere at bygge.

Kan en freelancer drive og vedligeholde en SaaS efter lanceringen?+

Ja. Mange mindre SaaS-produkter bliver vedligeholdt af én udvikler på en fast aftale om opdateringer, overvågning og videreudvikling. Det vigtige er at koden, hostingen og alle adgange står i dit navn, og at koden er dokumenteret så en anden udvikler kan tage over hvis det bliver nødvendigt. Så er du ikke låst til én person.

Hvor lang tid tager det at bygge en SaaS?+

Det afhænger af omfanget, men en afgrænset første version med brugerkonti, et par kernefunktioner og abonnementsbetaling tager ofte et par måneder at bygge efter et forprojekt. Mange integrationer, flere brugerroller eller en app til telefonen forlænger forløbet. Regn også med tid efter lanceringen: de første betalende kunder kommer sjældent af sig selv, og produktet skal justeres efter hvad kunderne faktisk bruger.