Vaste prijs of retainer: hoe kies je het juiste samenwerkingsmodel?

Voor de eerste regel code wordt geschreven, moeten klanten en ontwikkelaars het eens zijn over hoe het werk wordt gestructureerd en gefactureerd. De keuze tussen een vaste prijs en een doorlopende retainer bepaalt alles: hoe vereisten worden gedefinieerd, hoe wijzigingen worden afgehandeld, wie het risico draagt en hoe de samenwerking er zes maanden later uitziet.

Geen van beide modellen is universeel beter. Beide hebben specifieke omstandigheden waarin ze goed werken, en specifieke manieren waarop ze mislukken.

Vaste prijs: wanneer het werkt

Een vaste prijs werkt wanneer de scope werkelijk stabiel is. Dit betekent dat je voor de start van het werk precies kunt omschrijven wat er wordt gebouwd, hoe "klaar" eruitziet en wat uitdrukkelijk buiten scope valt. Voorbeelden waarbij een vaste prijs de juiste keuze is:

• Het bouwen van een afgebakende functionaliteit met duidelijke acceptatiecriteria (een betaalstroom, een rapportagemodule, een datamigratie)
• Een greenfield-project met een vastgestelde specificatie en een harde lanceerdatum
• Een eenmalige integratie tussen twee systemen met gedocumenteerde API's aan beide kanten

Voor de klant biedt een vaste prijs budgetzekerheid. Voor de ontwikkelaar schept het een duidelijke definitie van gedaan. Wanneer de scope stabiel is, profiteren beide partijen van die duidelijkheid.

Vaste prijs: wanneer het misloopt

Een vaste prijs loopt mis zodra de scope onzeker of veranderlijk is. Vereisten die aan het begin duidelijk lijken, groeien bijna altijd uit wanneer de klant werkende software ziet. Elk wijzigingsverzoek wordt een onderhandeling. De ontwikkelaar heeft een prikkel om het minimum te leveren dat aan de specificatie voldoet. De klant is verrast door wat wel en niet is inbegrepen.

Bij doorlopende productontwikkeling, waarbij prioriteiten verschuiven, gebruikers feedback geven en de backlog elke sprint verandert, creëert een vaste prijs bij elke stap wrijving.

Retainer: wanneer het werkt

Een retainer werkt wanneer je doorlopende capaciteit nodig hebt over een langere periode in plaats van een eenmalig omschreven resultaat. Voorbeelden:

• Een groeiend SaaS-product waarbij de roadmap maand voor maand wordt bepaald
• Een intern systeem dat doorlopend onderhoud, kleine functies en snelle doorlooptijden vereist
• Een ingesloten ontwikkelaarsrol: standups bijwonen, pull requests reviewen, bijdragen aan architectuurkeuzes

Retainers geven de ontwikkelaar de kans om echte kennis van je codebase op te bouwen. Die kennis accumuleert: een ontwikkelaar die zes maanden in jouw systeem heeft gewerkt, lost een probleem op in twee uur dat een nieuwe medewerker twee dagen zou kosten. Die opgebouwde kennis is de primaire waarde van een langdurige samenwerking.

Retainer: wanneer het misloopt

Een retainer zonder mijlpalen is moeilijk te evalueren. Als geen van beide partijen bijhoudt wat er in een bepaalde maand is opgeleverd, drijft de samenwerking. Klanten hebben het gevoel dat ze geen waarde krijgen; ontwikkelaars hebben het gevoel dat de scope grenzeloos is. De oplossing is eenvoudige maandelijkse rapportage: wat is er opgeleverd, wat is er in uitvoering en wat staat er gepland.

Retainers vereisen ook een basis van vertrouwen. Als de klant elk uur moet goedkeuren voor het wordt besteed, ontstaat overhead die het snelheidsvoordeel van een retainer tenietdoet.

Drie vragen om te beslissen

Beantwoord bij het bepalen welk model bij jouw situatie past deze drie vragen:

• Kun je vandaag een volledige specificatie schrijven? Zo ja, dan kan een vaste prijs werken. Zo nee, dan past een retainer beter.
• Is dit een eenmalige bouw of doorlopend werk? Eenmalig: vaste prijs. Doorlopend: retainer.
• Wat is belangrijker: kostenzekerheid of iteratiesnelheid? Kostenzekerheid pleit voor een vaste prijs; iteratiesnelheid voor een retainer.

Wat wij aanbevelen

Bij Fantomu.dev kiezen we standaard voor een vaste prijs bij goed omschreven integraties en losstaande functionaliteiten, en voor een retainer bij klanten die producten bouwen. In de praktijk beginnen veel samenwerkingen met een vaste-prijs-verkenningsfase (een paar weken om de scope te bepalen, een technische specificatie op te stellen en werkwijzen vast te leggen) waarna wordt overgestapt op een retainer voor de bouw.

Het model moet het werk dienen. Als je twijfelt welk model past, is het antwoord bijna altijd: begin kleiner en meer omschreven, en breid daarna uit wanneer vertrouwen en kennis zijn opgebouwd.