Timepris vs fastpris: hvad er bedst for dit softwareprojekt?

Timepris vs fastpris handler om ét spørgsmål: hvem betaler når opgaven tager længere tid end forventet? Med fastpris bærer udvikleren risikoen og tager betaling for den gennem en buffer i prisen, og med timepris bærer du den selv, men betaler kun for de timer der faktisk bliver brugt. Fastpris passer når opgaven kan beskrives præcist, timepris når den ikke kan, og til de fleste større projekter er en kombination bedst: et forprojekt til fastpris og derefter faste faser, faste sprints eller timer med loft.

Jeg starter selv større opgaver med et betalt forprojekt til fastpris, så jeg er ikke neutral i spørgsmålet. Jeg har forsøgt at være lige så ærlig om hvornår den model er forkert for dig.

Den korte version: hvilken model passer hvornår

Min tommelfingerregel er enkel. Kan du skrive ned hvad der skal være færdigt og hvordan du tester at det virker, så kan opgaven prissættes fast. Kan du ikke det endnu, så betal for afklaringen først, eller køb timer med et loft.

Prismodellen er kun én del af budgettet. Hvad de forskellige typer projekter typisk koster, har jeg samlet i prisguiden til softwareudvikling.

Hvem bærer risikoen i hver model

Al softwareudvikling bliver prissat ud fra et skøn over hvor mange timer opgaven tager. Også en fastpris er regnet sådan. Forskellen er hvem der hænger på regningen når skønnet rammer ved siden af. Der er tre slags risiko, og de fordeler sig forskelligt.

Risikoen for at estimatet er forkert

Et estimat er et bud på noget der ikke er bygget endnu, og usikkerheden er størst i starten. Med timepris betaler du for de ekstra timer. Med fastpris betaler udvikleren, og derfor lægger enhver fornuftig udvikler en buffer ind. Den buffer betaler du, også når projektet går præcis efter planen. Fastpris er altså en forsikring: præmien er den samme, uanset om skaden sker.

Risikoen for at du skifter mening

Her bliver mange overraskede. En fastpris dækker kun det der står beskrevet. Får du nye idéer undervejs, eller viser det sig at noget skal virke anderledes, bliver det et tillægstilbud. Med timepris er ændringer nemme, men hver ændring trækker på det samme budget.

I begge modeller er det altså dig der betaler for at skifte mening. Fastpris gør det bare synligt fordi hver ændring kommer med sin egen pris.

Risikoen for at kvaliteten bliver sparet væk

Begge modeller giver udvikleren et økonomisk incitament du skal kende. Ved fastpris tjener udvikleren mere jo hurtigere opgaven bliver færdig, så test, dokumentation og oprydning kan komme under pres når timerne slipper op. Ved timepris er der intet økonomisk pres for at blive hurtigt færdig.

De fleste udviklere arbejder ordentligt i begge modeller, men aftalen bør beskytte dig. Ved fastpris betyder det klare acceptkriterier (en beskrivelse af hvordan I tester at noget er færdigt) og en periode hvor fejl rettes uden beregning. Ved timepris betyder det status hver uge med brugte timer og hvad de er gået til.

Hvad koster bufferen i en fastpris?

Bufferen står sjældent i tilbuddet, men den er der. Hvor stor den er, varierer fra udvikler til udvikler og fra opgave til opgave. Et regneeksempel gør mekanikken tydelig. Tallene er kun til illustration.

En opgave er estimeret til 200 timer. Med 1.000 kr. i timen ekskl. moms, hvilket ligger inden for det normale prisniveau for en erfaren freelanceudvikler, giver det 200.000 kr. Lægger udvikleren 25 % buffer på for at give en fastpris, lander tilbuddet på 250.000 kr.

Fastpris er det billigste for dig når opgaven skrider mere end bufferen. To ting trækker dog i den anden retning.

Jo mere uklar opgaven er, jo større bliver bufferen fordi udvikleren skal dække sig ind. Og når et fastprisprojekt skrider voldsomt, opstår der næsten altid diskussion om hvad der egentlig var med i aftalen. Den nederste række i tabellen er derfor sjældent så rolig i virkeligheden som tallet antyder.

Fastpris er mest fordelagtig når opgaven er så godt beskrevet at bufferen kan være lille. Det er også den situation hvor timepris er mest forudsigelig. Valget betyder derfor mest på de uklare projekter, og her er svaret sjældent en ren model.

Sådan kombinerer jeg forprojekt, faste faser og timer

Den kombination jeg typisk anbefaler, deler projektet op efter hvor meget man ved. Hver del får den prismodel der passer til dens usikkerhed.

1. Forprojekt til fastpris

Et kort, afgrænset forløb hvor målet, de vigtigste funktioner, integrationer og risici bliver beskrevet og hvor du får et estimat på resten. Usikkerheden er størst her, men opgaven er lille og har en klar slutning, så den kan prissættes fast uden en stor buffer. Materialet bør være dit bagefter, så du også kan bruge det til at indhente tilbud andre steder. Priser og indhold står i indlægget om hvad et forprojekt (en discovery-fase) koster.

2. Udvikling i den model der passer til det I ved

Efter forprojektet er der som regel tre muligheder:

• Fastpris pr. fase passer når en del af opgaven er blevet konkret, fx login, brugerroller og en integration til et veldokumenteret API. Udvikleren bærer risikoen for estimatet, og du bærer risikoen for ændringer.
• Faste sprints passer når produktet skal formes undervejs. En sprint er en fast periode, fx to uger, til en kendt pris. Du bestemmer hvad der står øverst på listen, og du kan stoppe efter hver sprint. Prisen pr. periode ligger fast, men det er dig der bærer risikoen for hvor meget der bliver nået. Det er samme tankegang som den faste ramme med fleksibelt indhold i sammenligningen af agil udvikling og vandfald.
• Timer med loft passer når opgaverne er små og svære at forudsige, fx justeringer efter de første brugere. Et loft er ikke en fastpris. Det betyder at udvikleren stopper og spørger før loftet bliver overskredet, så du aldrig får en regning du ikke har godkendt.

3. Løbende aftale efter lanceringen

Når systemet er i drift, er opgaverne mindre og mere uforudsigelige. Her passer en fast månedlig ramme eller et klippekort bedre end fastpris på hver lille ændring. Hvordan de to fungerer, gennemgår jeg i guiden til retainer og klippekort.

Hvornår hver model ikke passer

Ingen af modellerne er altid rigtig. Her er de situationer hvor de typisk ender med at koste dig penge.

Hvornår timepris ikke passer

• Når budgettet er låst, fx fordi det er bevilget af en bestyrelse, en investor eller en tilskudsordning, og du skal kunne sige præcis hvad projektet koster.
• Når ingen hos dig har tid til at følge med. Timepris kræver at nogen ser timeforbruget hver uge og prioriterer.
• Når du ikke kender udvikleren endnu. Uden tillid bliver hver faktura en diskussion. Start med noget lille og afgrænset.

Hvornår fastpris ikke passer

• Når du bygger noget nyt som brugerne ikke har prøvet før. Du lærer undervejs, og hver ny indsigt bliver et tillægstilbud.
• Når omfanget ikke kan beskrives præcist endnu. Så betaler du for en stor buffer eller får et smallere system end du regnede med.
• Når arbejdet er løbende, fx fejlretning og små forbedringer. Et tilbud på hver lille opgave tager næsten lige så lang tid som selve opgaven.

Hvornår kombinationen er for tung

En mindre opgave på 10-30 timer behøver ikke et forprojekt. Her er en kort beskrivelse og et estimat nok, eller en lille fastpris direkte.

Og har du brug for en bindende fastpris på et stort projekt uden at bruge tid på afklaring først, er jeg ikke det rigtige valg. Så er et større bureau, der kan bære en stor risiko og prissætter den derefter, mere realistisk.

Spørgsmål der afslører risikoen i et tilbud

To tilbud i hver sin model kan ikke sammenlignes direkte. En fastpris på 250.000 kr. og et estimat på 200.000 kr. fortæller dig intet før du ved hvad der sker hvis estimatet skrider. Stil disse spørgsmål før du skriver under:

Har du allerede flere tilbud på bordet, så brug guiden til at sammenligne tilbud fra udviklere til at gøre dem sammenlignelige.

Næste skridt

Start med at svare ærligt på ét spørgsmål: kan du beskrive hvad der skal være færdigt og hvordan du tester det? Er svaret ja, så bed om en fastpris med acceptkriterier. Er svaret nej, så betal for afklaringen først, eller køb timer med et loft og status hver uge.

På min prisside kan du se hvordan jeg selv prissætter forprojekter og udvikling. Du ejer koden fra første dag, du taler direkte med den der skriver den, og du får svar inden for én hverdag.

Ofte stillede spørgsmål

Kan man skifte fra fastpris til timepris midt i et projekt?+

Ja, hvis begge parter er enige. Det sker oftest efter en afsluttet fase, hvor det leverede bliver godkendt og afregnet efter den faste pris, og resten fortsætter på timer med loft. Det er sværere midt i en fase fordi det kan være uklart hvor meget af den faste pris der er tjent. Aftal derfor gerne på forhånd at modellen kan tages op ved hver fase.

Er fejlrettelser med i en fastpris?+

Fejl i det der er aftalt, bør rettes uden ekstra betaling. Nye ønsker eller ændret opførsel er derimod ikke fejl, og det er ofte her uenigheden opstår. Få derfor skrevet ind hvor længe udvikleren retter fejl uden beregning og hvordan I skelner mellem en fejl og en ændring. Står der meget på spil, så få kontrakten tjekket af en advokat. Det her er ikke juridisk rådgivning.

Hvad sker der hvis udvikleren bruger færre timer end forventet ved fastpris?+

Så beholder udvikleren forskellen. Det er den anden side af aftalen: udvikleren bærer risikoen for at det tager længere tid og får gevinsten hvis det går hurtigere. Du har betalt for et resultat og ikke for timer. Synes du at det er urimeligt, er timepris med et loft sandsynligvis den model der passer bedst til dig.

Hvad betyder time and materials i et tilbud?+

Time and materials er den engelske betegnelse for timepris, og du møder den især i tilbud fra udenlandske leverandører og større bureauer. Du betaler for brugte timer plus eventuelle udgifter, fx licenser eller hosting. Spørg om der er et loft, hvor ofte der bliver faktureret, og om udgifterne bliver lagt videre til kostpris eller med et tillæg.