Sådan læser og sammenligner du tilbud fra udviklere

Når du skal sammenligne tilbud på udvikling, er totalprisen det sidste du skal kigge på. Stil først tilbuddene op i samme skabelon, find ud af hvad hvert af dem faktisk dækker, og regn dem om til samme omfang og samme periode. Først da kan du se om forskellen på 85.000 og 290.000 kr. handler om pris, eller om du har fået tilbud på tre forskellige projekter.

Jeg skriver selv tilbud som freelanceudvikler, så læs med det forbehold. Til gengæld kender jeg de steder hvor et tilbud kan se billigere ud end det er, og det er dem guiden handler om.

Den korte version: sammenlign i fire lag

Læg tilbuddene ved siden af hinanden i denne rækkefølge, og gå først videre til næste lag når det forrige er på plads:

1. Omfang: dækker tilbuddene det samme, og hvad står der udtrykkeligt at der ikke er med?
2. Samlet pris over to-tre år: udvikling plus det der mangler, drift og de ændringer der altid kommer.
3. Risiko: hvem betaler hvis det tager længere tid, og hvor mange forbehold er der?
4. Mennesker: hvem laver arbejdet, og hvordan svarer de når du spørger ind?

Her er et tænkt eksempel på hvordan det ser ud i praksis. Tre leverandører har givet tilbud på den samme kundeportal, hvor virksomhedens kunder skal kunne logge ind, se deres ordrer og hente fakturaer, og hvor data kommer fra virksomhedens økonomisystem.

På papiret er A billigst og C dyrest. Men A nævner hverken integrationen, test eller drift, og de ting forsvinder ikke fordi de mangler i tilbuddet. C indeholder til gengæld et designforløb og et helt hold, som B ikke har. Det er altså ikke tre priser på det samme projekt, men tre forskellige projekter. Tilbud B følger i øvrigt min egen model med betalt forprojekt og derefter fast pris, så vurder eksemplet med det i baghovedet.

Er du i tvivl om niveauet overhovedet er rimeligt for din type projekt, så start med min prisguide til softwareudvikling, og kom tilbage når du har tilbuddene i hånden.

Hvorfor tilbud på det samme projekt svinger så meget

Det er helt normalt at det dyreste tilbud er tre eller fire gange så dyrt som det billigste. Det skyldes sjældent at nogen snyder. Oftest er det en blanding af disse seks ting.

De har læst din beskrivelse forskelligt

Alt det din beskrivelse ikke siger, udfylder udvikleren med antagelser. "Brugerne skal kunne logge ind" kan betyde e-mail og adgangskode, login med Microsoft-konto eller MitID, og det kan være forskellen mellem få timer og flere dages arbejde. Jo mere beskrivelsen lader stå åbent, jo længere fra hinanden lander tilbuddene. Efter min vurdering er det den største enkeltårsag til store prisforskelle.

Timeprisen er forskellig

Ifølge LønRadars oversigt over freelance-timepriser i IT for 2026 ligger en junior typisk på 400-600 kr. i timen, en senior på 800-1.200 kr. og specialister og arkitekter på 1.000-1.600 kr., alt ekskl. moms. Bureauer ligger ofte højere fordi timeprisen også skal dække projektledelse og salg. En lav timepris giver dog kun et billigt projekt hvis antallet af timer ikke vokser tilsvarende. Hvad der er normalt for en freelancer, står i guiden til timepriser for freelance udviklere, og forskellen på freelancer, bureau og offshore gennemgår jeg i sammenligningen af hvad en udvikler koster.

Prismodellen flytter risikoen

Et tilbud med fast pris på et uklart projekt indeholder et risikotillæg fordi udvikleren betaler hvis det tager længere tid. Et tilbud på timebasis viser kun et estimat, og her er det dig der betaler. Du kan derfor ikke sammenligne en fast pris på 200.000 kr. med et estimat på 160.000 kr. uden at spørge hvad der sker hvis estimatet skrider. Fordele og ulemper ved de to modeller står i guiden til timepris eller fastpris.

Der er forskellige ting med

Design, projektledelse, test, dokumentation, opsætning af servere, hosting, support efter lanceringen og overdragelse er alle noget som nogle tilbud har med, og andre springer over. Hver af dem kan udgøre en mærkbar del af prisen.

Nogle bygger fra bunden, andre genbruger

En udvikler kan bygge på en eksisterende platform, et plugin eller sit eget fundament af standardkode, mens en anden skriver det hele fra bunden. Genbrug kan være en klar fordel for dig. Spørg bare hvem der ejer det genbrugte, om der følger licenser med, og om en anden udvikler kan overtage det senere.

Nogle vil have opgaven mere end andre

En udvikler med tom kalender byder ofte lavere end en med fuld kalender. Nogle byder bevidst lavt for at komme ind og tjener pengene på ændringer bagefter. Det kan du ikke se direkte i tilbuddet, men du kan se det på prisen for ekstraarbejde og på hvor præcist omfanget er beskrevet.

Hvad et godt tilbud skal indeholde

Før du sammenligner, så tjek at hvert tilbud overhovedet har de dele der gør det muligt. Et brugbart tilbud på udvikling indeholder typisk:

• Din opgave gengivet med leverandørens egne ord, så du kan se om de har forstået den.
• En liste over hvad der bliver bygget.
• En liste over hvad der ikke er med.
• Antagelser og forbehold, fx "forudsætter at økonomisystemet har et åbent API".
• Prismodel og pris, gerne fordelt på faser eller delleverancer.
• Tidsplan, og hvad den afhænger af fra din side.
• Betalingsplan.
• Hvordan ændringer bliver estimeret, godkendt og prissat.
• Hvem der ejer koden, og hvor den ligger.
• Hvad der sker efter lanceringen: fejlrettelser, drift og support.
• Hvem der laver arbejdet.

Listen over fravalg er den del jeg ville læse først. Et tilbud uden fravalg er ikke mere komplet end de andre. Det betyder bare at du først opdager fravalgene når fakturaen kommer.

Mangler et tilbud halvdelen af punkterne, er det ikke nødvendigvis et tegn på en dårlig leverandør. Mindre opgaver får ofte kortere tilbud. Men så er det din opgave at spørge før du sammenligner.

Sådan sammenligner du tilbud på udvikling i seks trin

Trinene virker for alt fra en lille integration til en hel platform. Ved mindre opgaver kan du nøjes med de første fire.

1. Giv alle det samme grundlag

Send den samme beskrivelse til alle, med den samme svarfrist og de samme spørgsmål. Bed om at få timerne fordelt på faser eller funktioner, så du kan se hvor pengene går hen. Præciserer du noget over for én leverandør, så send præciseringen til alle. Ellers sammenligner du tilbud på forskellige opgaver uden at vide det.

2. Stil tilbuddene op i samme skabelon

Tilbud kommer i alle former: en PDF på 20 sider, en mail på ti linjer, et regneark. Flyt de vigtigste oplysninger over i ét skema, så hullerne bliver synlige. Kopiér skabelonen herunder over i et regneark med én kolonne pr. tilbud.

Kan du ikke udfylde et felt ud fra tilbuddet, så skriv et spørgsmålstegn. Det er dine spørgsmål til næste trin.

3. Spørg ind til hullerne

Saml spørgsmålstegnene i én liste, og send de samme spørgsmål til alle leverandører. Læg mærke til hvordan de svarer. Et præcist svar inden for et par dage siger noget om hvordan samarbejdet bliver. Et svar som "det finder vi ud af undervejs" på et spørgsmål om integrationen siger også noget.

4. Regn tilbuddene om til samme omfang og samme periode

Giv hullerne en pris, og regn på de første to-tre år i stedet for kun udviklingen. Tag tilbud A fra eksemplet. Mangler integrationen, og vurderer du den til 40 timer til tilbuddets egen pris på ændringer, 950 kr. i timen, er du allerede oppe på 123.000 kr. Læg test, drift og de ændringer der altid kommer det første år oveni, og afstanden til B er pludselig lille.

Min tommelfingerregel er at lægge 15-20 % af udviklingsprisen til side om året til drift, opdateringer og små forbedringer. Brug den samme procentsats for alle tilbud, men tjek hvad timerne efter lanceringen koster hos hver leverandør. Det er dem du kommer til at købe i årevis. Hvordan den slags løbende arbejde typisk bliver aftalt, kan du læse i guiden til retainer og klippekort.

5. Vurder risikoen, ikke kun prisen

To tilbud med samme pris kan have meget forskellig risiko. Kig efter:

• Fast pris på et uklart projekt: enten er bufferen stor, eller også bliver ændringer dyre.
• Timepris uden loft: bed om et estimat pr. fase og et loft, så du kan stoppe op i tide.
• Mange forbehold: hver antagelse der ikke holder, flytter risikoen tilbage til dig.
• Én person: hvad sker der ved sygdom? Ligger koden i dit eget repository (kodearkiv), og er der dokumentation nok til at en anden kan tage over?
• Et hold: hvem laver arbejdet i praksis, og er det de samme personer du mødte til salgsmødet?

6. Gå de to bedste tilbud igennem på et møde

Bed de to mest lovende leverandører om at gennemgå deres tilbud med dig. Tre spørgsmål siger meget: "Hvad er den sværeste del af projektet?", "Hvor er dit estimat mest usikkert?" og "Hvad ville du skære væk, hvis budgettet var 30 % mindre?" En erfaren udvikler kan svare konkret på alle tre. Et vagt svar på det sidste betyder ofte at omfanget ikke er gennemtænkt.

Advarselstegn i et tilbud

Nogle ting er værd at stoppe op ved, uanset prisen:

• Kun en totalpris, uden fordeling på faser, funktioner eller timer.
• Ingen fravalg og ingen antagelser. Så ved du ikke hvad du har købt.
• Fast pris på et stort projekt der kun er beskrevet på en halv side, uden afklaring eller forprojekt først.
• Lav pris på projektet, men høj eller uklar pris på ændringer.
• Uklart ejerskab: koden ligger på leverandørens konto, eller du får en brugsret i stedet for rettighederne.
• En tidsplan der ikke afhænger af noget fra din side. Alle projekter afhænger af dine svar, dine tekster og din test.
• Fuld betaling på forhånd uden delleverancer.

Hvornår det billigste tilbud er det rigtige

Det billigste tilbud er ikke automatisk det dårligste. Det kan sagtens være det rigtige valg når:

• Opgaven er lille og klart afgrænset, fx en integration mellem to systemer med veldokumenterede API'er.
• En standardløsning dækker behovet. Får du et tilbud på 30.000 kr. for en løsning bygget på WordPress eller Shopify og et på 200.000 kr. for noget kodet fra bunden, er spørgsmålet ikke hvem der er billigst, men om du overhovedet har brug for at få noget bygget fra bunden. Det har du ofte ikke, og så har du heller ikke brug for en udvikler som mig.
• Du skal teste en idé. En prototype der skal vise om nogen vil betale, behøver ikke samme kvalitet som et system der skal køre i fem år.

Omvendt er det dyreste tilbud ofte det rigtige når systemet er kritisk for din forretning, eller når du har brug for et hold med faste svartider og vagtordning. Så er et bureau typisk et bedre valg end en enkelt freelancer, også selv om freelanceren er billigere.

Næste skridt

Sæt tilbuddene ind i skabelonen, send dine spørgsmål, book et møde med de to bedste, og brug tjeklisten herunder før du skriver under.

Er det bedste tilbud stadig over budget, så læs hvordan du forhandler med en udvikler uden at gå på kompromis med kvaliteten. Vil du se hvordan jeg selv prissætter, med 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

Hvor mange tilbud skal jeg indhente?+

To til tre er som regel nok. Med færre har du ikke noget at sammenligne med, og med flere bliver det svært at give hver leverandør den tid det kræver at gå tilbuddet ordentligt igennem. Mange udviklere bruger også mindre tid på et tilbud når de ved at ti andre byder. Vælg hellere tre leverandører med omhu end at sende beskrivelsen bredt ud.

Skal jeg betale for at få et tilbud?+

Et overslag efter en kort snak er normalt gratis. Et præcist tilbud på et større projekt kræver at krav, integrationer og risici er afklaret, og den tid tager mange udviklere betaling for i form af et forprojekt. Jeg starter selv større projekter med et betalt forprojekt til fast pris. Et godt forprojekt giver dig en beskrivelse du ejer, og som du også kan bruge til at indhente tilbud fra andre.

Hvad er forskellen på et estimat og et tilbud?+

Et estimat er et kvalificeret bud på hvor mange timer en opgave tager, og du betaler som regel for de timer der faktisk bliver brugt. Et tilbud med fast pris er en forpligtelse til at levere et bestemt omfang til en bestemt pris. Mange tilbud blander de to, så tjek hvilke dele der er faste, og hvilke der er skøn. Det bør stå klart i aftalen og ikke kun i en mail.

Må jeg vise et tilbud til en anden udvikler?+

Din egen projektbeskrivelse kan du frit dele. Et tilbud er derimod leverandørens arbejde, og nogle markerer det som fortroligt, så tjek om der står noget om det. Vil du have en anden udviklers vurdering, er det mere fair at dele dine spørgsmål og de tekniske antagelser end hele dokumentet med priser. Er du i tvivl, så spørg leverandøren først.