Frilansutvecklare - Fastpris eller pris per timme?

Så du har bestämt dig för att anlita en frilansutvecklare (eller en mindre byrå). Nu få du flera olika förslag på prismodeller för er nya hemsida eller app och du frågar dig vilken som är bäst för dig. Det finns givetvis inget svar som alltid stämmer men jag ska förklara varför jag tycker man ska undvika fastpris på utveckling.

Det är ofta lockande att avtala om fastpris. Du vet ju trots allt då hur mycket det kommer kosta då. Det finns gånger då ett fastpris på utveckling kan fungera. Ett exempel är om du har en väldigt väldefinierad uppgift så som implementera Klarnas api för betalning för en redan befintlig webbshop i en standardlösning.

Det är mindre lämpligt för stora och mindre snäva uppdrag så som "bygg en ny hemsida" eller "bygg en ny app". Det beror på att det är väldigt svårt att uppskatta hur lång tid det kommer ta att bygga något komplext.

Varför är det så svårt att uppskatta hur lång tid det tar att utföra komplexa projekt? Det finns två stora anledningar till det. Det första är att ju mer komplext ett projekt är desto större risk att något inte går som man tänkt vilket även kan påverka hur långtid resten av projektet tar. Det andra är vad man på engelska kallar för "scope creep" och det innebär att projektet växer och växer under projektets gång.

Låt oss ta ett exempel: Pelle vill bygga en träningsapp som kan hålla reda på hur många gånger han utfört ett träningsmoment på gymmet. Appen behöver alltså hålla reda på vilka träningsmoment som användaren utfört och hur många gånger och på vilken dag. En bit in i projektet kommer Pelle på att det vore bra om det fanns träningsprogram i appen. Projektet växer. Lite senare kommer Pelle på att det även vore bra om man hade en lokaliseringsfunktion i appen så att appen vet när man är på gymmet och kan rekommendera ett träningsprogram. Projektet växer. Du ser hur ett litet projekt snabbt kan växa och bli mer omfattande.

Problemet med fastpris när det gäller komplexa projekt är att det är väldigt svårt att förutsäga om projektet kommer bli mer omfattande pågrund av scope creep eller att något inte går som planerat. Det betyder att utvecklaren antingen måste göra ett väldigt stort påslag av timmar för att ha marginal (om utvecklaren tror att projektet kommer ta 100 timmar måste han kanske ta betalt för 250 timmar för att vara på säkra sidan) eller att man skriver ett detaljerat kontrakt där man listar de funktioner som sidan ska ha i detalj och att man sen inte tillåter nya funktioner. Problemet med det är att resultatet blir sämre. Många gånger vet man inte när man börjar ett projekt exakt vilka funktioner man behöver. Det är därför helt naturligt att projektet växer under tiden.

Om vi jämför detta med att betala för faktiskt arbetad tid ser vi många fördelar. Det är plötsligt helt OK om projektet förändras under projekts tid. Utvecklaren kan fortfarande göra en tidsuppskattning och säga att projektet kommer ta X antal timmar och priset är Y kr/timme. Då kan du ändå få en uppskattning om vad kostnaden blir även om det finns risk för att priset blir högre om du senare vill lägga till fler funktioner.

I slutändan bestämmer du om du vill anlita en utvecklare till fastpris eller per timme men nu har du lite mer information om för- och nackdelarna med respektive prismodell.