Wat kost softwareontwikkeling echt?

"Wat kost het om de software te bouwen?" is de verkeerde vraag, of op zijn minst het kleinste deel van de juiste. De bouw is de aanbetaling. De hypotheek is alles wat daarna komt: onderhoud, herwerk, incident response en de sluipende belasting van technical debt. Als je een budget afstemt op de oorspronkelijke ontwikkelofferte, dan budgetteer je voor een fractie van wat je daadwerkelijk gaat uitgeven. Dit artikel laat zien waar het geld werkelijk heen gaat en welke hefbomen het meetbaar verschuiven, onderbouwd met actuele branchecijfers in plaats van leveranciersoptimisme.

Diagram van de software development life cycle met de fasen build, test, deploy en onderhoud die de total cost of ownership bepalen

De bouw is het goedkope deel

De schattingen lopen uiteen, maar studie na studie komt uit op dezelfde ongemakkelijke conclusie: onderhoud en support, niet de oorspronkelijke bouw, vormen het grootste deel van de totale kosten over de softwarelevenscyclus. Veelgenoemde cijfers lopen uiteen van O'Reilly's "60/60-regel" (ongeveer 60 procent van de levenscycluskosten gaat naar onderhoud) tot latere schattingen van 75 procent en hoger, zonder één universeel geaccepteerd ijkpunt, omdat complexiteit en operationele context sterk verschillen (Software Maintenance Costs - 2024 Benchmark Overview).

Dit ene feit zou moeten veranderen hoe je elke ontwikkelofferte leest die op je bureau belandt. Een team dat snel oplevert maar broze, slecht geteste en ongedocumenteerde code achterlaat, is niet goedkoper. Het heeft de kosten simpelweg stroomafwaarts verschoven, weg van de bouwpost en naar je operationele budget, waar ze zich opstapelen. De software die het goedkoopst te bouwen is, is zelden de software die het goedkoopst in eigendom is.

Slechte kwaliteit is de verborgen vermenigvuldiger

De stroomafwaartse kosten zijn niet theoretisch. CISQ's analyse uit 2022 raamde de kosten van slechte softwarekwaliteit in de VS op minstens $2,41 biljoen, waarvan ruwweg $1,52 biljoen opgebouwde technical debt was, de kosten van het herwerken van suboptimale software (The Cost of Poor Software Quality in the U.S.: A 2022 Report). Het rapport benoemt als dominante kostendrijvers cybersecurityfalen, zwakke plekken in de toeleveringsketen van open-source-afhankelijkheden en niet-aangepakte technical debt, en maakt het punt dat voor budgettering het meest telt: deze kosten zijn grotendeels te voorkomen.

Voor teams in gereguleerde omgevingen en op grote schaal is dit geen abstractie. Elke shortcut die wordt genomen om een deadline te halen, wordt een regel in het herwerkbudget van volgend jaar, en in een gereguleerde context kan het ook een auditbevinding of een datalek worden. Wanneer je ontwikkelkosten inschat, kies je impliciet een kwaliteitsniveau, en die keuze bepaalt de omvang van de herwerkrekening die je later betaalt.

Wat "efficiënte delivery" werkelijk betekent

"Efficiënt" is een woord waar leveranciers van houden en dat ze zelden definiëren. DORA heeft het wel gedefinieerd, en de definitie is meetbaar. De vier metrics, lead time for changes, deployment frequency, change-failure rate en time to restore service, geven je een vocabulaire voor delivery-prestaties dat direct te vertalen is naar kosten. Het 2024 Accelerate State of DevOps report, gebaseerd op antwoorden van meer dan 39.000 professionals, vond dat slechts ongeveer 19 procent van de teams "elite"-prestaties bereikt: lead time onder een dag, on-demand deployment, een change-failure rate rond de 5 procent en herstel binnen een uur (Accelerate State of DevOps 2024 Report).

Die cijfers zijn een vermomd kostenmodel. Een team met een change-failure rate van 30 procent en een herstel van meerdere dagen betaalt voor dezelfde feature meerdere keren in rollbacks, hotfixes en brandjes blussen. Toewerken naar elite-prestaties is geen engineering-ijdelheid; het is de meest directe manier om de door herwerk gedreven kosten te verkleinen die de total cost of ownership domineren. Wanneer je een offerte beoordeelt, vraag dan waar het team staat op deze vier metrics. Het antwoord voorspelt je werkelijke uitgaven beter dan welk uurtarief dan ook.

AI verandert de rekensom, maar niet zoals je denkt

AI is in elk kostengesprek inmiddels onvermijdelijk. In het 2025 DORA report gebruikt rond de 90 procent van de practitioners AI in hun werk (State of AI-assisted Software Development 2025). De naïeve conclusie is dat coderen goedkoper werd, dus software goedkoper werd. De data zeggen iets anders.

DORA karakteriseert AI als een versterker: het verbetert de throughput maar vergroot de instabiliteit van delivery, en het rendement hangt volledig af van de kracht van het onderliggende systeem. De data uit 2024 waren onverbloemd over de afruil, met AI-adoptie die correleerde met een daling van 1,5 procent in throughput en een daling van 7,2 procent in stabiliteit, en 39 procent van de respondenten die weinig tot geen vertrouwen rapporteerde in AI-gegenereerde code (2024 DORA Report coverage, InfoQ). Bijna een derde van de practitioners in het rapport van 2025 zegt nog steeds AI-gegenereerde code niet te vertrouwen.

Vertaal dat naar budgettaire termen. AI kan tijd achter het toetsenbord besparen, maar als het code genereert die je engineers niet vertrouwen en je pipeline niet rigoureus verifieert, dan verschuift de besparing rechtstreeks naar QA, review, herwerk en onderhoud, precies de categorieën die de levenscycluskosten al domineren. AI zonder governance verlaagt je totale kosten niet; het verplaatst ze en legt er instabiliteit bovenop.

Platformen zijn de bewezen kostenhefboom

Als er één bevinding is die zou moeten bepalen waar je je geld inzet, dan is het deze. Het 2025 DORA report vindt dat 90 procent van de organisaties inmiddels een of andere vorm van intern developer-platform draait en 76 procent een toegewijd platform engineering-team heeft. DORA presenteert een sterk platform als de versterker die bepaalt of investeringen in AI en automatisering daadwerkelijk bedrijfswaarde opleveren, en de data uit 2024 lieten de grootste organisatorische winst toevallen waar interne platformen het sterkst zijn.

Dit is de inhoud achter de verder generieke bewering dat DevOps "kosten optimaliseert". Het specifieke mechanisme is dat automatisering, continue testing en een goed gebouwd intern platform een team naar elite-throughput en -stabiliteit bewegen, en weg van het herwerk dat technical debt aanjaagt. Een platform standaardiseert de paden naar productie, zodat kwaliteits-, security- en compliancecontroles standaard worden afgedwongen in plaats van per project erop geschroefd. Dat is wat de onderhoudscurve ombuigt, en daarom is het platform de plek met de grootste hefboom om in te investeren voordat je AI erbovenop schaalt.

Hoe je een softwareontwikkelofferte leest

Neem de bouwschatting en ga ervan uit dat de werkelijke kosten over tien jaar substantieel hoger liggen, met een zwaar accent op onderhoud en herwerk. Stel vervolgens drie vragen die dat grotere getal echt voorspellen. Waar staat dit team op de vier DORA-metrics? Is er een intern platform dat testing, security en compliance standaard afdwingt, of vindt elk project het pad naar productie opnieuw uit? En wordt AI-gebruik beheerst door review en geautomatiseerde verificatie, of jaagt het stilletjes de herwerkrekening op? Kostenoptimalisatie gaat niet over het vinden van de goedkoopste bouw. Het gaat over het minimaliseren van de vermenigvuldiger op alles wat daarna komt.