Hoe je een software-offerte leest

Een software-offerte is voor de meeste ondernemers een document waar ze maar één regel van echt begrijpen: het bedrag onderaan. De rest is een mengeling van vaktermen en aannames waar je niets tegenin kunt brengen, omdat je niet weet wat normaal is. Dat is ongemakkelijk, want je tekent wel.

Ik schrijf zelf offertes en ik heb er in de loop der jaren genoeg gezien van anderen. Wat een offerte eigenlijk is, is een afspraak over verwachtingen. Het bedrag is daar slechts het gevolg van. Als de verwachtingen scherp staan, valt het bedrag op zijn plek en weten jullie allebei waar je aan toe bent. Staan ze vaag, dan is de prijs een startpunt voor discussies die je later gaat voeren, meestal op het slechtst mogelijke moment.

Wat er in mijn offertes staat

Mijn offertes hebben een duidelijke scope, concrete deliverables en een vaste prijs. Geen opgerekte uren.

Scope betekent: wat gaan we maken, en net zo belangrijk, wat gaan we niet maken. Dat tweede deel voelt raar om op papier te zetten en het is precies het deel dat later ruzie voorkomt. Deliverables betekent: wat krijg je in handen als het klaar is. Niet “een oplossing”, maar de dingen die je kunt aanwijzen en gebruiken.

De vaste prijs is een bewuste keuze en geen verkooptruc. Bij een vaste prijs verschuift het risico van een verkeerde inschatting naar mij. Als iets meer werk blijkt dan ik dacht, is dat mijn rekensom die niet klopte, niet jouw factuur die oploopt. Bij een uurtarief werkt het andersom: hoe slechter de inschatting, hoe meer er betaald wordt, en jij bent degene die het minst kan beoordelen of die uren nodig waren. Dat is geen prettige verdeling voor iemand die niet dagelijks in code kijkt.

Er zit ook een kant aan die minder vaak genoemd wordt. Een vaste prijs dwingt mij om vooraf echt na te denken over wat er gebouwd moet worden en wat eruit kan. Dat is dezelfde afweging die tijdens het bouwen de hele dag terugkomt: kan ik iets opleveren dat vandaag genoeg waarde toevoegt, of gaat er tijd in iets zitten dat straks niemand gebruikt. Een uurtarief hoeft die vraag nooit te beantwoorden.

Wat er gebeurt als je onderweg van gedachten verandert

Dit is de vraag die iedereen stelt zodra het woord “vast” valt. Terecht, want plannen veranderen altijd. Je gaat het product gebruiken, je praat met klanten, en dan blijkt iets anders te moeten dan je dacht.

Ik hanteer daar een simpel onderscheid in. Past de wijziging binnen de richting die we hebben afgesproken, dan draaien we binnen de scope bij. Dat hoort erbij en daar ga ik niet voor factureren. Gaat het om een andere richting, of om iets dat fors groter is dan wat we hebben afgesproken, dan passen we de scope en de prijs aan.

Dat is geen boetesysteem, het is boekhouding. Als jij halverwege besluit dat er ook een heel nieuw onderdeel bij moet, is dat vaak een prima beslissing voor je bedrijf. Het is alleen niet het werk waar we een prijs voor hebben afgesproken. Door dat expliciet te maken hoeft niemand te doen alsof, en blijft de afspraak kloppen met wat er daadwerkelijk gebeurt.

Wat hierbij helpt is dat die richting vooraf duidelijk is. Niet de schermen, maar het probleem dat we oplossen. Als beide partijen weten waarom er gebouwd wordt, is het meestal binnen een paar minuten duidelijk of een wens binnen de richting past of dat het iets nieuws is.

Twee regels waar ik meteen naar kijk

In offertes van anderen zijn er twee dingen die bij mij direct een vraag oproepen.

Het eerste is een vage regel die alleen “ontwikkeling” heet, met een groot bedrag ernaast. Dat is geen afspraak, dat is een bedrag met een label. Je kunt niet controleren wat erin zit, je kunt niet vaststellen wanneer het af is, en je kunt achteraf niet aanwijzen wat je precies gekregen hebt. Als je zo’n regel ziet, vraag dan wat er onder valt en wat er expliciet buiten valt. Een goed antwoord kost de ander vijf minuten. Blijft het antwoord vaag, dan is de scope zelf vaag, en dat is een groter probleem dan de prijs.

Een offerte die je niet kunt controleren, is geen offerte maar een intentie.

Het tweede zijn verstopte maandelijkse kosten. Licenties, hosting, onderhoudscontracten, beheerabonnementen. Op zichzelf is daar niets mis mee, want sommige van die kosten zijn echt. Het probleem is dat ze soms klein en achteraan in het document staan terwijl ze jarenlang doorlopen, en dan verandert het plaatje flink. Tel ze bij elkaar op voor drie jaar en leg dat bedrag naast de bouwsom. Dan weet je pas wat je werkelijk vergelijkt.

Vraag er ook bij wat er gebeurt als je stopt met betalen. Blijft je site of app draaien, kun je alles meenemen naar iemand anders, en op wiens naam staan het domein, de hosting en de code? Dat zijn geen achterdochtige vragen, dat zijn dezelfde vragen die je bij elke leverancier zou stellen.

Vergelijken zonder dat je de techniek begrijpt

Je hoeft geen ontwikkelaar te zijn om twee offertes naast elkaar te leggen. Je hebt alleen een andere meetlat nodig dan het eindbedrag.

Kijk welke van de twee je precies vertelt wat je krijgt. Kijk welke durft op te schrijven wat er niet in zit. Kijk hoe elk van beide omgaat met wijzigingen, want daar kom je gegarandeerd terecht. En kijk of iemand iets heeft opgeschreven over het probleem dat je wilde oplossen, of dat de offerte alleen jouw wensenlijst terugkaatst met bedragen erachter.

De goedkoopste offerte is vaak degene met de minste details, simpelweg omdat er minder in is meegerekend. Dat verschil komt later terug, alleen dan heet het meerwerk.

Heb je een offerte liggen waar je niet helemaal uit komt, leg hem me dan eens voor. Ik zeg je wel waar ik vragen bij zou stellen, ook als het werk uiteindelijk bij iemand anders terechtkomt.