Et SaaS-produkt kan leve længe på små og mellemstore kunder uden at møde de samme krav. Så kommer den første store kunde, og listen er næsten altid ens: SSO, automatisk brugerstyring, finere roller, en revisionslog og et åbent API. Kravene kaldes ofte enterprise-krav, og de er sjældent svære hver for sig. Det svære er, at de griber ind i brugerstyringen, som tit er bygget i produktets første uger. Her gennemgår vi, hvad kravene betyder, og i hvilken rækkefølge de bør komme, så I kan have svaret klar, før de standser en aftale.
Hvad kravene betyder
SSO (single sign-on). Medarbejderne logger ind med deres konto hos kunden, fx i Microsoft Entra ID, i stedet for en særskilt adgangskode hos jer. For kunden betyder det, at en medarbejder, der stopper, mister adgangen ét sted. SAML og OpenID Connect er de to teknikker, der oftest bruges.
Automatisk brugerstyring. Her sender kundens system selv besked til jeres produkt, når en bruger oprettes, ændres eller fjernes. Standarden hedder SCIM. Uden den skal nogen hos kunden gøre det i hånden.
Roller og rettigheder. Kunden vil kunne bestemme, hvem der må se, ændre og godkende hvad, ofte delt efter afdeling. To roller, administrator og bruger, holder sjældent.
Revisionslog. En audit log er en liste over, hvem der gjorde hvad og hvornår i produktet, som kunden selv kan læse og eksportere. Den er noget andet end de tekniske logfiler, udviklerne bruger til fejlfinding, og den må ikke kunne ændres af brugerne.
Åbent API. Kunden vil koble produktet til sine egne systemer. Et API er en dokumenteret indgang, som andre systemer kan bruge. Det, der tæller, er, at det er beskrevet, versioneret og holder, når I udgiver nye versioner. Et API, der kun bruges af jeres egen app, er sjældent klar til at blive vist frem.
Hvorfor kravene hænger sammen
Alle fem hviler på den samme grundmodel: hvordan produktet forstår en organisation, en bruger og en rettighed. Er modellen bygget, så en bruger er knyttet til en adgangskode og hører til én konto, skal den udbygges, før SSO og roller kan komme ordentligt på plads. Det er derfor, den første vurdering bør handle om datamodellen. Spørg lead developeren:
- Kan én bruger høre til flere organisationer, og kan en organisation have flere afdelinger?
- Findes der ét sted i koden, hvor rettigheder bliver tjekket, eller er tjekket spredt rundt?
- Skriver produktet allerede ned, hvem der gør hvad, i en form, der kan vises til kunden?
Svarene viser, hvor meget arbejdet fylder. Er rettighedstjek spredt ud over hele koden, er roller den store opgave, og den skal planlægges som sådan.
En rækkefølge, der virker for de fleste
Rækkefølgen afhænger af jeres kunder, men denne vej er sjældent forkert:
- Grundmodellen. Organisation, bruger og rettigheder gøres klar. Det er usynligt for kunden og gør resten lettere.
- SSO. Det krav, der oftest stopper en aftale. Mange vælger en færdig tjeneste til login frem for at bygge selv; valget er beskrevet i bygge, købe eller integrere.
- Roller. Begynd med de få roller, kunderne faktisk efterspørger, og giv plads til flere. Fuldt frie roller kan vente.
- Revisionslog. Begynd at registrere de vigtige handlinger tidligt, også før der er en skærm til det. Historik kan ikke laves bagefter.
- Automatisk brugerstyring. Kommer ofte naturligt efter SSO, når kunden er stor nok til at bede om det.
- Offentligt API. Dokumentation, nøgler, begrænsninger på brug og regler for ændringer. Vent med at vise det frem, til I er klar til at holde det stabilt, for en kundes integration binder jer.
Den tekniske rækkefølge bør vejes mod salget. Står en bestemt aftale og venter på ét krav, kan det rykke frem, når grundmodellen tillader det.
Sæt det på køreplanen, før kunden gør det
Disse krav fylder lidt, når de planlægges, og meget, når de bygges under pres. Læg dem på den tekniske køreplan, når de første større kunder dukker op i salgsfeltet, og bed salg om at notere, hvor kravene dukker op. Ofte ligger de også i kundens spørgeskema, så I kan se dem, før nogen beder om dem direkte.
Aftal også, om funktionerne hører til en særlig kundepakke. Det er en forretningsbeslutning, men den påvirker tekniske valg, for en funktion, der kan slås til pr. kunde, skal bygges sådan fra start. Bliver én kundes krav så store, at de begynder at styre planen, er det et andet spørgsmål, se én stor kunde vil bestemme køreplanen. Sker det i møde med kundens folk, hjælper forberedelsen til arkitektens møde.
Et godt svar til kunden er en dato, I kan holde, og en beskrivelse af, hvad der kommer først. Skal I have vurderet rækkefølgen af en, der har prøvet det før, kan det indgå i det løbende arbejde med en fractional CTO.
Det skal I lade være med
- At bygge en særlig SSO-løsning til én kunde · næste kunde bruger en anden opsætning, og så har I to.
- At love frie roller, fordi det lyder enkelt · det griber ind i hele produktet og kan sjældent tages tilbage.
- At vise et internt API frem som offentligt · hver ændring kan så vælte en kundes integration.
- At vente med revisionslogen, til nogen beder om den · de manglende handlinger kan ikke hentes frem.
Det skal I kræve af den eksterne
- ☐ En vurdering af brugermodellen, før der gives datoer.
- ☐ En rækkefølge, der er begrundet i kunder og teknik.
- ☐ Valg om at købe eller bygge login, skrevet ned med begrundelse.
- ☐ Regler for API-versioner og varsel om ændringer.
- ☐ Et svar til salg, som de kan bruge i dag.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Arkitekturbeslutninger, der er dyre at lave om · Multi-tenant eller én installation pr. kunde
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
