Hvad koster det at udvikle
en SaaS-platform?

Prisen ligger ikke i siderne

Den mest udbredte misforståelse om SaaS-udvikling er at prisen hænger sammen med antallet af skærmbilleder. "Vi har brug for login, dashboard, profil og en indstillingsside — det kan vel ikke tage så lang tid?"

Det kan det godt. Ikke fordi skærmbillederne er svære at designe, men fordi hvert skærmbillede forudsætter beslutninger om hvem der må se det, hvad der sker i baggrunden, hvordan data er struktureret, og hvad der sker når noget går galt.

Det der reelt driver prisen på en SaaS-platform er: brugerroller, dataarkitektur, workflows, integrationer, administration og drift. Lad os gennemgå dem en ad gangen.

De seks faktorer der driver budgettet

1. Brugerroller og adgangsstyring

Har I ét brugertype eller flere? En platform med én slags bruger er relativt enkel. Tilføj en adminrolle, en superadmin, en readonly-rolle og en ekstern partner-rolle — og kompleksiteten mangedobles. Hvert skærmbillede skal nu validere hvad den aktuelle bruger må se og gøre. Det er ikke svært, men det tager tid at gøre rigtigt.

2. Datamodel og arkitektur

Databasedesign er fundamentet alt andet bygger på. En dårligt tænkt datamodel koster det dobbelte at rette senere. Skal platformen understøtte flere lejere (multi-tenancy)? Skal data kunne eksporteres, auditeres eller slettes per GDPR-anmodning? Skal historik bevares? Disse valg tages tidligt og er dyre at omgøre.

3. Workflows og forretningslogik

Det er her det meste af udviklingstiden gemmer sig. En "simpel" funktion som "send en notifikation når en ordre skifter status" indeholder typisk ti undtagelser ingen tænkte på fra start: Hvad hvis ordren annulleres? Hvad hvis brugeren har slået notifikationer fra? Hvad hvis systemet er nede? Hvad hvis mailen bouncer?

Jo mere forretningslogik platformen skal understøtte, jo dyrere er det — og jo vigtigere er det at kortlægge den grundigt inden udviklingen begynder.

4. Integrationer

Skal platformen tale med andre systemer? Betalingsgateways (Stripe, Nets), regnskabssystemer (e-conomic, Dinero), CRM, e-mail-udbydere, SMS-tjenester? Hver integration er et selvstændigt projekt med sin egen fejlhåndtering, autentificering og vedligeholdelse. To-tre velvalgte integrationer er realistisk i en MVP. Ti integrationer fra dag ét er et faresignal.

5. Administration og backoffice

Den del ingen taler om — men som altid er større end forventet. Hvem administrerer platformen? Hvordan opretter man nye kunder? Hvordan håndterer man support-cases, refunderinger, kontospærringer? Et solidt admin-panel kan let svare til 20–30% af den samlede udviklingstid.

6. Drift, sikkerhed og skalerbarhed

Cloud-arkitektur, backup-strategi, SSL, rate limiting, logging, monitorering — det er ikke sexy, men det er det der afgør om platformen holder når den rammer 1.000 brugere i stedet for 10. Det er typisk undervurderet i prisoverslag.

Hvad koster det så — konkret?

Med forbehold for at alle projekter er forskellige, er her et realistisk overblik over prisspænd for forskellige typer SaaS-projekter i Danmark i 2026:

MVP eller fuld platform — hvad giver mening?

Det korte svar: næsten altid MVP først.

Ikke fordi det er billigere (det er det), men fordi det er klogere. En platform bygget over 18 måneder ud fra antagelser om hvad brugerne vil have, ender sjældent med at ramme plet. En MVP bygget over 4–6 måneder og sat i produktion giver noget langt mere værdifuldt: rigtige brugeres rigtige adfærd.

Et godt MVP-scope starter med ét spørgsmål: Hvad er den mindste version af denne platform der løser det kerneproblem brugeren har? Alt der ikke bidrager direkte til at besvare det spørgsmål, hører til i backloggen.

Hvad bør altid med i en MVP?

• Brugeroprettelse og login (herunder adgangskode-reset — det glemmer alle)
• Kerneflowet — den ene ting platformen primært skal kunne
• Simpel admin-adgang til at håndtere brugere og data
• Grundlæggende sikkerhed og GDPR-compliance
• Et veldefineret betalingsflow, hvis det er forretningsmodellen

Hvad hører typisk til version 2?

• Avancerede notifikationsindstillinger
• Eksport og rapportering
• API til tredjeparter
• Whitelabeling og tilpasning per kunde
• Avancerede brugerroller og tilladelsessystemer

Fastpris eller løbende — og hvad betyder det?

De fleste ønsker en fastpris. Det er forståeligt — det giver budgetsikkerhed. Men fastpris forudsætter et fastlagt scope, og de færreste har det når de henvender sig.

Den ærlige version: fastpris-projekter med uklart scope ender typisk med en af to ting — enten leverandøren bygger præcis det der stod i kontrakten (men ikke det I reelt havde brug for), eller projektet fører til uenighed om hvad der var aftalt.

Alternativet er løbende samarbejde med tydelige milepæle og prioriteret backlog. Det giver fleksibilitet til at justere undervejs — og det er realistisk set den model der oftest leverer det bedste resultat, fordi I lærer noget nyt for hver sprint.

Det vigtigste råd

Prioritér tydeligt og design første version med fokus på kerneværdi. Det lyder enkelt. Det er svært i praksis, fordi der altid er nogen i organisationen der vil tilføje "bare én ting til".

Det næstvigtigste råd: vælg en leverandør der er villig til at sige fra. En god udviklingspartner hjælper jer med at skære scope til — ikke med at sige ja til alt. Ja til alt er en advarsel, ikke en fordel.

Og det tredje råd: sæt penge af til det uventede. I et SaaS-projekt vil der altid opstå noget I ikke havde forudset. Det er ikke dårlig planlægning — det er softwareudvikling. Et budget-buffer på 20% er ikke pessimisme, det er realisme.