Billig vs dyr udvikler: hvad du reelt får for pengene

En billig udvikler er kun billig hvis koden kan bære de ændringer du får brug for de næste par år. I mit regneeksempel ender en timepris på 450 kr. med at koste ca. 40.000 kr. mere over to år end en timepris på 1.000 kr., og skal koden omskrives, vokser forskellen til omkring 230.000 kr. Omvendt er en dyr udvikler spild af penge på små, veldefinerede opgaver og på prototyper der alligevel skal smides ud.

Jeg er selv freelance udvikler og har dermed en interesse i konklusionen. Derfor står alle antagelser åbent, så du kan sætte dine egne tal ind.

Den korte version: hvad forskellen i timepris køber

Med "billig" mener jeg her en timepris omkring 400-600 kr. ekskl. moms, og med "dyr" 800-1.200 kr. Det svarer nogenlunde til spændet mellem juniorer og seniorer i Lønradars oversigt over freelance IT-timepriser for 2026. Bureauer ligger typisk endnu højere.

Tabellen beskriver tendenser, ikke regler. Der findes dygtige udviklere med lav timepris og dyre udviklere der leverer rod. Beslutningsreglen er enkel: jo længere koden skal leve, og jo oftere den skal ændres, desto mere betaler erfaring sig.

Vil du se hvad hele projekter typisk koster, har jeg samlet det i min prisguide til softwareudvikling. Hvad der ellers skiller en lav timepris fra en høj, står i indlægget om timepriser for freelance udviklere.

Regneeksempel: samme projekt, to udviklere, to år

Projektet er et tænkt eksempel: et internt værktøj til ordrer og kunder med login, brugerroller, et par skærmbilleder til medarbejderne og en integration til økonomisystemet. Efter lanceringen kommer en ønskeliste med nye funktioner i år 2. Timetallene er mine grove skøn til illustration, ikke målte tal, og din egen tid er sat til 500 kr. i timen.

Når du sammenligner tilbuddene, ser den billige udvikler ud til at spare dig 65.000 kr. (135.000 mod 200.000 kr. med afklaringen). Efter to år har du betalt 40.000 kr. mere. Ser du bort fra din egen tid, ender de to næsten lige: 390.000 mod 385.000 kr.

Tallene kan sagtens falde anderledes ud. En dygtig udvikler med lav timepris vender regnestykket, og en dyr udvikler der bygger mere end nødvendigt, kan bruge flere timer end eksemplet viser. Pointen er mekanismen: forskellen flytter fra timeprisen til timerne.

Hvor forskellen opstår

Tilbuddet er ikke regningen

Et lavt tilbud er ofte lavt fordi det er optimistisk, ikke fordi arbejdet er billigere. Uden en afklaring først bygger estimatet på det udvikleren forestiller sig, og hullerne viser sig undervejs som ekstra timer eller tillægsarbejde. I eksemplet er overskridelsen 40 % hos den billige udvikler og under 10 % hos den dyre.

Omarbejde det første år

Fejl der ikke bliver fanget under udviklingen, dukker op når rigtige brugere tager systemet i brug. Uden automatiske tests (kode der kontrollerer at anden kode virker) bliver fejlene fundet af dine medarbejdere eller kunder, og hver rettelse risikerer at ødelægge noget andet.

År 2: alt bygges oven på år 1

Det er her den største forskel opstår. Nye funktioner skal passe ind i det der allerede findes. I rodet kode tager selv små ændringer lang tid fordi udvikleren først skal forstå koden og bagefter sikre sig at intet andet går i stykker.

I Stripes undersøgelse The Developer Coefficient fra 2018 anslog de adspurgte udviklere at en udvikler i deres virksomhed i gennemsnit brugte 17,3 af 41,1 ugentlige arbejdstimer på vedligehold, fx fejlsøgning, oprydning i koden og arbejde med dårlig kode. Tallene er selvrapporterede og efterhånden gamle, men de viser hvor meget tid der kan forsvinde før der bliver bygget noget nyt.

Din egen tid

Den billige løsning flytter arbejde over på dig: præcise opgavebeskrivelser, test af hver levering og opfølgning på misforståelser. De timer står ikke på nogen faktura, men de er ikke gratis. Det samme gælder de poster der sjældent står i et tilbud, som jeg har samlet i listen over skjulte omkostninger i softwareprojekter.

Når billig bliver dyrest: koden skal omskrives

Regneeksemplet ovenfor er det pæne scenarie, hvor den billige kode kan bære år 2. Det værste scenarie er at den ikke kan. Hver ny funktion skaber nye fejl, ingen tør røre ved integrationen til økonomisystemet, og den oprindelige udvikler er gået videre. Så står du med valget mellem at rydde op og at begynde forfra, og en ny udvikler skal først bruge tid på at forstå hvad der er bygget.

Med de samme antagelser ser scenariet sådan ud:

• Første version og rettelser i år 1: 225.000 kr., som i tabellen.
• Gennemgang af koden og omskrivning af kernen, inkl. flytning af data: ca. 230 timer à 1.000 kr., i alt 230.000 kr.
• Ønskelisten fra år 2, bygget på den nye kerne: ca. 80 timer, i alt 80.000 kr.
• Hosting og opdateringer: 30.000 kr.
• Din egen tid: ca. 150 timer, i alt 75.000 kr.

Det giver ca. 640.000 kr. mod 410.000 kr. hos den dyre udvikler, altså omkring 230.000 kr. mere. Dertil kommer kalendertiden: mens kernen bliver omskrevet, står produktet stille i flere måneder, og de nye funktioner må vente.

Mekanismen bag kaldes teknisk gæld: genveje der sparer tid i dag, men gør hver ændring dyrere senere. Jeg har forklaret hvordan teknisk gæld opstår, og hvordan du opdager den i et særskilt indlæg. Langt fra al billig kode ender sådan, men risikoen er det tal du ikke kan se i tilbuddet.

Dyr er ikke det samme som god

En høj timepris er ingen garanti. Nogle steder betaler du for kontor, salg og flere lag projektledelse uden at det gør koden bedre. Det kan være det rigtige når et stort projekt kræver design, tekst og udvikling på samme tid, men ikke når opgaven reelt kan løses af én udvikler.

En erfaren udvikler kan også bygge mere end du har brug for: et system til hundrede tusind brugere når du har halvtreds, eller en arkitektur der er spændende at arbejde med, men dyr at vedligeholde. Spørg altid hvad den mindste løsning på dit problem er.

Det du bør få for den højere pris, er konkret og kan tjekkes:

• Spørgsmål der udfordrer opgaven før der bliver skrevet kode.
• Et estimat hvor antagelser, risici og det der ikke er med, står på skrift.
• Koden i dit eget repository (kodearkiv) fra første dag, så du ejer den.
• Automatiske tests på de dele hvor fejl koster penge, fx betaling og integrationer.
• Dokumentation der gør det muligt for en anden udvikler at overtage.
• En fast svartid, så du ved hvornår du hører noget.

Tre af punkterne er faste hos mig: større projekter starter med et betalt forprojekt til fast pris, du ejer koden fra første dag, og jeg svarer inden for én arbejdsdag. Når du sammenligner udviklere, så stil tilbuddene op punkt for punkt. Min skabelon til at sammenligne tilbud fra udviklere gør det lettere.

Hvornår hver løsning ikke passer

En billig udvikler passer ikke når

• Koden skal leve i flere år og udvikles løbende.
• Systemet håndterer persondata, betalinger eller integrationer hvor en fejl koster penge eller giver problemer med GDPR.
• Du hverken har tid eller teknisk indsigt til at skrive præcise opgaver og teste leverancerne.
• Opgaven er uklar og skal formes undervejs i tæt dialog.

En dyr udvikler passer ikke når

• Opgaven er lille og veldefineret, fx at rette tekster, opdatere et plugin eller justere en formular. Der er ingen arkitektur der kan gå galt, så timeprisen afgør regningen.
• Du vil teste en idé med en prototype der skal smides ud. Så er tempo og lav pris vigtigere end holdbarhed, og et no-code-værktøj kan være endnu billigere.
• Du har en stærk teknisk person i huset der kan lede og gennemgå arbejdet. Under kyndig ledelse kan en billigere udvikler give mere for pengene.
• En standardløsning dækker det meste af behovet. Så er et abonnement på et færdigt system næsten altid billigere end at få noget bygget, uanset timepris.

Næste skridt: regn på dit eget projekt

1. Regn på to år, ikke på tilbudssummen. Skriv ned hvad du forventer at bygge efter første version, også selvom listen er usikker.
2. Bed hver udvikler om antagelserne bag estimatet: hvad er med, og hvad er ikke? Afklaring, test og dokumentation er de poster der oftest mangler.
3. Spørg hvordan fejl og ændringer bliver håndteret efter lanceringen, og hvad det koster. Mit overblik over hvad drift og vedligehold af en webapp koster om året giver dig et udgangspunkt.
4. Sæt en pris på din egen tid, og læg den oven i den billige løsning.
5. Kan du ikke selv vurdere kvaliteten, så få en erfaren udvikler til at kigge med tidligt og ikke først når problemerne viser sig.

På min prisside kan du se hvordan jeg prissætter, og hvordan forprojektet til fast pris fungerer, så du har noget konkret at sammenligne med.

Ofte stillede spørgsmål

Kan jeg bruge en billig udvikler og få en dyr til at gennemgå koden?+

Ja, og det er ofte en god kombination hvis gennemgangen sker løbende. Lad den erfarne udvikler lægge strukturen og gennemgå koden hver eller hver anden uge. Kommer gennemgangen først ved afleveringen, er de dyre valg allerede truffet, og så kan den kun fortælle dig hvad der skal laves om. Regn med nogle timer om ugen til gennemgang, alt efter tempoet.

Beskytter en fast pris mig mod overskridelser fra en billig udvikler?+

Den beskytter dit budget, men ikke kvaliteten. Ved en lav fast pris bærer udvikleren risikoen for overskridelser, og den risiko bliver ofte håndteret ved at skære test og dokumentation væk eller ved at kalde alt uden for den oprindelige beskrivelse for tillægsarbejde. En fast pris virker bedst når omfanget er afklaret grundigt først, så begge parter ved præcis hvad prisen dækker.

Hvad gør jeg hvis jeg allerede har valgt den billige løsning?+

Få koden vurderet af en uafhængig udvikler før du bygger mere oven på den. En gennemgang tager typisk fra en til et par dage og viser om koden kan ryddes op i trin, eller om kernen bør omskrives. Sørg samtidig for at du selv har adgang til kode, hosting, domæner og databaser, så du ikke er afhængig af én person hvis samarbejdet slutter.

Er en udvikler i udlandet altid den billige løsning?+

Nej, timeprisen er lav, men totalprisen afhænger af hvor meget du selv kan styre. Der findes dygtige udviklere i lande med lavere lønniveau, og med en klar beskrivelse og en teknisk person på din side kan det være en god forretning. Uden det går en stor del af besparelsen til specifikation, koordinering på tværs af tidszoner og rettelser af misforståelser.