SaaSTjekliste
enRead in EnglishSaaS-lanceringstjekliste: 30 ting før du åbner for betalende kunder
SaaS-lanceringstjekliste med 30 punkter om betaling, moms, mails, backup, overvågning og vilkår, før du åbner for de første betalende kunder.
Freelance full-stack udvikler
- Udgivet
- Læsetid
- 8 min.
Indhold i indlægget9
Før du åbner for betalende kunder, skal seks områder være på plads: betaling og moms, mails, data og backup, overvågning, vilkår og support. Min SaaS-lanceringstjekliste deler dem op i 30 konkrete punkter, som du kan krydse af ét ad gangen. Det er de ting, der koster penge, data eller kundernes tillid, hvis de mangler den første uge.
Den korte version: seks områder, 30 punkter
| Hvis det mangler | Vigtigste punkt | |
|---|---|---|
| Betaling og moms | Kunder bliver ikke opkrævet, eller momsen er forkert | En rigtig betaling med live-nøgler |
| Mails | Bekræftelser og nulstilling af adgangskode lander i spam | SPF, DKIM og DMARC på dit domæne |
| Data og sikkerhed | Datatab, eller kunder der ser hinandens data | En gendannelse du har prøvet |
| Overvågning og drift | Kunderne opdager nedetid før dig | Alarm til en navngiven person |
| Vilkår og GDPR | Virksomhedskunder kan ikke købe | Databehandleraftale klar til kunderne |
| Support og måling | Du ved ikke, hvorfor folk ikke betaler | En udenforstående har testet tilmeldingen |
Min tommelfingerregel: funktioner kan vente, betaling og data kan ikke. Hvilke funktioner du kan udskyde, står i listen over funktioner din SaaS kan undvære ved lancering. Hele vejen fra idé til første kunde finder du i guiden til at bygge en SaaS.
Betaling og moms: punkt 1-5
Her koster en fejl penge direkte. Testmiljøet hos Stripe eller Paddle opfører sig næsten som det rigtige, men kun næsten.
Betaling og moms
- 1. Hele forløbet er testet: oprettelse, planskift, fejlet betaling, nyt kort og opsigelse, med udbyderens testkort.
- 2. Webhooks virker i live-tilstand: de beskeder, udbyderen sender til din app ved fx en betaling, bliver signaturtjekket, og den samme besked kan komme to gange uden at noget sker dobbelt.
- 3. Live-tilstand er klar: live-nøgler ligger kun på serveren, priserne er oprettet i live, og du har lavet én rigtig betaling med dit eget kort og refunderet den.
- 4. Fejlede betalinger har en plan: du ved, hvor længe kunden beholder adgangen, og hvad kunden ser, når kortet afvises.
- 5. Moms og fakturaer er rigtige: 25 % moms til danske kunder, omvendt betalingspligt med valideret momsnummer til virksomheder i andre EU-lande, og dit CVR-nummer på fakturaen.
Stripe har sin egen tjekliste til at gå live, som blandt andet anbefaler at skifte nøglerne og teste med dubletter. Sælger du til forbrugere i andre EU-lande for over 10.000 euro om året, skal du opkræve moms i kundens land, typisk via EU's One Stop Shop. Få en revisor til at se på opsætningen, og læs sammenligningen af abonnementsbetaling til SaaS, hvis du ikke har valgt udbyder endnu.
Mails der når frem: punkt 6-10
Din SaaS sender mails, som kunden venter på: bekræft din mail, nulstil adgangskode, invitation og kvittering. Kommer de ikke frem, ser produktet ødelagt ud, selvom koden virker.
Mails
- 6. Mails sendes via en mailudbyder: fx Postmark, Mailgun eller Amazon SES, ikke direkte fra serveren.
- 7. Domænet er godkendt: SPF, DKIM og DMARC er sat op i DNS for det domæne, du sender fra.
- 8. Alle systemmails er gennemgået: tekst, afsender og links, så intet peger på testmiljøet. Også mails, der kun sendes ved fejl.
- 9. Mails er testet hos de store: sendt til Gmail og Outlook og tjekket for spam.
- 10. Svar bliver læst: svar-til-adressen går til en indbakke, du holder øje med, og afviste mails bliver registreret.
Ifølge Googles retningslinjer for afsendere skal alle, der sender til Gmail, have SPF eller DKIM, og sender du over 5.000 mails om dagen, kræves også DMARC. Jeg anbefaler alle tre fra dag ét. Det tager typisk under en time, og det er langt sværere at rette, når mailtjenesterne først har lært, at dine mails er spam. Hold også nyhedsbreve og systemmails på hvert sit underdomæne.
Data, sikkerhed og backup: punkt 11-15
Her sidder de fejl, du ikke kan rette bagefter. En kunde, der har set en anden virksomheds data, kommer sjældent igen.
Data, sikkerhed og backup
- 11. Automatisk backup uden for serveren: databasen bliver sikkerhedskopieret mindst dagligt, og kopien ligger et andet sted end appen.
- 12. Gendannelsen er prøvet: du har gendannet en backup i et separat miljø og ved, hvor lang tid det tager.
- 13. Filer er med: uploads som billeder, PDF'er og bilag er dækket af backuppen, ikke kun databasen.
- 14. Kunderne er adskilt: testet med to testkonti i hver sin virksomhed, der prøver at se hinandens data via URL'er og API.
- 15. Produktionen er låst ned: debug-tilstand er slået fra, loginforsøg er begrænset, og der er to-faktor på hosting, betaling, domæne og GitHub.
Debug-tilstand er en klassiker: I Laravel kan APP_DEBUG=true i produktion vise følsomme oplysninger om opsætningen til alle besøgende. Hvordan du sætter backup op efter 3-2-1-reglen og tester gendannelsen trin for trin, står i min guide til backup af webapps.
Overvågning og drift: punkt 16-20
Efter lanceringen dukker fejl op, som ingen test fandt. Spørgsmålet er, om du hører om dem fra et værktøj eller fra en irriteret kunde.
Overvågning og drift
- 16. Oppetid overvåges: UptimeRobot, Oh Dear, Better Stack eller lignende giver besked, når appen er nede.
- 17. Fejl bliver rapporteret: Sentry, Flare eller lignende sender fejl med nok detaljer til at rette dem.
- 18. Baggrundsjob overvåges: køer og planlagte opgaver som fakturering og udsendelse af mails slår alarm, hvis de stopper.
- 19. Udgivelser kan gentages: en ny version kommer i drift med én kommando eller ét klik, og du ved, hvordan du ruller tilbage.
- 20. Domæne og certifikat fornyes automatisk: domænet står i virksomhedens navn, og både domæne og SSL-certifikat fornyes af sig selv.
Værktøjet er mindre vigtigt end hvem alarmen går til. Beslut hvem der reagerer om aftenen og i weekenden. Hold særligt øje med køen: når den går i stå, ser appen ud til at virke, mens mails og fakturaer hober sig op.
Vilkår, privatliv og GDPR: punkt 21-25
Virksomhedskunder spørger ofte efter vilkår og databehandleraftale, før de spørger efter funktioner. Uden dem kan salget gå i stå hos kundens indkøbsafdeling.
Vilkår, privatliv og GDPR
- 21. Abonnementsvilkår: betaling, opsigelse, prisændringer, ansvarsbegrænsning og hvad der sker med data, når kunden stopper.
- 22. Privatlivspolitik: hvilke persondata du behandler om brugerne, hvorfor, hvor længe og hos hvilke leverandører.
- 23. Databehandleraftale: en standardaftale, kunderne kan acceptere, fordi du behandler persondata på deres vegne.
- 24. Liste over underdatabehandlere: hosting, mail, betaling, fejlrapportering, support og statistik, og hvor data ligger.
- 25. Firmaoplysninger og cookies: navn, adresse, CVR-nummer og mail står synligt, og cookies til statistik eller annoncer sættes først efter samtykke.
Kravet om mail og CVR-nummer på siden kommer fra e-handelsloven, og Forbrugerombudsmanden har håndhævet det over for virksomheder, der manglede det. Sælger du til forbrugere, gælder også regler om fortrydelsesret. Få en advokat til at læse vilkårene, for tjeklisten er ikke juridisk rådgivning. De tekniske krav bag, fx eksport og sletning af data, gennemgår jeg i GDPR-tjeklisten til SaaS.
Support, onboarding og måling: punkt 26-30
De første betalende kunder lærer du mest af. Gør det let for dem at komme i gang, få hjælp og stoppe igen.
Support, onboarding og måling
- 26. Tilmeldingen er testet af en udenforstående: en person, der ikke har set produktet før, kommer fra tilmelding til første resultat uden din hjælp.
- 27. Der er en supportkanal: kunderne ved, hvor de skriver, og hvornår de kan forvente svar.
- 28. Du har et adminoverblik: du kan finde en kunde, forlænge en prøveperiode og refundere uden at gå i databasen.
- 29. Kunden kan opsige og få sine data: opsigelse og eksport virker, og du har besluttet, hvornår data slettes.
- 30. Du måler det vigtigste: tilmeldinger, aktivering, betalinger og opsigelser kan ses et sted, du faktisk kigger.
Punkt 26 er billigt og afslører mere end de fleste tests. Sæt en person foran produktet, giv dem en opgave, og sig ingenting. Flere greb til de første minutter i produktet står i 11 greb til bedre SaaS-onboarding.
Næste skridt: fra tjekliste til lancering
Gå listen igennem, og markér hvert punkt som klar, mangler eller bevidst udskudt. Det er fint at vente med fx en statusside, så længe det er et valg og ikke en forglemmelse.
Mange punkter kan du klare selv: vilkår, supportkanal, test af tilmeldingen og gennemgang af mails. Har du bygget produktet i et no-code-værktøj med indbygget betaling og hosting, er flere tekniske punkter løst for dig, og så er en udvikler sjældent pengene værd lige før lanceringen. Hent derimod hjælp til webhooks, adskillelse af kunder og backup, hvis du ikke selv kan teste dem. Her er fejlene usynlige, indtil de koster noget.
Vil du have hjælp til de tekniske punkter eller til at bygge produktet færdigt, kan du se hvordan jeg arbejder med udvikling af SaaS-produkter. Du taler direkte med mig, og du ejer koden fra dag ét.
Ofte stillede spørgsmål
Hvor lang tid før lanceringen skal jeg starte på tjeklisten?
Start to til fire uger før. De fleste punkter går hurtigt, men nogle afhænger af andre: DNS-ændringer, aktivering af kontoen hos betalingsudbyderen og vilkår fra en advokat kan tage dage. Begynd med betaling og vilkår, og gem testen af tilmeldingen til sidst, når produktet ikke længere ændrer sig dagligt.
Bør jeg lave en soft launch først?
Ja, til de fleste B2B-produkter anbefaler jeg det. En soft launch betyder, at du først åbner for en lille, udvalgt gruppe, fx fra din venteliste. Fejl rammer færre, og du kan tale med hver kunde. Tjeklisten gælder stadig fuldt ud, for de første kunder betaler også rigtige penge og lægger rigtige data ind.
Skal jeg have en penetrationstest før lanceringen?
Sjældent før de første kunder, medmindre du håndterer følsomme data som helbred eller økonomi, eller en stor kunde kræver det. De fleste nye SaaS-produkter får mere ud af at gennemgå punkt 11-15 grundigt og få en udvikler til at teste adskillelsen mellem kunder. En penetrationstest er mest nyttig, når produktet er mere stabilt, og kunderne begynder at spørge efter den.