Fixed price of nacalculatie: welk prijsmodel past bij software?

Definitie: Bij fixed price spreek je vooraf één vaste prijs af voor een vastgelegde scope, en draagt de bouwer het risico als het meer werk blijkt. Bij nacalculatie, ook wel time and material of regie genoemd, betaal je voor de werkelijk gewerkte uren tegen een afgesproken uurtarief, en draag je als opdrachtgever het risico van meer of minder werk.

In het kort

• Fixed price geeft zekerheid over het bedrag, maar vraagt een scope die vooraf echt vaststaat.
• Nacalculatie geeft flexibiliteit om bij te sturen, maar het eindbedrag staat niet vooraf vast.
• In een vaste prijs zit vrijwel altijd een opslag voor risico. Aanbieders noemen buffers van 20 tot 50 procent.
• Bij softwareprojecten werkt een mengvorm vaak het best: eerst afbakenen, daarna per fase of met een budgetplafond. Welk model het beste past, hangt vooral af van hoe zeker je bent over wat er gebouwd moet worden.

Wat betekent fixed price?

Fixed price betekent vaste prijs. Je spreekt met de bouwer af wat er wordt opgeleverd, wanneer en voor welk bedrag. Dat bedrag verandert niet, ook niet als de bouwer meer uren nodig heeft dan hij had ingeschat. In het Engels heet dit ook fixed fee of fixed price, fixed scope.

De kern zit in dat laatste deel. Een vaste prijs hoort bij een vaste scope. Alles wat in de offerte staat, valt onder de prijs. Alles wat er niet in staat, is meerwerk en wordt apart geprijsd. Hoe preciezer de scope is beschreven, hoe minder discussie er later ontstaat over wat er wel en niet bij hoort.

Fixed price komt uit een wereld waarin het eindresultaat goed te beschrijven is. Bij een verbouwing of een drukwerkopdracht werkt dat prima. Bij software is dat lastiger, omdat je vaak pas tijdens het bouwen ontdekt wat gebruikers echt nodig hebben.

Wat betekent nacalculatie?

Nacalculatie betekent dat de prijs achteraf wordt berekend op basis van wat er daadwerkelijk is gedaan. Je spreekt een uurtarief af, de bouwer houdt bij hoeveel uur hij aan je project besteedt, en je betaalt die uren, meestal per maand of per sprint. In de IT heet dit vaak time and material, afgekort T&M. In Nederland hoor je ook werken in regie of op uurbasis.

Bij nacalculatie hoort meestal wel een schatting vooraf. Die schatting is een verwachting, geen belofte. Wordt het werk groter, dan wordt de rekening hoger. Blijkt iets eenvoudiger, dan betaal je minder.

Het voordeel is flexibiliteit. Je betaalt voor wat er gebeurt, en je ziet per week of per sprint waar de uren naartoe gaan. Je kunt onderweg prioriteiten verschuiven, functies schrappen of toevoegen en reageren op wat je leert van gebruikers, zonder voor elke wijziging een nieuwe offerte te hoeven bespreken.

Fixed price en nacalculatie naast elkaar

Hoe komt een vaste prijs tot stand?

Een bouwer die een vaste prijs afgeeft, maakt eerst een schatting van de uren. Daarna telt hij er een buffer bij op voor alles wat onzeker is: onduidelijke eisen, koppelingen met systemen die hij nog niet kent, extra overleg, testrondes en wijzigingen die toch binnen de scope worden gerekend. Aanbieders van softwareontwikkeling noemen risicobuffers van 20 tot 50 procent.

Dat is niet oneerlijk. De bouwer neemt een risico over en laat zich daarvoor betalen. Maar het betekent wel dat een vaste prijs bijna nooit de goedkoopste route is als het project meevalt. Je betaalt voor zekerheid, ook als je die zekerheid achteraf niet nodig had.

Hoe groter de onzekerheid, hoe hoger de buffer. Een opdracht met een helder ontwerp, bekende techniek en geen koppelingen kan met een kleine opslag. Een project met nieuwe processen, meerdere gebruikersrollen en koppelingen met een ouder systeem vraagt een grote buffer, of een andere aanpak.

Rekenvoorbeeld

Een vereenvoudigd voorbeeld met een voorbeeldtarief van €100 per uur. Stel dat een bouwer een webapplicatie inschat op 200 uur, met de kanttekening dat het werkelijke aantal ergens tussen 170 en 260 uur zal liggen.

Bij fixed price betaal je in alle drie de gevallen hetzelfde. Bij nacalculatie hangt het af van hoe het project loopt. In dit voorbeeld is nacalculatie in twee van de drie scenario’s goedkoper, maar heb je geen zekerheid vooraf. Belangrijk detail: dit geldt alleen zolang de scope gelijk blijft. Komen er bij fixed price tijdens het project wensen bij, dan worden die als meerwerk bovenop de €25.000 gerekend.

Ter vergelijking met de praktijk: freelancers in Nederland vroegen in mei 2026 volgens de Freelance Markt Index gemiddeld €106 per uur, over alle vakgebieden heen. Een Nederlands bureau als Brixxs noemt voor API-koppelingen een uurtarief van €125.

Voor- en nadelen van fixed price

Voordelen

• Begrotingszekerheid. Je weet vooraf wat het project kost, wat prettig is voor een budget of een investeringsbesluit.
• Risico bij de bouwer. Loopt de bouw uit, dan is dat zijn probleem.
• Duidelijke afspraak. Er ligt een beschrijving van wat er wordt opgeleverd.

Nadelen

• Hogere prijs door de buffer. Je betaalt voor onzekerheid, ook als die zich niet voordoet.
• Weinig ruimte om te leren. Ontdek je tijdens het project dat iets anders moet, dan wordt dat meerwerk of een discussie.
• Veel voorbereiding. Om een vaste prijs te kunnen geven, moet de scope tot in detail beschreven zijn.
• Verkeerde prikkel. Een bouwer met een vaste prijs heeft er belang bij om zo weinig mogelijk extra te doen, ook als iets extra’s het product beter zou maken.

Voor- en nadelen van nacalculatie

Voordelen

• Flexibel. Je stuurt bij op basis van wat je ziet en hoort van gebruikers.
• Geen risico-opslag. Je betaalt de uren die er echt in zitten.
• Sneller beginnen. Je hoeft niet eerst alles vast te leggen voordat er iets gebouwd wordt.
• Gezamenlijk belang. Bouwer en opdrachtgever praten over wat het meeste waarde heeft, niet over wat binnen de scope valt.

Nadelen

• Minder zekerheid over het eindbedrag. Zonder bewaking kan een project duurder worden dan gedacht.
• Vraagt vertrouwen en inzicht. Je moet kunnen zien waar de uren naartoe gaan.
• Vraagt betrokkenheid. Iemand aan jouw kant moet keuzes maken en prioriteiten bewaken.

Hoe schat een bouwer de uren in?

Of je nu kiest voor een vaste prijs of voor nacalculatie, alles begint bij een schatting. Een goede schatting deelt het werk op in kleine onderdelen: inloggen en rechten, het klantoverzicht, het formulier, de koppeling met de boekhouding, de rapportage. Per onderdeel geeft de bouwer een bandbreedte, bijvoorbeeld 8 tot 14 uur, in plaats van één getal.

De breedte van die bandbreedte zegt veel. Een smalle marge betekent dat het onderdeel bekend terrein is. Een brede marge betekent onzekerheid, en dat is precies de plek waar een vaste prijs een flinke buffer krijgt. De grootste onzekerheden zitten meestal in koppelingen met andere systemen, het overzetten van bestaande gegevens, onduidelijke uitzonderingen in het proces en het aantal feedbackrondes.

Vraag bij een offerte daarom niet alleen naar het totaal, maar ook naar de opbouw. Een bouwer die per onderdeel kan uitleggen waar de uren in zitten, heeft het werk begrepen.

Mengvormen die in de praktijk goed werken

Tussen een vaste prijs voor alles en een open rekening zit veel ruimte. Een paar mengvormen die bij software vaak beter werken dan een van beide uitersten:

• Eerst afbakenen, dan bouwen. Je betaalt eerst voor een korte fase waarin het proces, de schermen en de afhankelijkheden worden uitgewerkt. Pas daarna wordt de prijs van de eerste versie bepaald, op basis van iets wat beide partijen begrijpen.
• Vaste prijs per fase of mijlpaal. Elke fase krijgt een eigen afgebakende scope en prijs. Na elke fase kun je bijsturen voordat de volgende begint.
• Nacalculatie met een plafond. Je werkt op uurbasis, maar spreekt een maximumbedrag af. Dreigt het plafond bereikt te worden, dan beslis je samen wat er nog wel en niet gebeurt.
• Vast budget per sprint. Elke periode van één of twee weken heeft een vast bedrag. Wat er in die sprint gebouwd wordt, bepaal je samen op basis van prioriteit.
• Vaste prijs voor de basis, uurtarief voor de rest. De kern van de applicatie gaat tegen een vaste prijs, latere uitbreidingen op uurbasis.

Wanneer kies je fixed price en wanneer nacalculatie?

Fixed price en de kwaliteit van de software

Een vaste prijs zet druk op de uren. Loopt een project uit, dan heeft de bouwer er belang bij om sneller af te ronden. Het risico is dat juist de onzichtbare onderdelen onder druk komen: geautomatiseerde tests, documentatie, een nette structuur in de code en beveiliging. Die zie je bij oplevering niet, maar je merkt ze wel bij elke latere aanpassing.

Spreek daarom ook bij een vaste prijs af wat “af” betekent. Bijvoorbeeld: elk onderdeel is getest, de code staat in een repository waar jij toegang toe hebt, er is een korte technische beschrijving en er is een beveiligingscontrole gedaan voor livegang.

Prijsmodellen voor onderhoud na oplevering

Na de livegang begint een nieuwe fase, met een eigen prijsmodel. De gangbare vormen:

• Op uurbasis. Je betaalt alleen voor wat er gebeurt. Overzichtelijk bij weinig wijzigingen.
• Urenbundel of strippenkaart. Je koopt vooraf een aantal uren in, vaak tegen een iets lager tarief, en die worden afgeschreven bij gebruik.
• Vast maandbedrag. Een vast bedrag voor afgesproken werk, zoals updates, monitoring, back-ups en een aantal uur voor kleine verbeteringen.

Leg in elk geval vast wat wel en niet binnen het onderhoud valt, wie meldingen oppakt en hoe nieuwe functies worden geprijsd. Nieuwe functionaliteit is doorontwikkeling en hoort meestal niet bij het standaardonderhoud.

Is je project klaar voor een vaste prijs?

Een vaste prijs werkt pas eerlijk als je de meeste van deze vragen met ja kunt beantwoorden:

• Is beschreven welke gebruikers welke taken moeten kunnen uitvoeren?
• Zijn er schermschetsen of een klikbaar prototype?
• Is bekend met welke systemen gekoppeld wordt, en is daar documentatie van?
• Weet je welke gegevens moeten worden overgezet?
• Zijn de acceptatiecriteria per onderdeel duidelijk?
• Verwacht je weinig veranderingen tijdens de bouw?

Bij meerdere keren nee is een vaste prijs voor het hele project vooral een gok, voor beide partijen.

Welk prijsmodel past bij een MVP?

Bij een MVP, de kleinste werkende versie van een product, wil je juist leren wat gebruikers nodig hebben. Dat botst met een volledig vastgelegde scope. Toch wil je als opdrachtgever weten waar je aan begint.

Een werkbare aanpak is een vast budget met een vaste periode. Je spreekt bijvoorbeeld af dat er binnen een bepaald bedrag en een aantal weken een eerste versie komt, en bepaalt samen per sprint wat de hoogste prioriteit heeft. De kern moet werken; wat er niet in past, schuift door naar een volgende versie. Zo heb je begrotingszekerheid zonder dat je vooraf elke functie hoeft vast te leggen.

Meerwerk en minderwerk

Bij een vaste prijs is meerwerk alles wat buiten de afgesproken scope valt. Dat klinkt simpel, maar de discussie gaat meestal over de grijze gebieden. Valt een extra filter op een overzicht onder “zoeken binnen de klantenlijst”, of is het nieuw? Hoe vager de scope, hoe vaker die vraag terugkomt.

Spreek daarom vooraf een wijzigingsprocedure af. Een nieuwe wens wordt beschreven, de bouwer geeft een prijs en planning, en pas na akkoord wordt het gebouwd. Dat voorkomt verrassingen aan het eind van het project. Spreek ook af hoe het werkt met minderwerk: als een functie vervalt, wordt dat dan verrekend?

Bij nacalculatie bestaat meerwerk in die zin niet. Een nieuwe wens kost gewoon de uren die hij kost. Daar staat tegenover dat je zelf moet bewaken of de som van alle wensen nog binnen je budget past.

Wat leg je vast in de afspraak?

Welk model je ook kiest, deze punten horen op papier:

1. De scope of de prioriteiten. Bij fixed price een volledige beschrijving, bij nacalculatie een geprioriteerde lijst.
2. Acceptatiecriteria. Wanneer is een onderdeel af? Bijvoorbeeld: deze gebruiker kan deze taak afronden in deze situatie.
3. Uurtarief en rapportage. Ook bij fixed price, voor meerwerk. Bij nacalculatie: hoe vaak krijg je inzicht in de bestede uren?
4. Wijzigingsprocedure. Hoe een nieuwe wens wordt beoordeeld, geprijsd en goedgekeurd.
5. Betaalmomenten. Per maand, per sprint of per opgeleverde mijlpaal.
6. Eigendom en toegang. Wie wordt eigenaar van de broncode en wie heeft toegang tot de repository en de hosting?
7. Garantie en herstel. Hoe lang worden fouten in opgeleverde onderdelen zonder kosten opgelost?
8. Beheer na oplevering. Onderhoud, updates en ondersteuning zijn een aparte afspraak, los van de bouw.

Veelgehoorde misverstanden

• “Een vaste prijs is altijd goedkoper.” Niet als het project meevalt. Dan betaal je de buffer zonder dat die nodig was.
• “Nacalculatie is een blanco cheque.” Niet met een plafond, een schatting per onderdeel en een regelmatige rapportage van de uren.
• “Met een vaste prijs hoef ik me nergens mee te bemoeien.” Ook bij fixed price moet je testen, feedback geven en keuzes maken. Anders klopt het resultaat niet met wat je bedoelde.
• “Bij nacalculatie heeft de bouwer geen reden om op te schieten.” Een bouwer die zijn uren goed laat zien en per sprint werkende software oplevert, maakt dat risico zichtbaar en klein.

Wat betekent dit voor jouw project?

Prijs en planning volgen voor mij uit de omvang van de opdracht en de afhankelijkheden. Daarom begin ik met een procesgesprek: wat gebeurt er nu, wie werkt ermee, waar zit de impact? Past er een vervolg, dan werken we in een betaalde blauwdruk een afgebakend proces uit, met schermschetsen, afhankelijkheden en een voorstel voor de eerste versie.

Die volgorde maakt elk prijsmodel eerlijker. Een vaste prijs op basis van een blauwdruk heeft minder buffer nodig, omdat er minder onzekerheid is. En nacalculatie op basis van een blauwdruk geeft een schatting waar je iets aan hebt. Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen, want daar hangt de rest van af.

In een voorstel leg ik daarnaast uit hoe beheer, eigenaarschap, toegang en ondersteuning geregeld zijn. Ik gebruik alleen bedragen en data die voor die specifieke opdracht zijn vastgesteld, geen standaardpakket dat later niet blijkt te passen.

Wil je weten wat jouw idee of proces zou kosten? Stuur me hoe het nu gaat en wie ermee werkt. Dan kijken we in ongeveer twintig minuten waar een logische eerste stap ligt en welke manier van afrekenen daarbij past.

Veelgestelde vragen over fixed price en nacalculatie

Wat is het verschil tussen fixed price en time and material?

Bij fixed price spreek je vooraf een vaste prijs af voor een vaste scope, en draagt de bouwer het risico van extra werk. Bij time and material betaal je de werkelijk gewerkte uren tegen een afgesproken tarief, en kun je onderweg flexibel bijsturen.

Is een vaste prijs voor software verstandig?

Een vaste prijs is verstandig bij kleine, goed omschreven opdrachten waarvan de scope niet verandert. Bij grotere of nieuwe projecten zit er een flinke risico-opslag in de prijs en is er weinig ruimte om bij te sturen. Een vaste prijs per fase na een afbakening is dan vaak beter.

Hoe houd je grip op de kosten bij nacalculatie?

Spreek een schatting per onderdeel en een budgetplafond af, laat de uren regelmatig rapporteren en beslis per sprint wat de hoogste prioriteit heeft. Zo zie je op tijd als een onderdeel meer tijd kost en kun je bijsturen.

Verwante termen

Total Cost of Ownership (TCO) · Uurtarief developer · Programma van eisen · Scope creep · Functioneel ontwerp · MVP · Build vs buy