White-label SaaS: hvad det er, og hvornår det kan betale sig

White-label SaaS er software som én virksomhed udvikler og driver mens andre virksomheder sælger den til deres egne kunder under eget navn, logo og domæne. Slutkunden ser kun partnerens brand og ved typisk ikke hvem der har bygget produktet. Det kan betale sig når dine kunder bedst nås gennem mellemled som bureauer, konsulenter eller kæder, men det kræver langt mere end et felt hvor partneren kan uploade sit logo.

Det meste af arbejdet ligger i datamodellen, domænerne, e-mailopsætningen og alle de små steder hvor dit eget navn gemmer sig. Det er dem jeg gennemgår her, set fra den side der skal bygge det.

Den korte version

White-label er ikke enten-eller. Det findes i niveauer, og hvert niveau koster mere at bygge og drive end det forrige.

Indsatsen er et groft skøn og forudsætter at produktet allerede holder kunders data adskilt. Min tommelfingerregel er at bygge det niveau som en betalende partner beder om i dag, og ikke mere. Niveau 4 er reelt et nyt forretningsområde med support, aftaler og afregning, ikke bare en udviklingsopgave.

White-label er en udvidelse af en SaaS der allerede virker. Mangler du fundamentet, så start med min komplette guide til at bygge en SaaS.

Hvad white-label SaaS er, og hvad det ikke er

Ordet bruges om to forskellige situationer, og det hjælper at holde dem adskilt. I den ene ejer du en SaaS og lader partnere sælge den under deres brand. I den anden ejer du ikke noget software, men køber et færdigt white-label-produkt og sælger det som dit eget. Så er du partneren, og opgaven handler om indkøb og aftaler, ikke om udvikling.

Der findes også en række nabobegreber som ofte bliver blandet sammen:

• Co-branding eller "leveret af": partnerens logo står i appen, men dit navn er stadig synligt et sted. Det kræver langt mindre end fuld white-label.
• Forhandler (reseller): partneren sælger dit produkt under dit navn og får provision. Ingen rebranding.
• Private label: bruges i software ofte om det samme som white-label. Nogle bruger det om en version der er lavet eksklusivt til én forhandler.
• En separat installation pr. kunde: det er single-tenant drift, ikke white-label. Det er dog ofte dér det ender hvis white-label ikke er bygget ordentligt ind fra start.

Fælles for dem alle er at partneren får ret til at bruge og sælge produktet. Koden og driften bliver hos dig.

Hvornår white-label kan betale sig, og hvornår ikke

Når du ejer produktet

Det er gode tegn når:

• Dine kunder allerede køber gennem mellemled, fx bureauer, revisorer, konsulenthuse, franchisekæder eller brancheforeninger der ejer kunderelationen.
• Partnerne selv beder om det og er villige til at betale, fx et fast månedligt beløb plus et beløb pr. aktiv kunde.
• Produktet er stabilt, og en ny kunde kan komme i gang uden at du skal hjælpe.
• Dit produkt indgår i partnerens egen ydelse, fx en kundeportal som et bureau leverer til sine kunder.

Det er dårlige tegn når:

• Du endnu ikke ved hvad dine egne kunder vil betale for. White-label lægger et led mellem dig og brugerne, og så lærer du langsommere.
• Én partner står for det meste af omsætningen. Så har partneren reelt kontrollen over din køreplan.
• Partnerne vil have hver deres funktioner. Så er det kundetilpasset udvikling forklædt som et produkt.
• Dit eget brand er din vigtigste salgskanal. Ser ingen dit navn, får du heller ingen anbefalinger.

Når du vil sælge andres software under eget navn

At købe et færdigt white-label-produkt er tit det rigtige valg og meget billigere end at bygge selv. Dækker et eksisterende produkt det meste af dit behov, er mit ærlige råd at købe det og bruge pengene på salg, ikke at hyre en udvikler som mig til at bygge det fra bunden.

Bagsiden er at du ikke styrer køreplanen, at leverandøren kan hæve prisen, og at det er svært at flytte dine kunder hvis leverandøren lukker. Spørg altid om du kan få dine kunders data ud i et brugbart format. Overvejer du det til en kundeportal, har jeg sammenlignet en skræddersyet kundeportal med et white-label-produkt.

Trin 1-4: datamodel, temaer, domæner og e-mail

Har du besluttet at åbne for partnere, er det disse otte trin der afgør om det bliver ét produkt eller en stak særløsninger. De første fire handler om fundamentet.

1. Giv partneren en plads i datamodellen. Med white-label kommer der et niveau over kunden: partner, kunde, bruger. Partneren skal kunne oprette kunder og se deres forbrug, men aldrig se kunder hos en anden partner. Testene skal dække begge grænser. Hvordan selve kundeadskillelsen bygges, har jeg forklaret i indlægget om multi-tenant-arkitektur.
2. Gem branding som data, ikke som kode. Logo, farver, favicon og produktnavn gemmes pr. partner i databasen og sættes ind som CSS-variabler. Så kræver en ny partner ingen ny udgivelse. Giv ikke partnere fri adgang til egen CSS. Det går i stykker ved dit næste redesign. Tjek også kontrasten automatisk, for en lys brandfarve på hvid baggrund er ofte ulæselig.
3. Understøt egne domæner med automatiske certifikater. Partneren peger sit domæne på din server med en CNAME-post, og serveren skal selv hente og forny certifikatet. Caddys on-demand TLS og Cloudflare for SaaS er lavet til netop det. Med Caddy skal du bygge et endpoint der godkender hvert domæne, ellers kan fremmede få din server til at udstede certifikater. Husk også login: cookies gælder kun ét domæne, og Google- eller Microsoft-login kræver typisk at hver adresse er registreret hos udbyderen.
4. Send e-mail fra partnerens domæne, eller lad være. Sender din server mails fra partnerens domæne, ender de i spam hvis partneren ikke har sat SPF og DKIM op. Googles krav til afsendere har siden februar 2024 betydet at alle der sender til Gmail-adresser, skal bruge SPF eller DKIM. Sender du over 5.000 mails om dagen til Gmail, kræves både SPF og DKIM, DMARC og et afsenderdomæne der matcher. Byg en side der viser partneren de præcise DNS-poster og tjekker dem. Indtil posterne er bekræftet, sender du fra dit eget domæne med partnerens navn som afsendernavn.

Trin 5-8: tekster, partnerpanel, betaling og GDPR

De næste fire trin er dem der oftest bliver glemt fordi de ikke handler om selve appen.

5. Find alle steder dit eget navn står. Det er sjældent selve appen der afslører dig. Det er velkomstmailen, kvitteringen fra betalingsudbyderen, PDF-eksporten, fejlsiden ved nedbrud, titlen i browserfanen, hjælpeartiklerne og API-dokumentationen. Erstat produktnavn og links med variabler i alle skabeloner og sprogfiler. En enkel test er at oprette en partner med et opdigtet navn og søge efter dit eget i alt det systemet sender ud.
6. Byg et partnerpanel med klare roller. Partneren skal kunne oprette og lukke kunder, se forbrug og ændre branding, og det kræver mindst roller som partneradministrator, partnersupport, kundeadministrator og bruger. Kan partnerens support logge ind som en kunde, skal det logges. Aftal også hvem der svarer slutkunden. Typisk tager partneren første linje i supporten og du anden linje fordi slutkunden ikke kender dig.
7. Beslut hvem der fakturerer slutkunden. Enten fakturerer du partneren en engrospris, fx pr. aktiv kunde, og partneren sætter selv sin pris. Eller du fakturerer slutkunderne på partnerens vegne og deler omsætningen, fx med Stripe Connect, der er bygget til platforme der modtager betalinger for andre. Den første model er langt enklest, og i den anden bliver momsen mere kompliceret når partnere og slutkunder sidder i forskellige EU-lande. Læs prismodellerne til SaaS og mine noter om abonnementsbetaling med Stripe, Paddle eller en dansk løsning før du lover partnerne noget.
8. Få databehandleraftalerne til at hænge sammen. Ofte er slutkunden dataansvarlig, partneren databehandler og du underdatabehandler. Artikel 28 i GDPR kræver den dataansvarliges skriftlige godkendelse af underdatabehandlere og de samme databeskyttelseskrav hele vejen ned i kæden. Partneren skal altså kunne oplyse dig som underdatabehandler selv om dit navn ellers ikke står nogen steder. De tekniske krav finder du i min GDPR-tjekliste til SaaS. Det her er ikke juridisk rådgivning.

De typiske faldgruber

De fleste problemer med white-label opstår ikke ved den første partner. De opstår ved den tredje.

• En kopi af koden pr. partner. Det føles hurtigt den første gang. Ved tredje partner skal hver fejlrettelse laves tre steder, og kopierne glider fra hinanden. Alt der adskiller partnerne, skal være indstillinger der slår funktioner til og fra, ikke separate versioner.
• Partnerens ønsker bliver din køreplan. En stor partner vil have sine egne funktioner. Sig kun ja til det der også gavner de andre partnere, eller tag betaling for det som særskilt udvikling.
• Engrosprisen er for lav. Partneren skal tjene penge på at videresælge, og du skal stadig dække drift og support i anden linje. En pris der kun lige dækker dine omkostninger, holder ikke når antallet af slutkunder vokser.
• Du kan ikke se hvorfor kunderne stopper. Kunderelationen ligger hos partneren, så du hører ikke klagerne. Byg din egen statistik over aktivitet og opsigelser pr. partner fra start.
• Egne domæner uden automatik. Certifikater der fornyes i hånden, udløber før eller siden, og så møder partnerens kunder en sikkerhedsadvarsel i stedet for appen.
• Ingen exitplan. Hvad sker der med kundernes data hvis partneren stopper? Kan kunderne flyttes direkte over til dig eller til en anden partner? Skriv det ind i aftalen før den første kunde bliver oprettet.

Næste skridt

Er du stadig i tvivl om white-label er det rigtige, så start med ét niveau og én partner, og byg resten når den næste partner står klar til at betale. Brug tjeklisten herunder før du siger ja.

Vil du se hvordan jeg griber den slags an, fra et forprojekt til fast pris til færdig kode som du ejer fra første dag, så læs om min udvikling af SaaS-produkter.

Ofte stillede spørgsmål

Kan jeg gøre min eksisterende SaaS white-label bagefter?+

Ja, men omfanget afhænger af hvordan den er bygget. Har alle tabeller et kunde-id, og står produktnavnet i sprogfiler i stedet for spredt i koden, handler det mest om at tilføje partnerniveauet, temaer og domæner. Er navne, farver og adresser hardcodet mange steder, eller mangler adskillelsen mellem kunder, er det dér du starter, og det er typisk den største del af arbejdet.

Får partneren adgang til kildekoden?+

Nej, normalt ikke. En white-label-aftale giver partneren ret til at bruge og videresælge produktet under eget navn mens du beholder koden, driften og retten til at videreudvikle. Vil en partner have koden, er det en anden slags aftale: en kildekodelicens eller et køb af produktet. Det kan være fornuftigt over for en meget stor partner, men så mister du typisk kontrollen over den version de kører.

Hvad skal en white-label-aftale indeholde?+

Som minimum pris og betalingsmodel, hvem der supporterer slutkunderne, oppetid og svartider, regler for brug af brandet, databehandleraftaler, og hvad der sker med kunder og data hvis aftalen ophører. Aftal også om du må kontakte slutkunderne direkte ved nedbrud eller sikkerhedshændelser. Det her er ikke juridisk rådgivning, så få en advokat til at læse aftalen igennem før den bliver underskrevet.

Kan hver partner få sin egen app i App Store?+

Som udgangspunkt ikke, hvis du selv indsender dem. Apples retningslinje 4.2.6 afviser apps lavet ud fra en kommerciel skabelon eller appgenerator medmindre de indsendes direkte af den virksomhed hvis indhold appen viser. Alternativerne er én fælles app hvor brugeren vælger sin partner, eller at hver partner indsender appen fra sin egen udviklerkonto. En webapp kan derimod sagtens bære hver partners brand.