Clutch Developer
SV
Book a call

Fast pris vs time and materials: vilken kontrakt skyddar dig egentligen

En modell skjuter risken på din leverantör. Den andra skjuter den på dig. Ingen är generös.

Inköp behandlar detta som ett kommersiellt val. Det är det inte. Det är ett beslut om vem som betalar för att ha fel, och att välja fel är hur mjukvaruprojekt blir motsatsiga.

Vad varje modell faktiskt säger

Fast pris säger: vi är överens om vad som byggas, och jag tar risken att uppskatta det fel. Leverantören prisar in den risken. Du betalar en premie för säkerhet — typiskt 20–40% över det ärliga budgeten.

Time and materials säger: vi är överens om en riktning, och du tar risken att det tar längre tid. Du betalar bara för arbetet som utfördes. Du betalar också för varje timme som gick åt vägen.

Ingen är generös. Båda är rationella. Misslyckandet är att välja den som inte passar hur väl du förstår arbetet.

När fast pris är rätt

  • Scopet är verkligen möjligt att känna — en omdesign av en definierad uppsättning skärmar, en migration med känd källa och mål, en specifik integration.
  • Du har en hårt extern deadline (en finansieringsmilstolpe, en mässa, ett regulatoriskt datum) och behöver att datumet är någon annans problem.
  • Du kan inte acceptera budgetavvikelse, och du kommer att acceptera att scopet krymper för att skydda siffran.
  • Relationen är ny och du vill ha en avgränsad första engagement innan du binder dig till mer.

Klausulen som bestämmer allt: vad händer när scope ändras. Om svaret är "vi diskuterar det", har du ett time and materials-kontrakt med extra steg och dåligare mående.

När time and materials är rätt

  • Du håller fortfarande på att upptäcka vad produkten ska vara. Att fixa ett pris på något okänt fixar bara scopet, och det blir fel scope.
  • Du har någon teknisk på din sida som kan bedöma om timmarna är verkliga.
  • Arbetet är kontinuerligt — en roadmap snarare än ett projekt.
  • Prioriteringar kommer att förändras, och du vill omdirigera snarare än omförhandla.

Fellägen

Fast pris misslyckas genom att göra varje samtal till en förhandling. Leverantörens marginal beror nu på att göra mindre, så en bra idé i vecka tre blir en ändringsförfrågan. Kvalitet blir tyst releaseventilen, för det är det enda som ingen specificerade. Du får exakt vad som står skrivet, vilket sällan är vad du behövde.

Time and materials misslyckas genom att ta bort deadline. Utan ett fast slut finns det ingen tvingande funktion på scope, och "medan vi är där uppe" blir den dyraste frasen i projektet. Sex månader senare har du utmärkt kod och ingen produkt — se varför agencies tar sex månader.

Den modell jag faktiskt skulle rekommendera

Ett fast pris, fast varaktighet-fönster med förhandlingsbar innehål. Två veckor, ett pris, överenskommet på förhand. Vad som går in i dessa två veckor beslutas tillsammans och kan ändras fram till det ögonblick arbetet börjar på det.

Detta inverterar det vanliga bytet. Leverantören bär leveransrisken (datumet och priset är fixade), och du behåller flexibiliteten (vad som byggas kan röra sig). Ingen är incitamenterad att argumentera om scope, för scope är inte vad som skyddas — fönstret är.

Det fungerar bara om fönstret är kort. En fast tolvmånaders engagement med flexibelt scope är inte detta; det är en retainer med en trevlig historia.

Vad som faktiskt händer när scope ändras

Det kommer att göra det. Frågan är vad kontraktet gör att folk gör åt det.

Under fast pris, är en ändringsförfrågan en förhandling med en marginal bifogad. Leverantören måste prisa det, du måste godkänna det, och nu är ni båda lite på motsatta sidor. Det rationella draget för leverantören är att tolka originalscopet snävt; det rationella draget för dig är att tolka det brett. Ingen av er beter sig dåligt och relationen förverkligas fortfarande.

Under time and materials, är en ändring bara nästa veckas arbete. Friktionsfritt — vilket är problemet. Ingenting tvingar någon att fråga om ändringen är värd dess kostnad, för kostnaden dyker aldrig upp som ett beslut. Det dyker upp tre månader senare som en burnrate.

Under ett fast fönster, kostar en ändring något synligt och omedelbar: det förskjuter något annat i samma två veckor. Det är den friskaste versionen, för avvägningen är explicit och gjord av den person som borde göra det — du.

Hybriden som de flesta egentligen vill ha

I praktiken är formen som fungerar för mest produktarbete:

  1. En liten betald discovery, fast pris. Ett par dagar till en vecka. Slutar i ett scope som ni båda tror på, inte en deck. Om leverantören inte vill göra detta, planerar de att descobra på din budget.
  2. Fast pris, fast varaktighet-leveransfönster. Två eller tre veckor vardera, prissatta på förhand, innehål överenskommet i början av vardera. Leverera något verkligt i slutet av varje en.
  3. Time and materials för svansen. Support, små ändringar, den långa tystna perioden efter lansering. Ingen borde fixera ett pris på arbete som ännu inte har tänkts ut.

Discoverystegget är det som gör de fasta priserna ärliga. Utan det, är en leverantör som fixerar ett pris att gissa, och gissningen inkluderar en marginal för deras egen osäkerhet som du betalar för.

Taxa kontra total kostnad

En 400 €/dag-leverantör som behöver två veckors uppvärmning kostar mer än en 900 €/dag som börjar producera på tisdag. Detta är den vanligaste falska ekonomin inom mjukvaran, och den överlever för att dagtakten är siffran i kalkylbladet och uppvärmningen inte är.

När du jämför leverantörer, fråga varje: när ser jag den första arbetande saken? Det enda datumet kodar uppvärmning, processvikt, personlighetsverklighet och säkerhet. Det är mer förutspådande för total kostnad än taxan är.

Klausuler värd mer än takten

Oavsett vilken modell du väljer, besluter dessa om det fungerar:

  • IP-tilldelning vid betalning, inte vid slutförande. Om projektet stannar tidigt bör du äga vad du betalade för.
  • Källåtkomst från dag ett. Inte en handoff i slutet. Om du inte kan se lagret kan du inte verifiera någonting.
  • En namngiven person. Kontrakt är med företag; arbete görs av människor. Namnge dem, och säg vad som händer om de ändras.
  • En exit som inte är punitiv. En leverantör som är säker på sitt arbete behöver inte en lock-in-klausul.
  • Definition av gjort. Skriven ned, på förhand, i termer som en icke-ingenjör kan kontrollera.

Om du får de fem rätt, spelar prismodellen långt mindre roll än någon i rummet tror för närvarande.