Een offerte aanvragen voor een webapplicatie of portaal voelt soms als het kopen van een huis waarvan je de plattegrond nog niet hebt gezien. Je wilt weten wat het kost, maar de prijs hangt af van keuzes die je nog niet hebt gemaakt. Dat spanningsveld is precies waar de discussie over vaste prijs versus uurtarief over gaat. Beide modellen hebben hun plek, maar de verkeerde keuze op het verkeerde moment kost je meer dan geld: het kost je tijd, vertrouwen en in het ergste geval een project dat halverwege vastloopt.
Wanneer een vaste prijs wél werkt
Een vaste prijs werkt goed als de scope vaststaat. Daarmee bedoel ik niet dat je een globaal idee hebt van wat je wil. Ik bedoel dat de schermen, de logica, de koppelingen met externe systemen en de randgevallen zijn uitgewerkt voordat de eerste regel code wordt geschreven. Zit dat niveau van detail er niet in, dan verplaats je het risico van onduidelijkheid naar de developer of het bureau, die dat risico vervolgens inprijzen met een ruime buffer.
Zelf werk ik bij grotere trajecten pas met een vaste prijs nadat er een uitgebreide analyse heeft plaatsgevonden. Dat is een betaalde stap waarbij ik de functionele eisen, de technische architectuur en de afhankelijkheden van buitenaf in kaart breng. Pas na die analyse weet ik of ik een betrouwbaar prijskaartje kan hangen aan het bouwen. Zonder dat fundament is een vaste prijs eigenlijk gewoon een schatting met psychologische zekerheid eromheen.
Het gevaar van een te vroeg gegeven vaste prijs zit hem in wat er daarna gebeurt. Zodra een ondernemer iets wil aanpassen, een inzicht krijgt of een koppeling nodig blijkt die niet in de originele scope stond, begint het meerwerk-circuit. Elke kleine afwijking wordt een apart gesprek over extra kosten. Dat vreet aan het vertrouwen en maakt de samenwerking stroef, terwijl het project inhoudelijk juist de goede kant op gaat.
Waarom uurtarief meer flexibiliteit geeft dan je denkt
Het idee dat werken op uurbasis per definitie duurder uitvalt klopt niet. Een trajectprijs zonder strakke scope kan uiteindelijk veel hoger uitvallen dan een eerlijk uurtarief, omdat meerwerk al is ingecalculeerd in de buffer. Bij een uurtarief betaal je voor wat er daadwerkelijk gedaan wordt, niet voor het risico dat iets mee kan vallen of tegenvallen.
Wat ik in mijn werk zie is dat projecten die starten met "we weten globaal wat we willen" vrijwel altijd op uurbasis beter uitpakken. Denk aan een klantportaal waarbij de exacte rechtenstructuur pas duidelijk wordt als je hem gaat inrichten, of een webshop met maatwerk-logica waarbij de koppeling met het eigen logistieke systeem gaandeweg meer lagen blijkt te hebben dan verwacht. In die gevallen is een vaste prijs eigenlijk een fictie.
Transparantie is hier het sleutelwoord. Met een goed bijgehouden urenadministratie en heldere rapportage weet je als opdrachtgever precies waar de tijd naartoe gaat. Dat vraagt om vertrouwen in de developer, maar het geeft je ook de mogelijkheid om bij te sturen. Wil je een feature later inplannen omdat het budget op dreigt te raken? Dat gesprek is op uurbasis veel makkelijker te voeren dan bij een vaste prijs waar elke aanpassing een nieuw offerte-rondje vereist.
De scope is altijd het echte discussiepunt
Wat beide modellen gemeen hebben: ze staan of vallen met de kwaliteit van de scope. Een slecht gedefinieerde scope bij een vaste prijs leidt tot conflict. Diezelfde slechte scope bij uurtarief leidt tot verrassingen op de factuur. Het probleem is dus nooit het tarief-model op zich, maar de mate waarin het project vooraf is doorgedacht.
Ondernemers die voor het eerst een webapplicatie laten bouwen onderschatten dit geregeld. Ze hebben een helder beeld van het eindresultaat, maar niet van de stappen ernaartoe. Hoe werkt de authenticatie? Wie krijgt welke rechten? Wat gebeurt er als een gebruiker een fout invoert? Hoe worden koppelingen met externe diensten afgehandeld als die dienst tijdelijk uitvalt? Dit zijn geen details die je aan de developer kunt overlaten zonder gevolgen voor scope, doorlooptijd en budget.
Mijn aanpak is altijd om vóór de offertefase samen met de opdrachtgever door de kritieke gebruikersstromen te lopen. Niet om alles dicht te timmeren, maar om inzicht te krijgen in wat echt vast staat en wat nog open ligt. Dat gesprek bepaalt welk model het meest eerlijk is voor beide kanten. Een project van drie schermen en een formulier kan prima op vaste prijs. Een portaal voor honderd gebruikers met rollen, rapportages en API-koppelingen verdient een eerlijker aanpak.
Hoe je een betrouwbare offerte herkent
Een offerte die geloofwaardig is, legt uit hoe de prijs is opgebouwd. Staat er één getal zonder verdere toelichting, dan weet je niet of dat getal is berekend op basis van een gedetailleerde scope of op basis van onderbuikgevoel en een veiligheidsmarge. Vraag altijd om een uitsplitsing per fase of per onderdeel, zelfs als de eindfactuur op vaste prijs is.
Fases geven je ook de mogelijkheid om tussentijds te evalueren. Na de bouw van het fundament weet je of de aannames kloppen, of de samenwerking prettig verloopt en of de prioriteiten zijn verschoven. Bij een fasische aanpak kun je na elke fase besluiten door te gaan, te pauzeren of bij te sturen. Dat is een veel gezondere manier van samenwerken dan een monolitisch contract van zes maanden met één opleverdatum.
Wat ik zelf doe bij trajecten boven een bepaalde omvang: ik splits altijd op in een analysefase, een bouwfase en een stabilisatiefase. De analysefase is altijd op uurbasis, omdat het doel ervan is om helderheid te creëren. De bouwfase kan daarna op vaste prijs als de scope scherp genoeg is, of op uurbasis als er nog te veel open eindjes zijn. De stabilisatiefase, waarbij bugs worden opgelost en laatste aanpassingen worden doorgevoerd, is bijna altijd op uren. Die uren zijn vooraf begroot, maar de exacte invulling hangt af van wat er tijdens de bouw naar boven komt.
Een rode vlag is een developer of bureau dat zonder doorvragen een vaste prijs geeft voor een project dat meerdere externe koppelingen, rollen of maatwerk-logica bevat. Dat wijst er niet op dat ze het beter begrijpen dan anderen. Het wijst erop dat ze de risico's hebben weggestopt in een buffer die jij betaalt, of dat ze verwachten het meerwerk later te verrekenen.
Kijk ook naar wat er in de offerte staat over wijzigingen. Staat er iets als "wijzigingen worden verrekend als meerwerk", dan is de vaste prijs eigenlijk een open einde in vermomming. Een eerlijke vaste prijs beschrijft precies wat er wél en niet in zit, en legt ook vast wat er gebeurt als de scope verandert.
Het prijsmodel is uiteindelijk een weerspiegeling van hoe goed een project is voorbereid. Een goed voorbereide scope, een eerlijke developer en een opdrachtgever die bereid is om mee te denken in het traject: dat is de combinatie die projecten doet slagen, ongeacht of er een vaste prijs op staat of een uurtarief.
Webapplicaties, portalen en maatwerksoftware zijn precies het soort trajecten waarbij de keuze tussen vaste prijs en uurtarief het meest van belang is. Op https://pimvdmolen.nl/diensten/webapplicaties lees je hoe ik dit soort projecten aanpak en hoe ik de scope samen met opdrachtgevers uitwerk voordat er een offertemodel wordt gekozen. Wil je sparren over jouw project of een offerte aanvragen? Neem dan contact op via https://pimvdmolen.nl/contact.