Sådan validerer du en SaaS-idé før du skriver en linje kode

Du validerer en SaaS-idé ved at skaffe bevis for at en bestemt gruppe kunder har problemet og vil betale for at få det løst. Det gør du før der bliver skrevet en linje kode: du taler med potentielle kunder, sætter en pris på en enkel landingsside, beder om forudbetaling og leverer løsningen i hånden til de første. Hvert trin koster lidt mere end det forrige og fortæller dig mere.

Jeg er udvikler og lever af at bygge software, så det kan lyde underligt at jeg anbefaler dig at vente. Men en færdig SaaS som ingen vil betale for, er en fejl som ingen udvikler kan rette bagefter.

Den korte version: fire metoder fra billigst til stærkest

Reglen er enkel: gå videre til næste metode når den forrige har givet et klart ja, og stop når du får et klart nej. Du behøver ikke bruge alle fire. En idé til erhvervskunder kan sagtens være valideret efter en runde samtaler og tre underskrevne pilotaftaler.

Validering er trin 2 i min guide til at bygge en SaaS fra idé til betalende kunder. Her går jeg i detaljer med selve testene, og med hvordan du læser resultatet.

Hvad der tæller som bevis

De fleste idéer bliver ikke valideret. De bliver bekræftet. Du fortæller om idéen, folk er høflige og siger at den lyder spændende, og du går derfra med en god fornemmelse og intet bevis.

Jeg tænker på signaler som en stige. Jo mere det koster kunden at give dig signalet, jo mere er det værd:

1. Ros og interesse ("det lyder smart"). Næsten intet værd.
2. En mailadresse på en venteliste. Lidt værd, især hvis prisen stod på siden.
3. Tid: en time til en opfølgende samtale eller til at prøve en prototype.
4. Omdømme: de introducerer dig for deres chef eller en kollega. Nu sætter de noget på spil.
5. Penge eller en underskrift: forudbetaling, en betalt pilot eller en hensigtserklæring.

Spørgeskemaer og likes på sociale medier ligger i bunden af stigen. Folk svarer på hvad de tror de ville gøre, og det er noget andet end hvad de gør når de skal finde betalingskortet frem.

Validering betyder heller ikke at idéen er bevist for altid. Du tester en antagelse om en bestemt kundegruppe, et bestemt problem og en bestemt pris. Ændrer du en af de tre, skal du teste igen.

Sådan validerer du en SaaS-idé i seks trin

Trinene bygger oven på hinanden. Du kan springe et over hvis svaret allerede er tydeligt, men start ikke med trin 6.

1. Skriv din antagelse ned i én sætning

Formulér hvem kunden er, hvilket problem de har, og hvad de vil betale for at slippe for det. Fx: "Ejere af små tandklinikker bruger flere timer om ugen på at ringe patienter op om aflyste tider og vil betale 600 kr. om måneden for at få det automatiseret."

Sætningen tvinger dig til at vælge én kundetype og sætte et tal på. Begge dele er ubehagelige, og det er netop pointen. Er du i tvivl om hvordan prisen skal skrues sammen, har jeg gennemgået de mest almindelige prismodeller til SaaS.

Skriv også ned hvad der skal til for at du opgiver idéen. Det vender jeg tilbage til længere nede.

2. Find 10-15 personer der har problemet

Ikke venner, familie eller andre iværksættere. Du skal tale med folk der har problemet i dag og som kunne blive betalende kunder. Til erhvervskunder finder du dem typisk via LinkedIn, brancheforeninger, faggrupper på sociale medier eller dit eget netværk i branchen.

Kan du ikke finde 10-15 af dem på et par uger, er det i sig selv et fund. Så bliver det sandsynligvis også svært at sælge til dem senere.

3. Tal om problemet, ikke om din idé

Spørg ind til hvad de gør i dag, ikke hvad de ville gøre. Gode spørgsmål er konkrete og handler om noget der allerede er sket:

• Hvornår skete det sidst, og hvad gjorde du?
• Hvad bruger du i dag, og hvad koster det dig i tid eller penge?
• Hvad har du allerede prøvet for at løse det?

Undgå spørgsmål som "Ville du bruge et system der ...?" Svaret er næsten altid ja, og det forpligter ingen. Metoden er beskrevet godt i The Mom Test af Rob Fitzpatrick, en kort bog om at stille spørgsmål der giver ærlige svar, også når folk gerne vil være søde.

Læg mærke til om de selv bringer problemet op og om de allerede bruger penge på en dårlig løsning. Et regneark som tre medarbejdere vedligeholder i hånden, er et bedre tegn end begejstring.

4. Lav en landingsside med pris

En landingsside beskriver produktet som om det allerede fandtes: hvem det er til, hvilket problem det løser, og hvad det koster. Knappen fører til en venteliste eller en formular hvor man kan booke en demo. Siden kan laves i et no-code-værktøj på en dag eller to.

Prisen skal stå der. Uden pris måler du nysgerrighed, ikke købelyst. Send trafik fra din målgruppe til siden, enten via de kontakter du fandt i trin 2, via faggrupper eller med en lille annoncekampagne, og mål hvor mange der skriver sig op.

En landingsside siger mest om produkter med selvbetjening og mange små kunder. Til dyrere software for virksomheder siger den mindre fordi køberne sjældent skriver sig op på en venteliste. Her betyder trin 5 mere.

5. Bed om penge eller en underskrift

Det er det trin de fleste springer over, og det er det der betyder mest. Tilbyd de mest interesserede en plads som pilotkunde: en rabat på første år mod forudbetaling, eller en betalt pilotperiode når første version er klar.

Til selve betalingen behøver du ingen kode. Stripe Payment Links oprettes i Stripes kontrolpanel og kan bruges til både engangsbetaling og abonnement. Til erhvervskunder kan en almindelig faktura eller en underskrevet hensigtserklæring være lige så god.

Når nogen takker nej til at betale, så spørg hvorfor. Det svar er ofte mere værd end ti tilmeldinger på en venteliste.

Lov ikke mere end du kan holde. Tager du imod penge, skal du kende den omtrentlige pris og tid på første version, og kunderne skal have pengene tilbage hvis produktet ikke bliver til. Få en rådgiver til at se på vilkårene hvis du er i tvivl.

6. Lever løsningen i hånden til de første kunder

En manuel MVP, også kaldet en concierge-MVP, betyder at du selv udfører det arbejde som softwaren senere skal klare. Kunden betaler for resultatet, og bag kulisserne er det dig med et regneark, en mailboks og en kalender.

Det er ineffektivt, og det er meningen. Du lærer præcis hvilke trin kunderne bruger, hvad de spørger om, og hvad der skal automatiseres først. Paul Graham beskriver princippet i essayet Do Things that Don't Scale, hvor han blandt andet fortæller hvordan Stripes stiftere selv satte produktet op hos de første brugere.

En manuel MVP er stadig en MVP. Den eneste forskel er at koden mangler. Er du i tvivl om begrebet, har jeg skrevet om hvad en MVP er, og hvad den ikke er.

Når du ikke længere kan følge med manuelt og kunderne stadig betaler, er det et godt tidspunkt at begynde at bygge.

Sådan ved du om idéen har bestået

Bestem dine grænser før du starter, ikke efter. Ellers ender du med at kalde 40 tilmeldinger en succes fordi du har brugt tre måneder på at skaffe dem.

Start med et regnestykke. Skal produktet koste 500 kr. om måneden, og skal det give 25.000 kr. om måneden før det kan betale sig for dig, så skal du bruge 50 kunder. Spørg dig selv om testen viser en realistisk vej til de 50.

Jeg sorterer resultatet i tre bunker:

• Fortsæt: flere har betalt eller skrevet under, og samtalerne peger på det samme problem.
• Justér: folk har problemet, men vil ikke betale din pris, eller det er en anden kundetype der bider på. Skift én ting og test igen.
• Stop: du kan ikke finde folk med problemet, eller ingen vil betale, heller ikke efter en justering.

Der findes ikke et fast tal for hvor mange tilmeldinger eller forudbetalinger der er nok. Det afhænger af prisen og af hvor mange kunder du skal bruge. Men to betalende pilotkunder til software for virksomheder er efter min vurdering et langt stærkere signal end et par hundrede mailadresser fra en side uden pris.

De metoder jeg selv ville vælge

Hvis idéen var min, ville jeg vælge metode ud fra hvem kunden er:

• Software til virksomheder med en højere pris: samtaler og pilotaftaler. Jeg ville springe annoncer over og kun bruge landingssiden som noget at sende videre efter en samtale. Den slags køb sker gennem samtaler, så det er dem der skal testes.
• Selvbetjening til mange små kunder: en landingsside med pris og en lille annoncekampagne mod præcis den målgruppe, efterfulgt af forsalg til dem der skriver sig op.
• En idé hvor arbejdsgangen er uklar: manuel levering. Du finder ikke ud af hvad softwaren skal gøre ved at gætte. Du finder ud af det ved at gøre arbejdet selv.

Det kan være fristende at gå direkte til koden. Det er den del der føles som fremskridt. Men et par ugers samtaler kan spare dig for måneders udvikling af noget der skal laves om.

AI-værktøjer som Lovable og Bolt er fine til at lave en klikbar prototype du kan vise frem i samtalerne. Pas bare på med at kalde prototypen et produkt og lukke rigtige kunder og persondata ind i den uden en grundig gennemgang.

Hvornår validering ikke er nok, og hvornår du ikke skal hyre mig

Validering tester om nogen vil betale. Den tester ikke om produktet kan bygges. Ligger risikoen i din idé i det tekniske, fx en integration til et system uden åbent API eller beregninger der skal være helt præcise, så er en lille teknisk prøve det rigtige næste skridt. Det kan en udvikler hjælpe med, typisk som en del af et forprojekt.

Der er også situationer hvor du ikke har brug for en udvikler som mig endnu:

• Du har ikke talt med kunderne. Så skal pengene bruges på at finde dem, ikke på kode.
• Et regneark, en formular og et betalingslink kan klare de første kunder. Så kør det sådan til det manuelle arbejde begynder at koste dig kunder eller nattesøvn.
• Du vil have en udvikler til at validere idéen ved at bygge den. Det er den dyreste markedsundersøgelse der findes.

Forskellen i pris er stor. En SaaS-MVP med abonnement og roller lander groft skønnet på 250.000-400.000 kr. med en erfaren freelancer. Regnestykket står i min prisguide til MVP-udvikling. Valideringen koster en brøkdel af det.

Næste skridt: fra valideret idé til et prisoverslag

Har du et klart ja fra rigtige kunder, er næste skridt at afgrænse første version og få en pris på den. Brug tjeklisten før du kontakter en udvikler.

Kan du krydse de fleste af, er du klar til at afgrænse første version. Det gennemgår jeg i guiden til at skære en MVP ned til det nødvendige. Og vil du vide hvad det koster at komme videre, kan du se hvordan jeg prissætter forprojekt og udvikling.

Ofte stillede spørgsmål

Kan nogen stjæle min idé hvis jeg fortæller om den?+

Det sker sjældent, og risikoen er næsten altid mindre end risikoen ved at bygge i hemmelighed. En idé er ikke meget værd før nogen har ført den ud i livet, og de folk du interviewer, har travlt med deres egen forretning. Skal du dele detaljer med en udvikler eller en samarbejdspartner, kan en fortrolighedsaftale være fornuftig. Potentielle kunder skriver sjældent under på en, så lad være med at kræve det af dem.

Er det lovligt at tage imod betaling for et produkt der ikke findes endnu?+

Ja, forsalg er almindeligt, men du skal være tydelig om hvad kunden køber og hvornår det forventes leveret. Skriv vilkårene ned, også hvad der sker hvis produktet bliver forsinket eller ikke bliver til, og giv pengene tilbage i så fald. Sælger du til forbrugere, gælder der strengere regler end ved salg til virksomheder. Få en rådgiver til at se på vilkårene før du sender det første betalingslink.

Kan jeg bruge et spørgeskema til at validere min idé?+

Et spørgeskema kan hjælpe dig med at finde ud af hvem der har problemet, men det kan ikke vise at nogen vil betale. Brug det i stedet til at finde de personer du skal tale med. Slut fx med et spørgsmål om de vil deltage i en samtale på 20 minutter. Dem der siger ja, er ofte de mest interesserede, og dermed dine bedste bud på pilotkunder.

Skal jeg validere hvis jeg allerede har kunder i min serviceforretning?+

Ja, men det går hurtigere. Du kender allerede kunderne og problemet, og du kan teste ved at tilbyde eksisterende kunder en softwareudgave af det du leverer i dag. Spørg om de vil betale for den og hvor meget. Vær opmærksom på at kunder der er glade for din personlige service, ikke nødvendigvis vil betale for et værktøj de selv skal bruge.