Fastpris eller timepris på utviklingsprosjekter: hva lønner seg?

Fastpris lønner seg når jobben kan beskrives presist før den starter. Timepris lønner seg når den ikke kan det, og det finnes flere slike jobber enn bransjen liker å innrømme. Jeg jobber selv mest på fastpris, men valget handler egentlig om én ting: hvem som skal bære risikoen når estimatet bommer.

Hvem bærer risikoen

Alle utviklingsprosjekter starter med et estimat, og estimater bommer. Ikke alltid, men ofte nok til at noen må ta regningen når det skjer.

Med fastpris er det utvikleren som tar den. Jeg har lovet et tall. Bruker jeg flere timer enn planlagt, er det mitt problem, ikke ditt. Med timepris er det du som tar den. Du betaler for medgått tid, enten jobben tok 40 timer eller 90.

Hvorfor bommer estimater? Sjelden fordi utvikleren er dårlig. Oftere fordi et API ikke virker som dokumentert, fordi en tredjepart bruker to uker på å svare, eller fordi behovet viser seg å være litt annerledes enn alle trodde. Usikkerheten er ekte. Spørsmålet er bare hvem som betaler for den.

Ingen av modellene er snillere enn den andre. De plasserer den samme risikoen på hver sin side av bordet, og prisen gjenspeiler det. En ærlig fastpris inneholder en buffer for usikkerhet. En ærlig timepris er åpen i begge ender: den kan ende under fastprisen, og den kan ende langt over.

Når fastpris beskytter deg

Fastpris er riktig når leveransen kan defineres. En nettside med kjente sider og funksjoner. Et verktøy som løser ett konkret problem. En integrasjon mot et API som er dokumentert. Da kan en utvikler vurdere jobben skikkelig og stå for tallet.

Tre ting får du igjen:

Budsjettsikkerhet. Du vet sluttsummen før du sier ja. Det gjør beslutningen til et regnestykke, ikke et sjansespill. Du kan avklare finansiering, sammenligne tilbud og si nei uten å ha brukt en krone. For en liten bedrift med stramt budsjett er den forutsigbarheten ofte verdt mer enn en mulig besparelse.

Riktig insentiv. Utvikleren tjener på å bli ferdig, ikke på at arbeidet drar ut. Effektivitet og pris drar i samme retning.

En tvungen spesifikasjonsrunde. Ingen seriøs utvikler gir fastpris på noe de ikke forstår. Tilbudsprosessen tvinger frem samtalen om hva som faktisk skal bygges, hva som er med, og hva som ikke er med. Den samtalen er verdifull uansett hvilken modell dere lander på. Mange prosjekter sporer av nettopp fordi den aldri ble tatt.

Når timepris er det ærlige valget

Noen jobber kan ikke beskrives presist på forhånd. Da er fastpris feil verktøy, og en utvikler som gir deg fastpris likevel, gjør deg ingen tjeneste.

Timepris er ærligere når:

• Arbeidet er utforskende. Dere vet ikke ennå hva som skal bygges. Research, prototyper, en pilot der målet er å lære noe.
• Det er vedlikehold. Små, hyppige oppgaver over tid. Skriftlig tilbud for hver tretimersjobb er administrasjon ingen trenger.
• Omfanget kommer til å endre seg. Produktutvikling der retningen justeres hver uke, hører hjemme på timepris eller en løpende avtale.

Derfor tar jeg selv feilretting og småjobber på eksisterende løsninger på timepris, hos meg 1 000 kr per time. Det ville vært rart å late som at slike jobber kan avgrenses på forhånd.

Modellene kan også kombineres. En kort, timebasert kartlegging først, for å avklare omfanget. Deretter fastpris på selve byggingen. For større jobber med uklare hjørner er det ofte den ryddigste veien.

Et varsku til slutt: vær skeptisk til fastpris på en jobb ingen har klart å avgrense. Kjennetegnene er gjenkjennbare. Prisen kom uten en skikkelig samtale, tilbudet mangler en liste over hva som ikke er inkludert, og tallet er påfallende rundt. Da er «fastprisen» i praksis et timeestimat med stor buffer på toppen. Du betaler for usikkerheten uansett, bare skjult og på forhånd. Det er timepris med dårligere vilkår.

Slik bygges et fastpristilbud

Slik gjør jeg det, og slik bør du forvente at andre gjør det:

1. En samtale først. Hos meg er de første 20 minuttene gratis. Du beskriver hverdagen din, ikke en kravspesifikasjon. Jeg stiller spørsmålene som trengs for å forstå jobben.
2. Skriftlig tilbud. Tilbudet definerer leveranser, pris, tidslinje og avhengigheter. Det står svart på hvitt hva som er inkludert.
3. Avgrensning begge veier. Listen over hva som ikke er inkludert, er like viktig som listen over hva som er det. Den stopper de fleste konflikter før de oppstår.
4. Endringshåndtering avtalt på forhånd. Endringer avtales skriftlig før de settes i gang, med justert pris og tidslinje der det trengs. Det står i vilkårene mine, ikke bare i hodet mitt.

Faktura følger en avtalt plan, normalt månedlig eller per leveranse. Fastpris betyr altså ikke at alt betales på forskudd.

Prisintervallene for mine tjenester viser hvor slike tilbud pleier å lande for ulike typer jobber.

Regneeksempel

Ta et konkret eksempel: et lite verktøy for en håndverksbedrift, som genererer tilbud automatisk i stedet for manuelt kveldsarbeid. Jobben anslås til rundt 55 timers arbeid. Alle tall er eksklusive mva.

Først timepris. Typiske markedspriser i Norge: konsulentselskaper ligger ofte på 1 100 – 1 800 kr per time, frilansere gjerne på 800 – 1 300 kr. Dette er anslag for hva markedet pleier å ta, ikke statistikk. Vi regner med 1 200 kr per time.

• Går alt glatt og jobben tar 45 timer: 54 000 kr.
• Går det som estimert, 55 timer: 66 000 kr.
• Sklir det til 85 timer: 102 000 kr.

Så fastpris. Jeg ser den samme usikkerheten og priser den inn. Tilbudet blir 68 000 kr, uansett hvor mange timer jobben faktisk tar.

Resultatet: går prosjektet glatt, sparer du 14 000 kr på timepris. Sprekker det, sparer du 34 000 kr på fastpris. I midten er modellene omtrent like. Fastpris er med andre ord en forsikring. Du betaler en premie på noen tusenlapper for å slippe nedsiden. Om det er verdt det, avhenger av hvor vondt en sprekk på 30 000 kr ville gjort i budsjettet ditt.

To ting til hører med i regnestykket. Timepris krever at du følger opp underveis: timelister skal leses, og du må selv vurdere om fremdriften står i stil med fakturaene. Fastpris krever at utvikleren faktisk forstår jobben. Ellers er bufferen ren gjetning, og da betaler en av dere for det.

Endringer underveis

Begge modeller har samme svake punkt: endringer som dukker opp etter start. I et fastprisprosjekt skaper de friksjon, for «det var ikke med i tilbudet». I et timeprisprosjekt skaper de en stille voksende faktura som ingen har godkjent.

Løsningen er den samme i begge tilfeller: skriftlig endringshåndtering. Hos meg fungerer det slik: du ber om en endring, og jeg svarer med hva den koster og hva den gjør med tidslinjen. Vi avtaler det skriftlig før noe settes i gang. Ingen overraskelser på fakturaen, ingen diskusjon i etterkant.

Og én ting til: endringer er ikke nødvendigvis et problem. Ofte betyr de at du har lært noe viktig om ditt eget behov. En god prosess gjør det billig å si det høyt tidlig, i stedet for dyrt å oppdage det til slutt.

Spørsmål du bør stille uansett modell

Modellen alene beskytter deg ikke. Det gjør avtalen. Still disse spørsmålene før du signerer:

• Hva er konkret inkludert, og hva er ikke?
• Hva skjer når jeg ber om en endring underveis, og hvordan prises den?
• Hvem eier kode, innhold og kontoer når alt er betalt?
• Hva koster driften etterpå, per måned?
• Hva skjer hvis prosjektet må stoppes halvveis?
• Får jeg alt dette skriftlig før vi starter?

En leverandør som svarer klart på disse seks, kan du trygt jobbe med på begge modeller. En som vrir seg unna, bør du være forsiktig med uansett modell.

Ta en prat før du bestemmer deg

Usikker på om prosjektet ditt egner seg for fastpris? Ta kontakt, så finner vi ut av det sammen. De første 20 minuttene koster ingenting, og du får et ærlig svar. Også hvis svaret er at du bør be om timepris.