Hvad koster skræddersyet software? Fra lille værktøj til større system (2026)

Skræddersyet software koster typisk fra ca. 15.000 kr. for et lille værktøj der automatiserer én opgave, til 500.000 kr. og op for et større system med mange brugere og integrationer. Prisen på skræddersyet software er i praksis timer gange timepris, og antallet af timer afhænger mest af hvor mange arbejdsgange, brugerroller og integrationer systemet skal håndtere.

Jeg er selv freelanceudvikler og bygger den slags systemer. Jeg har altså en interesse i sagen, og derfor er der også et afsnit om hvornår du ikke skal få noget bygget.

Den korte version

Tabellen er mit grove skøn over timeforbrug i fire typiske størrelser. Priserne er regnet med 800-1.200 kr. i timen, som ifølge Lønradar er det normale spænd for en senior freelancekonsulent i Danmark i 2026. Bureauer og softwarehuse ligger ofte højere fordi salg og projektledelse også skal betales.

En simpel beslutningsregel: Kan du beskrive opgaven i én sætning, og er det kun dine egne medarbejdere der skal bruge den, så er du sandsynligvis i de to øverste rækker. Skal kunder logge ind, eller skal systemet tale sammen med jeres økonomisystem, CRM og lager, så er du i de to nederste.

Timerne er den stabile del af regnestykket. Timeprisen svinger mere, og den har jeg gennemgået i guiden til timepriser for freelanceudviklere. Vil du se priserne på tværs af alle typer projekter, fra hjemmesider til SaaS, så har jeg samlet dem i den store prisguide til softwareudvikling.

Hvorfor den lille ende sjældent har en pris

Søger du på priser for skræddersyet software, finder du mest guides skrevet af softwarehuse, og de starter højt. Keyhole Software angiver for eksempel 40.000-120.000 dollars for de simpleste projekter i deres prisguide fra 2026. Det er dollartal fra et amerikansk softwarehus for projekter der tager 2-4 måneder, men pointen gælder også herhjemme: et projekt på 40 timer passer dårligt ind i et softwarehus' forretningsmodel.

Det skyldes ikke grådighed. Et softwarehus har faste omkostninger på hvert projekt: salg, tilbud, projektleder, opstartsmøder, test og overdragelse. Omkostningerne er næsten de samme uanset om projektet er på 40 eller 400 timer. Derfor har de fleste en minimumsstørrelse, og under den bliver opgaven enten afvist eller pakket ind så den fylder mere end den behøver.

Den lille ende er typisk opgaver som:

• et script der hver nat henter data fra ét system og lægger dem over i et andet
• en intern side hvor medarbejderne registrerer det der i dag ligger i et delt regneark
• en ugentlig rapport som nogen bruger en fredag eftermiddag på at samle i hånden
• et lille administrationspanel oven på en database I allerede har

Den slags opgaver passer godt til en freelancer eller et lille udviklingsfirma. Der er ingen projektleder imellem, og den der skriver koden, er også den du taler med. Til gengæld får du ikke et team der kan skalere op fra den ene uge til den næste, og ferie eller sygdom rammer direkte.

Fire eksempler fra lille værktøj til større system

Eksemplerne er typiske opgaver, ikke kundecases. Timetallene er grove skøn og forudsætter at opgaven er afklaret før udviklingen starter.

1. Ugentlig rapport fra to systemer (ca. 20-40 timer)

En virksomhed trækker hver uge tal ud af webshoppen og økonomisystemet, sætter dem sammen i Excel og sender dem til ledelsen. Et lille program kan hente dataene via de to systemers API (den indgang som andre programmer bruger til at hente og sende data), regne nøgletallene ud og sende rapporten på mail mandag morgen.

Der er ingen brugerflade at designe og ingen brugere at holde styr på. Det meste af tiden går med at forstå dataene og håndtere de gange hvor et API svarer forkert eller er nede. Kalendertiden er typisk 1-3 uger, og prisen lander i den lave ende af tabellen.

2. Regnearket der skal være et internt værktøj (ca. 60-150 timer)

Ordrer, opgaver eller udstyr bliver styret i et delt regneark, og det begynder at gå galt: to personer retter samtidig, formler bliver slettet, og ingen ved hvilken version der er den rigtige. Kender du symptomerne, så har jeg skrevet om tegnene på at en virksomhed er vokset ud af Excel.

Et internt værktøj til den opgave består typisk af login, to-tre brugerroller, nogle skærmbilleder til at oprette og rette data, søgning og filtre, eksport til Excel og en log over hvem der har ændret hvad. Fordi det kun er jeres egne folk der bruger det, kan brugerfladen være enkel og bygges med færdige byggeklodser til administrationssider, fx Filament til Laravel. Det sparer mange timer i forhold til at designe alt fra bunden.

Regn med 3-8 ugers kalendertid. Skal data flyttes fra et rodet regneark, så læg typisk 10-20 timer oveni til oprydning og import.

3. Ordresystem med kundelogin og integration (ca. 200-500 timer)

Nu skal kunderne selv kunne logge ind, se deres ordrer og bestille, og ordrerne skal automatisk over i økonomisystemet som fakturaer. Det løfter projektet en klasse op af tre grunde. Brugerfladen skal være så god at kunder kan bruge den uden oplæring. Brugerrettighederne skal være skudsikre så kunder kun ser deres egne data. Og integrationen til økonomisystemet skal kunne håndtere fejl, rettelser og kreditnotaer.

Systemer i den størrelse kaldes ofte en kundeportal eller en webapp, og jeg går mere i detaljer med prisniveauerne i guiden til hvad en webapp koster. Kalendertiden er typisk 2-5 måneder. Her anbefaler jeg altid et forprojekt (en kort, betalt afklaringsfase) før der gives en fast pris.

4. Platform med flere brugertyper og betaling (600+ timer)

Forestil dig en platform hvor kunder, leverandører og jeres egne medarbejdere har hver deres adgang, hvor der betales online, sendes notifikationer, og hvor flere eksterne systemer skal hænge sammen. Her er det ikke længere kodningen alene der koster. Afklaring, test, sikkerhed og drift fylder lige så meget.

Projekter i den størrelse kan sagtens løbe op over en million kroner, og de bør bygges i faser: første fase sættes i drift og tages i brug før resten bygges. Den størrelse har sine egne prisdrivere, så den har fået sin egen guide om hvad en platform eller markedsplads koster.

Hvad driver prisen op og ned

Det er sjældent selve teknologien der afgør prisen. Det er hvor mange ting systemet skal holde styr på og hvor mange undtagelser der er.

Integrationer bliver ofte undervurderet. At hente data fra et system er sjældent svært. Det tager tid at holde to systemer synkroniseret når en faktura bliver rettet, en kunde bliver slettet eller et API ændrer sig. Hver integration er reelt et lille projekt for sig.

Undtagelserne er den anden store post. Hovedforløbet i en arbejdsgang er ofte hurtigt at bygge, men de sidste 20 % med specialtilfælde ("men hvis kunden er en offentlig institution, så ...") kan tage lige så lang tid som resten.

Hvad softwaren koster efter lanceringen

Udviklingsprisen er ikke den sidste regning. Software skal køre et sted, og den skal holdes ved lige.

Hosting af et lille internt værktøj kan typisk klares for et par hundrede kroner om måneden. Større systemer med flere servere, backup og overvågning koster mere. Dertil kommer vedligehold: opdateringer af framework og pakker, sikkerhedsrettelser og tilpasninger når et eksternt system ændrer sit API.

Som groft skøn bør du budgettere med 10-20 % af udviklingsprisen om året til drift, opdateringer og små rettelser. Et værktøj til 100.000 kr. koster altså typisk 10.000-20.000 kr. om året at holde kørende. Jeg har gennemgået posterne mere detaljeret i guiden til drift og vedligehold af en webapp.

Planlæg også med videreudvikling. Når folk først bruger et system de er glade for, kommer ønskerne til nye funktioner hurtigt. Det er et godt tegn, men det skal stå i budgettet.

Hvornår du ikke skal få bygget skræddersyet software

Jeg tjener penge på at bygge software, men der er flere situationer hvor jeg vil fraråde det:

• Et standardprogram dækker det meste. Hvis et abonnement til nogle hundrede kroner pr. bruger om måneden løser 80 % af behovet, er det næsten altid billigere at tilpasse jeres arbejdsgang til programmet end at bygge selv.
• Arbejdsgangen ligger ikke fast endnu. Ændrer I processen hver måned, så hold den i et regneark eller et no-code-værktøj til den har sat sig. Ellers betaler du for at bygge den om flere gange.
• Opgaven er meget lille. En Excel-makro eller en automatisering i Zapier eller Make kan være nok, og det kræver ikke en udvikler til 1.000 kr. i timen.
• Du har brug for et helt team med det samme. Skal fem udviklere i gang i næste uge, eller skal der være vagt døgnet rundt, er en freelancer som mig ikke det rigtige valg. Så er det et bureau eller et softwarehus.

Omvendt er skræddersyet software ofte den billigste løsning på sigt når en arbejdsgang er stabil, koster mange timer hver uge og ikke passer ind i noget standardprogram.

Sådan får du en pris du kan regne med

Et præcist tilbud kræver en præcis beskrivelse. Sådan kommer du dertil:

1. Beskriv problemet, ikke løsningen. Hvad tager tid i dag, hvem gør det, og hvor ofte?
2. Vælg den ene arbejdsgang der skal virke i første version.
3. Saml materialet: regnearket, skærmbilleder af de systemer der skal tales med, og en liste over hvem der skal bruge løsningen.
4. Bed om et groft skøn først. Er opgaven større end et lille værktøj, så start med et forprojekt til fast pris før du får et fast tilbud på udviklingen.
5. Sammenlign tilbud på timer og afgrænsning, ikke kun på slutprisen. Et billigt tilbud med et uklart omfang bliver sjældent billigt.

Jeg starter selv større opgaver med et forprojekt til fast pris, og du ejer koden fra første dag. Er det en kundeportal, et internt værktøj eller et system der skal afløse regneark, så kan du se hvordan jeg arbejder på siden om udvikling af webapps og platforme.

Ofte stillede spørgsmål

Ejer jeg koden når systemet er betalt?+

Det bør du, men det skal stå i aftalen. Nogle leverandører beholder rettighederne og giver dig kun en licens, og så kan du ikke uden videre tage koden med til en anden udvikler. Hos mig ejer du koden fra første dag. Uanset hvem du vælger, så spørg direkte om ejerskab og adgang til koden før du skriver under.

Bliver skræddersyet software billigere med AI-værktøjer?+

Lidt, men ikke så meget som overskrifterne lover. AI-værktøjer gør det hurtigere at skrive standardkode, og derfor kan et lille værktøj blive billigere end for et par år siden. De tunge poster er dog de samme: at forstå arbejdsgangen, få integrationer til at virke, teste undtagelserne og holde systemet i drift. Vær skeptisk over for tilbud der er markant billigere med henvisning til AI, og spørg hvem der tester og vedligeholder koden.

Hvad sker der hvis min freelanceudvikler stopper?+

Det er den reelle risiko ved at vælge én person, men den kan gøres lille. Sørg for at du har adgang til koden, at den er bygget i et udbredt framework som Laravel, og at der findes en kort beskrivelse af opsætning og drift. Så kan en anden udvikler overtage uden at starte forfra. Aftal det fra starten, ikke først når problemet opstår.

Kan et lille værktøj vokse til et større system senere?+

Ja, hvis det er bygget til det. Et internt værktøj lavet i et almindeligt framework med en ordentlig database kan udvides med flere roller, integrationer og senere kundeadgang. Er første version derimod bygget i et no-code-værktøj eller som et regneark med makroer, ender det ofte med en genopbygning når kravene vokser. Det er ikke nødvendigvis forkert at starte der, men regn genopbygningen med i budgettet.