Sådan sætter du et realistisk budget til dit softwareprojekt (skabelon)

Et realistisk budget til et softwareprojekt har fire lag: et forprojekt, selve udviklingen, en buffer til det uforudsete og drift efter lanceringen. Udviklerens estimat dækker som regel kun det andet lag, og derfor ender mange budgetter med at være for små selv når tilbuddet holder. Skabelonen herunder hjælper dig med at regne alle fire lag ud, så du har en budgetramme klar før det første møde med en udvikler.

Jeg er freelanceudvikler og skriver selv estimater, så læs med det forbehold. Procentsatserne er mine tommelfingerregler, og tallene er grove skøn, ikke et tilbud.

Den korte version: et budget i fire lag

Skriv budgettet op i fire lag, og regn hvert lag for sig. Så kan du se hvor pengene går hen, og du kan skære i det rigtige lag hvis summen bliver for høj.

Ved siden af de fire lag kommer dine egne omkostninger: den tid du og dine medarbejdere bruger, og de tekster, billeder og aftaler som udvikleren ikke leverer.

Ved du endnu ikke hvilken størrelsesorden dit projekt ligger i, så start med prisguiden til softwareudvikling. Den giver et groft prisniveau for de typiske projekttyper, og skabelonen herunder gør tallet til et budget.

Skabelonen: kopiér den over i et regneark

Opret et regneark med linjerne herunder, og tilføj en kolonne til dine egne tal. Eksemplet er tænkt: en virksomhed vil erstatte regneark og mails med en webapp hvor kunderne opretter og følger reklamationssager, og hvor afsluttede sager bliver sendt videre til økonomisystemet. Timeprisen er sat til 1.000 kr. ekskl. moms for at gøre regnestykket enkelt. Det er ikke min pris.

Læg mærke til forholdet. Udviklerens estimat på 260.000 kr. udgør lidt over halvdelen af den samlede ramme på 465.000 kr.

Det betyder ikke at alle pengene bliver brugt. Bufferen er en reserve, og puljen til version to kan vente til du ved hvad brugerne efterspørger. Men det er det beløb du skal have godkendt hvis projektet skal kunne gennemføres uden at gå i stå halvvejs. Lægger du et budget for flere år, så gentag linje 7 og en del af linje 8 for år to og tre.

Sådan finder du dine egne tal i syv trin

Trinene følger skabelonen. Du kan godt udfylde den på en eftermiddag, og den behøver ikke være præcis. Den skal være realistisk.

1. Start med hvad problemet koster i dag

Før du regner på udviklingen, så regn på gevinsten. Hvor mange timer går til manuelt arbejde, hvor mange fejl sker der, og hvor meget omsætning går tabt? Bruger to medarbejdere hver ti timer om ugen på reklamationerne i eksemplet, er det omkring 900 timer om året. Med en intern timesats på 450 kr. svarer det til godt 400.000 kr. om året, så rammen på 465.000 kr. er tjent hjem på godt et år hvis systemet fjerner det meste af arbejdet.

Gevinsten sætter loftet for budgettet. Kan løsningen ikke tjene sig hjem inden for to-tre år, er det et signal om at gøre den mindre eller lade være.

2. Skriv første version ned, og del den i to

Lav en liste over hvad løsningen skal kunne, og del den i "skal med nu" og "kan vente". Skriv hvem der bruger løsningen, og hvad de skal kunne gøre. "Kunden opretter en sag og vedhæfter billeder" er langt mere brugbart end "sagsbehandling".

Listen behøver ikke være en kravspecifikation. Men jo mere konkret den er, jo smallere bliver spændet i estimatet. Har du brug for et format, så brug min skabelon til en projektbeskrivelse til udvikleren.

3. Find størrelsesordenen

Regn med timer gange timepris, også selv om du ender med en fast pris. Ifølge LønRadars oversigt over freelance-timepriser i it for 2026 tager en senior it-konsulent typisk 800-1.200 kr. i timen ekskl. moms. Bureauer ligger ofte højere fordi timeprisen også skal dække projektledelse og salg.

Timetallet kan du anslå ud fra prisguiden til din projekttype eller ved at give hver funktion på listen et groft antal timer. Regn hellere med et spænd, fx 220-320 timer, end med ét tal. Et spænd er mere ærligt, og det viser dig med det samme hvor meget usikkerhed bufferen skal dække.

4. Fordel timerne på faser

Del byggeprisen op i design, funktioner, integrationer og test som i skabelonen. Så kan du se om en enkelt linje fylder urimeligt meget, og hvad der kan udskydes til version to.

Test og lancering bliver ofte glemt, men tager en mærkbar del af timerne. Integrationer er den linje der oftest skrider fordi den afhænger af et andet system som hverken du eller udvikleren styrer. Skal du betale i rater, så lad faserne være grundlaget for betalingsplanen.

5. Læg en buffer på efter usikkerhed

Bufferen dækker to ting: estimater der skrider, og ønsker du først får når du ser systemet. Hvor stor den skal være, afhænger af hvor afklaret projektet er. Usikkerhedskeglen, som Barry Boehm satte tal på, viser at et estimat helt i starten kan ramme ved siden af med en faktor fire i begge retninger. Spændet bliver mindre efterhånden som kravene bliver afklaret. Mine tommelfingerregler ser sådan ud:

Ved alt over et par hundrede timer anbefaler jeg et forprojekt. Det koster typisk 5-10 % af udviklingsbudgettet og gør resten af tallene langt mere præcise. Se hvad en discovery-fase koster, og hvad den indeholder.

6. Regn drift og videreudvikling med for to-tre år

Software i drift koster penge hvert år: hosting, e-mailudsendelse, backup, fejlovervågning, opdatering af framework og pakker og små rettelser. Min tommelfingerregel er 15-20 % af byggeprisen om året, og mere hvis produktet skal udvikle sig hurtigt. Hvordan beløbet fordeler sig for små og store løsninger, står i guiden til prisen på drift og vedligehold.

Læg desuden en pulje til version to. Når de første rigtige brugere tager løsningen i brug, opdager du hvad der mangler, og de første ønsker er ofte de vigtigste. Jeg anbefaler typisk at holde en del af budgettet tilbage til månederne efter lanceringen i stedet for at bruge det hele på første version.

7. Læg dine egne omkostninger til

Et softwareprojekt tager også tid hos dig. Nogen skal svare på spørgsmål, godkende skitser, teste, skrive tekster og lære kollegerne op. Regn timerne ud for de personer der er involveret, og gang dem med en intern timesats.

Tag også det med som udvikleren typisk ikke leverer: tekster og billeder, licenser til tredjepartstjenester, juridisk hjælp til vilkår og databehandleraftaler og markedsføring ved lanceringen. Flere af de poster der sjældent står i et tilbud, har jeg samlet i listen over skjulte omkostninger i softwareprojekter.

Når budgettet ikke passer til idéen

Det sker ofte at summen i skabelonen er større end det beløb du kan eller vil bruge. Det er ikke et nederlag. Det er netop derfor du laver budgettet før du taler med en udvikler. Du har fire muligheder:

• Gør første version mindre. Flyt funktioner fra "skal med nu" til "kan vente" indtil summen passer. Det er næsten altid det bedste første skridt.
• Byg i faser. Lav den del der giver størst gevinst først, og lad gevinsten finansiere resten.
• Brug en standardløsning. Dækker et færdigt system omkring 80 % af dine behov, er det typisk billigere at tilpasse din proces end at bygge selv.
• Test idéen billigere først. Er du ikke sikker på at nogen vil bruge løsningen, så test med en landingsside, en manuel proces eller et no-code-værktøj.

Det du ikke skal gøre, er at fjerne bufferen og driften for at få regnestykket til at gå op. Så holder budgettet kun på papiret.

Ligger din ramme under omkring 40.000 kr., og skal løsningen have login, data og integrationer, er en freelanceudvikler som mig sjældent det rigtige sted at starte. Så får du typisk mere for pengene med et standardsystem eller et no-code-værktøj. Du kan altid få noget bygget senere når du ved præcis hvad du har brug for.

Fem fejl der gør budgettet for småt

1. Kun at budgettere udviklerens pris. Forprojekt, buffer, drift og din egen tid er lige så reelle udgifter. De kommer bare på andre tidspunkter.
2. At regne med ét tal i stedet for et spænd. Ét tal giver en falsk følelse af sikkerhed og efterlader ingen plads til det du ikke ved endnu.
3. At bruge bufferen som ønskeseddel. Bufferen er til det uforudsete. Går den til nye ønsker i første måned, er den væk når integrationen skrider.
4. At glemme momsen. Priser mellem virksomheder er normalt ekskl. moms. Er din virksomhed ikke momsregistreret, skal du lægge 25 % oven i.
5. At vælge den laveste timepris. En lav timepris giver kun et billigt projekt hvis timetallet ikke vokser tilsvarende.

Næste skridt: brug budgettet i dialogen med udvikleren

Når skabelonen er udfyldt, har du tre ting: en liste over første version, et spænd for byggeprisen og en samlet ramme med buffer og drift. Del rammen med de udviklere du taler med. Det er ikke en invitation til at bruge hele beløbet. Det gør det muligt for udvikleren at foreslå en løsning der passer til rammen i stedet for at gætte.

Når tilbuddene kommer, så sæt dem ind i skabelonen og sammenlign tilbuddene fra udviklerne på samme grundlag. Brug tjeklisten herunder før budgettet går til godkendelse.

Vil du se hvordan jeg selv prissætter, med et forprojekt til fast pris og kode du ejer fra første dag, så står det på siden med mine priser. Du taler direkte med mig, og du får svar inden for én hverdag.

Ofte stillede spørgsmål

Hvad gør jeg hvis budgettet skrider undervejs?+

Stop op før pengene er brugt, og få et nyt estimat på det der mangler. Gennemgå derefter listen over funktioner, og flyt det der kan vente til version to. Brug bufferen til det der skal med for at løsningen virker, ikke til nye ønsker. Jo tidligere du opdager at budgettet skrider, jo flere muligheder har du. Derfor er en kort status hver uge eller hver anden uge en god idé.

Hvordan styrer jeg budgettet hvis jeg betaler i timer?+

Aftal et loft pr. måned eller pr. fase, og bed om en status med forbrugte timer og et skøn over resten. Så kan du stoppe eller prioritere om før loftet er nået. At betale efter timer er fleksibelt, men risikoen for at timerne skrider ligger hos dig, så bufferen skal typisk være større end ved en fast pris. Bed også om at få store ændringer estimeret skriftligt før arbejdet går i gang.

Kan jeg få tilskud til mit softwareprojekt?+

Nogle projekter kan, især når der er tale om reel innovation og ikke almindelig drift eller en ny hjemmeside. Ordningerne, beløbene og betingelserne ændrer sig, så undersøg dem før du lægger budgettet endeligt. Regn ikke med pengene i budgettet før de er bevilget, og læg mærke til om ordningen kræver at du selv betaler en del, eller at arbejdet først må starte efter en bevilling.

Skal softwareudvikling bogføres som en udgift eller som et aktiv?+

Det afhænger af projektet og af virksomhedens regnskabspraksis. Udvikling kan i nogle tilfælde aktiveres og afskrives over flere år, mens andre udgifter skal udgiftsføres med det samme. Valget påvirker både regnskabet og skatten, så tal med din revisor før budgettet bliver godkendt. Det er også revisoren der kan sige om drift og videreudvikling skal behandles anderledes end selve byggeriet.