Vaste prijs of uurtarief in softwareontwikkeling: waarom wij voor vast kozen

Huurt u een bureau in voor softwareontwikkeling, dan is een van de eerste dingen die u onderhandelt hoe u betaalt. De twee dominante modellen zijn facturatie op uurbasis — u betaalt voor bestede tijd — en een vaste prijs, waarbij u een totaalbedrag afspreekt voordat het werk begint.

De meeste bureaus kiezen standaard voor uurbasis. Wij kozen voor een vaste prijs. Dit artikel legt uit waarom, wat de werkelijke verschillen zijn en wat u zou moeten vragen voordat u een ontwikkelcontract tekent.

Het probleem met facturatie op uurbasis

Facturatie op uurbasis zorgt voor een scheve prikkel die u niet meer kunt negeren zodra u haar ziet.

Factureert een bureau per uur, dan verdient het meer naarmate het werk langer duurt. Dat betekent niet dat bureaus oneerlijk zijn — de meeste zijn dat niet — maar de structuur duwt de verkeerde kant op. Inefficiëntie wordt niet afgestraft. Uitdijende projectomvang is winstgevend. Er is geen prikkel om de eenvoudigste oplossing voor uw probleem te zoeken, want de ingewikkelde oplossing levert meer uren op.

Vanuit de klant bezien geeft facturatie op uurbasis onrust. Elke e-mail die u stuurt, elke vraag die u stelt, elke aanpassing die u vraagt is mogelijk declarabel. U gaat de communicatie rantsoeneren om de kosten te beheersen. U stelt geen vragen meer omdat u zich zorgen maakt over de factuur. De verhouding wordt tegengesteld, ook als beide partijen te goeder trouw handelen.

De maandelijkse factuur komt binnen en is altijd een verrassing — soms een aangename, vaak niet. U weet pas wat het totaal wordt als het project klaar is.

Waarom wij voor een vaste prijs kozen

Geven wij u een vaste prijs, dan doen wij een toezegging: wij leveren de afgesproken omvang voor dat bedrag, punt. Daarmee draait de prikkelstructuur volledig om.

Wij hebben er nu belang bij de meest efficiënte oplossing voor uw probleem te vinden, want efficiëntie beschermt onze marge. Wij hebben er belang bij vooraf helder te communiceren, want misverstanden kosten ons tijd die wij al hebben toegezegd. Wij hebben er belang bij op tijd te leveren, want een project dat uitloopt drukt onze winstgevendheid zonder die van u te verhogen.

U kent de totale kosten voordat wij één regel code schrijven. U kunt nauwkeurig budgetteren. U kunt uw directie een voorstel voorleggen met een echt bedrag. De verhouding tussen ons wordt samenwerking in plaats van transactie — wij willen allebei hetzelfde: een geslaagd project dat efficiënt wordt opgeleverd.

Hoe wij nauwkeurig begroten

Het meestgehoorde bezwaar tegen een vaste prijs is: ‘hoe kunt u zich vastleggen op een prijs voordat u precies weet wat u bouwt?’. Dat is een terechte vraag, en het antwoord is dat nauwkeurig begroten echt werk vooraf vergt.

Elk project dat wij aannemen begint met een grondige kennismaking. Wij vragen naar uw bedrijfsprobleem, niet alleen naar uw lijst met gewenste functies. Wij brengen uw processen in kaart, doorgronden uw gegevens, bekijken bestaande systemen en maken elke aanname expliciet. Wij stellen de vragen die de meeste bureaus overslaan, omdat zij per uur factureren en de onduidelijkheid later wel kunnen uitzoeken.

Daarna begroten wij intern — niet alleen de ontwikkeltijd, maar ook de complexiteit van koppelingen, de testinspanning, de eisen rond uitrol en een marge voor de dingen die er altijd zijn. U krijgt één bedrag. Geen bandbreedte. Geen ‘vanaf’. Eén vaste prijs voor een vastgelegde omvang.

Dat kost tijd. Een grondige kennismaking en begroting kan ons meerdere uren kosten voordat u een voorstel krijgt. Die kosten nemen wij voor onze rekening, omdat het de basis is van een kloppende vaste prijs — en omdat een goed begroot project een grotere kans van slagen heeft.

Wat er gebeurt als de omvang verandert

Een vaste prijs betekent niet dat de omvang bevroren is. Bedrijven veranderen, wensen ontwikkelen zich en tijdens de bouw ontstaan betere ideeën. Daar gaan wij eerlijk mee om.

Heeft u iets nodig dat niet in de oorspronkelijke omvang zat — een nieuwe functie, een andere koppeling, een aangepast proces — dan begroten wij dat apart. U krijgt een prijs voor de uitbreiding voordat wij eraan beginnen. U bepaalt of het dat waard is. Geen verrassingen, geen achteraf gefactureerde kosten voor besluiten die wij samen namen.

Wat wij niet doen: stilzwijgend een uitdijende omvang opvangen en aan het eind een verrassingsfactuur presenteren. En wij gebruiken ‘dat zat niet in de omvang’ niet als excuus om iets in rekening te brengen dat duidelijk in de oorspronkelijke opdracht besloten lag. Beide houdingen vernietigen vertrouwen. Zo werken wij niet.

De vraag wie het risico draagt

Wie in welk model het risico draagt is de helderste manier om het verschil tussen uurtarief en vaste prijs te begrijpen.

Bij facturatie op uurbasis draagt u het risico. Duurt het project twee keer zo lang als verwacht, dan betaalt u twee keer zoveel. Onderschat het bureau de complexiteit, dan draait u op voor die kosten.

Bij een vaste prijs dragen wij het risico. Schatten wij te laag in, dan vangen wij dat op. Duurt iets langer dan wij dachten, dan is dat ons probleem om op te lossen. U betaalt wat is afgesproken.

Dat is geen liefdadigheid — het is het model dat onze belangen op die van u afstemt. Wij hebben een sterke prikkel om nauwkeurig te schatten en efficiënt te leveren, want zo werkt een vaste prijs als verdienmodel. Werkt het goed, dan krijgt u voorspelbare kosten en een gemotiveerd bureau. Wij krijgen een rendabel project en een tevreden klant.

Wat u elk bureau zou moeten vragen voordat u tekent

Of u nu met ons werkt of met een ander bureau, dit zijn de vragen die blootleggen hoe de facturatie in de praktijk uitpakt:

Vraag wat er gebeurt als het project langer duurt dan geschat. Vraag hoe wijzigingen in de omvang worden afgehandeld en geprijsd. Vraag om voorbeelden van eindfacturen van eerdere projecten, afgezet tegen de oorspronkelijke offerte. Vraag hoe men omgaat met situaties waarin de oorspronkelijke opdracht onduidelijk was. De antwoorden zeggen u meer dan het facturatiemodel zelf.

Voorspelbaarheid is wat in een softwaretraject het zwaarst weegt. U hoort te weten wat u gaat betalen voordat u zich vastlegt.