12 MVP-features din SaaS kan undvære ved lancering

De fleste MVP-features som står på en kravliste før lanceringen, kan vente til betalende kunder beder om dem. En MVP er den første, enkle version af dit produkt, og dens eneste opgave er at bevise at nogen vil betale for at få løst ét bestemt problem. Avanceret rollestyring, en native app og en hjemmebygget fakturamotor koster uger at bygge og afgør sjældent om de første kunder siger ja.

Herunder får du 12 funktioner du roligt kan udskyde, hvad du gør i stedet, og hvilket signal der bør få dig til at bygge dem. Jeg udvikler software som freelancer, så jeg kender både den tekniske regning og presset for at komme i luften.

Den korte version

Tabellen viser de 12 funktioner, hvad du gør i stedet ved lancering, og hvornår det er tid til at bygge dem.

Alle 12 er rigtige funktioner i modne SaaS-produkter. Problemet er rækkefølgen, ikke funktionerne. Vil du have overblikket over hele forløbet fra idé til drift, så start med min guide til at bygge en SaaS.

Adgang og administration

Den første gruppe handler om hvem der må hvad, og hvordan du selv holder styr på kunderne. Her er fristelsen størst for at bygge det en stor virksomhed ville forvente.

1. Avanceret rollestyring

Rettigheder pr. modul, roller som kunden selv definerer, og godkendelsesflows ser professionelle ud på en kravliste. De første kunder har dog sjældent mere end en håndfuld brugere hver, og de har ikke brug for at kunne skjule fanen "Rapporter" for praktikanten.

Start med to eller tre faste roller, fx ejer, administrator og bruger, kodet direkte i systemet. Det vigtige er datamodellen: lad brugere høre til en konto eller et hold fra første dag, så du kan bygge finere rettigheder ovenpå senere uden at flytte data rundt. Begynder flere kunder at spørge efter adgang pr. afdeling eller pr. projekt, er det signalet til at bygge mere.

2. Enterprise single sign-on

Single sign-on via SAML betyder at brugerne logger ind med virksomhedens egen brugerstyring, fx Microsoft Entra ID eller Okta. Det er et krav hos mange større virksomheder, og det er også en funktion som SaaS-leverandører ofte lægger i deres dyreste pakke. En oversigt over SSO-tillæg hos kendte SaaS-produkter viser hvor udbredt det er. Det siger noget om hvem der efterspørger det: store kunder med it-afdelinger og indkøbsprocesser, ikke dine første ti.

Ved lancering rækker e-mail og adgangskode med en god nulstilling. Sælger du til virksomheder der bruger Google Workspace eller Microsoft 365, er "Log ind med Google" eller "Log ind med Microsoft" et billigt skridt op. Brug frameworkets færdige løsning til login i stedet for at skrive den selv. Den dag en kunde skriver SSO ind i kontrakten, har du også en pris at sætte på det.

3. Et specialbygget adminpanel

Du skal kunne se dine kunder, rette en forkert e-mail og hjælpe en bruger der sidder fast. Men et håndbygget administrationssystem med egne skærme til alting er ugers arbejde på noget dine kunder aldrig ser.

Bygger du i Laravel, giver Filament dig et brugbart adminpanel med tabeller, formularer og filtre på kort tid, og det er open source. Andre teknologier har tilsvarende værktøjer. Undgå til gengæld at administrere ved at rette direkte i databasen i produktion. Det går fint lige indtil nogen sletter den forkerte række. Byg egne adminskærme når du kan se at bestemte supportopgaver æder timer hver uge, og så kun til de opgaver.

Betaling og prissætning

Penge er det sted hvor fejl er dyrest, og netop derfor skal du ikke bygge det hele selv. Her er det næsten altid bedre at leje end at eje.

4. Din egen fakturamotor

Abonnementer lyder simpelt: træk et beløb hver måned. I virkeligheden skal du håndtere afviste kort, påmindelser, op- og nedgraderinger midt i en periode, kreditnotaer, moms på tværs af lande og fakturaer der opfylder kravene i moms- og bogføringsreglerne. Det er et produkt i sig selv.

Brug en betalingsudbyder. Stripe og Paddle klarer abonnementer, og i Laravel håndterer Laravel Cashier det meste af koden omkring dem, inklusive prøveperioder, kuponer og skift mellem planer. Paddle fungerer desuden som merchant of record, altså den juridiske sælger der opkræver og afregner moms for dig. Det koster typisk en højere procentsats pr. betaling, men sparer dig for administration. Har du kun en håndfuld erhvervskunder, kan du starte med manuelle fakturaer fra dit regnskabsprogram, fx e-conomic eller Dinero.

Din egen fakturamotor er en af de få ting på listen jeg sjældent ville anbefale at bygge, selv når produktet er vokset. Valget mellem udbyderne gennemgår jeg i indlægget om abonnementsbetaling i en SaaS.

5. Mange prisplaner, tillæg og kuponer

Tre planer, årlig og månedlig betaling, tillægsmoduler, mængderabat og kampagnekoder. Det er fristende at designe hele prisstrukturen før lanceringen, men du ved endnu ikke hvem der køber, eller hvad de vil betale for.

Start med én eller to planer. Giver du en tidlig kunde rabat, så aftal den direkte og læg den ind som en kupon hos betalingsudbyderen eller på fakturaen. Skift mellem planer kan klares på mail de første måneder. Det tager dig et par minutter, og hver henvendelse fortæller dig noget om hvorfor kunden vil skifte. Byg selvbetjening og flere planer når du har salg nok til at se et mønster.

6. White-label og særløsninger til enkelte kunder

Egne farver, eget domæne, egne felter og særlige arbejdsgange for hver kunde. Det første store salg frister ofte med "hvis bare I kan ...", og pludselig har du én kodebase med ti undtagelser som skal testes hver gang du ændrer noget.

Hold fast i ét design og én måde at gøre tingene på i starten. Et logo i toppen er fint og billigt. Særønsker fra én kunde skal du vurdere ud fra om de næste kunder også vil have dem. Hvis ja, er det en funktion. Hvis nej, er det et konsulentprojekt, og så skal det prissættes som et. Byg rigtig white-label når flere kunder vil betale ekstra for det, ikke når én kunde nævner det.

Brugerflade og produkt

Den tredje gruppe er de funktioner der ser bedst ud i en demo. Det er også dem der oftest bliver bygget fordi konkurrenterne har dem, ikke fordi kunderne har bedt om dem.

7. En native app til iOS og Android

En app i App Store føles som et rigtigt produkt. Men en native app betyder typisk en ekstra kodebase eller et fælles framework som React Native, godkendelse hos Apple og Google, og at hver ændring skal udgives flere steder. For en lille MVP kan det let blive en af de dyreste beslutninger i hele projektet.

Byg i stedet en webapp der virker godt på mobilen. Den kan gøres installerbar som en PWA (progressiv webapp), så den ligger som et ikon på hjemmeskærmen. Det dækker de fleste B2B-produkter, hvor brugerne alligevel sidder ved en computer store dele af dagen. En native app bliver relevant når brugerne skal arbejde offline i felten, bruge telefonens hardware på måder browseren ikke tillader, eller når telefonen er det primære arbejdsredskab.

8. Rapportbygger og avancerede dashboards

Grafer gør sig godt i en demo, og en rapportbygger hvor kunden selv vælger tal og perioder, lyder som noget alle vil have. Ofte ender brugerne dog med at kigge på en håndfuld nøgletal og eksportere resten til Excel.

Find ud af hvilke 3-5 tal din kunde faktisk træffer beslutninger på, og vis dem tydeligt. Tilføj en CSV-eksport (en fil der kan åbnes i Excel) af de vigtigste data. Det er billigt, og hvis du spørger kunderne hvad de bruger filen til, får du at vide præcis hvad de regner på. Når mange eksporterer de samme data hver uge for at lave den samme graf, ved du hvilken rapport du skal bygge.

9. Realtid og notifikationscenter

Live-opdateringer, en klokke med ulæste beskeder, chat mellem brugere og pushbeskeder. Det kræver ekstra infrastruktur som websockets, køer og indstillinger for hvem der vil have besked om hvad. Det giver også nye typer fejl der er svære at teste.

Ved lancering rækker e-mails ved de vigtige hændelser og en oversigt der viser det seneste når brugeren åbner siden. Skal noget opdatere sig selv, kan siden hente nye data med faste mellemrum. Realtid bliver relevant når flere brugere arbejder i de samme data samtidig og ellers overskriver hinandens ændringer, eller når hastighed er selve produktet, fx en booking hvor ledige tider forsvinder på sekunder.

Teknik bag kulissen

Den sidste gruppe kan dine kunder ikke se, men den kan æde en stor del af budgettet. Her handler det om at forberede det billige og udskyde det dyre.

10. Offentligt API og integrationer

Et offentligt API (en dør ind til dit system som andre udviklere kan bruge) kræver dokumentation, versionering, adgangsnøgler, begrænsning af antal kald og support til udviklere du aldrig har mødt. Når det først er ude, kan du ikke ændre det uden at ødelægge andres integrationer, og det binder dig på et tidspunkt hvor produktet bør ændre sig hver uge.

Start med CSV-import, så nye kunder kan flytte deres data ind, og eksport, så de ikke føler sig låst. Bliver der spurgt efter én bestemt integration, typisk regnskab eller kalender, så byg præcis den. Webhooks (automatiske beskeder til andre systemer når noget sker) er et billigt mellemtrin der lader kunderne koble sig på via værktøjer som Zapier eller Make. Byg et rigtigt API når kunder eller partnere vil bygge oven på dit produkt.

11. Flersprogethed

Oversættelse er mere end tekster. Det er datoformater, valuta, moms, vilkår, support på flere sprog og markedsføring på hvert marked. Lanceringen er det dårligste tidspunkt at tage alt det på sig.

Lancér på ét sprog. Men her er en af de få ting jeg anbefaler at forberede fra dag ét: læg brugerfladens tekster i oversættelsesfiler i stedet for at skrive dem direkte i koden. I Laravel sker det med frameworkets indbyggede oversættelsesfunktioner, og det koster næsten intet ekstra mens du bygger. At pille hundredvis af tekster ud af koden bagefter er til gengæld kedeligt og dyrt. Tilføj det næste sprog når du aktivt vil sælge på et nyt marked.

12. Mikroservices og arkitektur til millioner af brugere

Mikroservices, Kubernetes og databaser der kan fordeles over mange servere, er løsninger på problemer som store virksomheder har. For en ny SaaS er det mest sandsynlige problem for få brugere, ikke for mange. Kompleks infrastruktur gør hver ændring langsommere og driften dyrere.

En velstruktureret monolit (én samlet kodebase) på enkel hosting kan typisk bære rigtig mange kunder, især med køer til tunge opgaver og caching (midlertidig lagring af resultater) hvor det er nødvendigt. Brug i stedet kræfterne på det der gør det let at skalere senere: hold koden ryddelig, mål hvor tiden bruges, og vælg udbredt teknologi. Jeg har skrevet om hvordan du vælger den rigtige tech stack til en SaaS. Del først systemet op når målinger peger på en konkret flaskehals.

Det skal din SaaS have fra dag ét

Listen betyder ikke at alt kan vente. Nogle ting er dyre eller umulige at rette efter lanceringen, fordi de handler om tillid og data. Dem ville jeg aldrig skære væk:

Hvor grænsen præcis går for dit produkt, er en del af arbejdet med at afgrænse en SaaS-MVP, som jeg har skrevet en særskilt guide om.

Sådan afgør du om en funktion skal med

Når en ny funktion dukker op på listen, så stil tre spørgsmål i den her rækkefølge:

1. Kan kunden ikke købe uden den? Hvis en rigtig kunde har sagt at de ikke kan bruge produktet uden, hører den med.
2. Er den dyr at tilføje senere? Datamodel, sikkerhed og adskillelse af data hører til her. De fleste brugerflader gør ikke.
3. Kan den klares manuelt eller med en færdig tjeneste i de første måneder? Hvis ja, så vent.

Listen er ikke en lov. Sælger du til hospitaler, banker eller offentlige kunder, kan SSO, logning af hvem der har gjort hvad, og fine rettigheder være krav fra første kontrakt. Er dit produkt en integrationsplatform, er API'et selve produktet. Kend din kunde før du bruger listen.

Vær også opmærksom på din udvikler. Siger vedkommende ja til alle 12 uden at spørge hvorfor, så vær på vagt. Hver funktion er kode der skal testes, opdateres og vedligeholdes i årevis. Og hver funktion der ryger af listen, trækker regningen ned, som du kan se når du regner på hvad en MVP koster.

Kan du ikke nævne fem konkrete virksomheder der har det problem dit produkt løser, er det for tidligt at hyre en udvikler som mig. Så får du mere ud af at tale med potentielle kunder eller teste idéen med en klikbar prototype først.

Næste skridt

Tag din nuværende kravliste og sæt hver funktion i én af tre kasser: nødvendig for det første køb, billig at forberede nu, eller kan vente. Den sidste kasse er som regel den største. Skriv for hver udskudt funktion ned hvilket signal der skal til før du bygger den, så beslutningen ikke skal tages forfra hver gang en kunde nævner den.

Vil du have hjælp til at skære første version til og bygge den, kan du læse om hvordan jeg arbejder med SaaS-udvikling. Større forløb starter typisk med et betalt forprojekt til fast pris, hvor du og jeg bliver enige om funktionslisten før der skrives kode.

Ofte stillede spørgsmål

Hvor mange funktioner skal en MVP have?+

Der er ikke et fast tal, men en MVP skal kunne løse én arbejdsgang fra start til slut, plus det nødvendige omkring den: login, betaling og sikker håndtering af data. Kan du ikke beskrive produktets kerne i én sætning, er det som regel et tegn på at listen er for lang. Mange gode første versioner har færre skærme end stifteren forestiller sig.

Mister jeg ikke kunder hvis funktionerne mangler?+

Du mister måske enkelte, men det er sjældent dine første kunder. Tidlige kunder køber fordi produktet løser et problem de har i dag. Fortæl åbent hvad der er på vej, og spørg hvad funktionen er værd for dem. Vil ingen betale mere for den, har du lært noget vigtigt uden at bruge penge på at bygge den.

Bliver det ikke dyrere at bygge funktionerne senere?+

Som regel ikke meget, hvis fundamentet er lagt rigtigt, og nogle gange bliver det billigere, fordi du ved præcis hvad kunderne har brug for. Undtagelserne er datamodel, sikkerhed og adskillelse af kundedata. Dem skal du tænke igennem fra start, også selvom selve funktionerne bygges senere.

Hvad med AI-funktioner i en MVP?+

Byg dem kun hvis AI er selve grunden til at kunderne køber. En chatbot eller en tekstgenerator tilføjet fordi konkurrenterne har en, giver løbende udgifter pr. kald til sprogmodellen, nye fejltyper og spørgsmål om persondata. Er AI ikke kernen, så lancér uden og tilføj det når du ved hvilken opgave det skal løse.