Software onderhoud uitbesteden — wat het kost en waarom het loont

Maatwerksoftware laten bouwen is voor de meeste bedrijven een bewust en goed afgewogen beslissing. De kosten worden berekend, de scope wordt vastgelegd, en na oplevering staat het systeem live. Wat daarna komt, wordt verrassend vaak niet gepland.

De veronderstelling — soms impliciet, soms uitgesproken — is dat software na oplevering "af" is. Dat het systeem gewoon blijft werken zolang niemand er iets aan verandert. Die veronderstelling klopt niet, en de consequenties van die misvatting worden pas zichtbaar op het moment dat het fout gaat.

Waarom software altijd onderhoud nodig heeft

Software bestaat niet in isolatie. Het draait op servers met een besturingssysteem dat updates krijgt. Het gebruikt externe bibliotheken die worden bijgewerkt, soms met brekende veranderingen. Het communiceert met externe diensten via API's die van versie wisselen. Het wordt benaderd via browsers die nieuwe standaarden implementeren en oude ondersteuning intrekken.

Drie categorieën onderhoud zijn structureel:

Beveiligingspatches en dependency-updates

In elke moderne webapplicatie zitten tientallen tot honderden open-source bibliotheken. Die bibliotheken worden doorlopend bijgewerkt — soms voor nieuwe functionaliteit, maar regelmatig ook voor het oplossen van beveiligingslekken. Een bibliotheek die vandaag veilig is, kan morgen een kritieke kwetsbaarheid hebben die actief wordt misbruikt.

De lijst van bekende kwetsbaarheden (de CVE-database) groeit wekelijks. Een systeem dat een jaar lang geen dependency-updates heeft gehad, heeft vrijwel zeker kwetsbaarheden waar aanvallers misbruik van kunnen maken. Dit is geen theorie — ransomware-aanvallen op MKB-bedrijven verlopen vaak precies via dit pad: een verouderde webapplicatie met een bekende kwetsbaarheid.

Framework- en platformdeprecaties

De frameworks waarop applicaties worden gebouwd, worden niet eeuwig ondersteund. Node.js brengt regelmatig nieuwe LTS-versies uit en depreceert oude. Python 2 is al jaren end-of-life, maar er draaien nog altijd productiesystemen op. PHP 7 verloor zijn officiële beveiligingsondersteuning in 2022.

Wanneer een framework end-of-life gaat, worden er geen beveiligingspatches meer uitgebracht — ook niet voor kritieke kwetsbaarheden. Een systeem op een verouderd framework is een systeem met een open raam.

Infrastructuur en cloud-omgeving

Servers, containers, databases en cloudservices vereisen doorlopend beheer. Schijven die vol raken, certificaten die verlopen (een verlopen SSL-certificaat maakt je website onbereikbaar voor browsers), databases die niet worden gevacuumd, logs die niet worden geroteerd. Dit zijn geen grote projecten — het zijn terugkerende onderhoudstaken die vervelende gevolgen hebben als ze te lang worden uitgesteld.

Wat onderhoud in de praktijk inhoudt

Een realistisch onderhoudscontract dekt doorgaans de volgende activiteiten:

Proactief onderhoud — Dependency-updates uitvoeren en testen, beveiligingsscans uitvoeren, performance-monitoring, loganalyse, back-ups verifiëren, certificaten verlengen. Dit is het onderhoud dat je nooit ziet, maar dat voorkomt dat je het later duur betaalt.

Reactief onderhoud (bugfixes) — Het oplossen van bugs die in productie worden ontdekt. Een goed onderhoudscontract definieert responsetijden per ernst: een kritieke bug (systeem staat plat) binnen 2 uur, een significante bug (kernfunctionaliteit werkt niet) binnen 1 werkdag, een lichte bug (cosmetisch of klein) binnen 1 week.

Kleine aanpassingen en verbeteringen — Tekst aanpassen, een nieuw exportformaat toevoegen, een extra veld in een formulier. Doorgaans valt een uur of minder werk per aanvraag binnen de grenzen van een retainercontract.

Monitoring en rapportage — Een goed bureau houdt proactief bij of het systeem beschikbaar is (uptime-monitoring), hoe snel pagina's laden, en of er foutmeldingen in de logs opduiken. Maandelijkse rapportage over de status van het systeem is een marker van een professioneel onderhoudsarrangement.

Kostenmodellen voor softwareonderhoud

Er zijn drie gangbare modellen:

Retainer

Een vaste maandelijkse vergoeding voor een afgesproken hoeveelheid uren en proactieve onderhoudstaken. De rekening is voorspelbaar. De relatie is continu: het bureau kent het systeem en hoeft zich niet elke keer opnieuw in te werken.

Gangbare tarieven: €1.500–€5.000 per maand, afhankelijk van de complexiteit van het systeem, het aantal uren dat is afgesproken, en de SLA-eisen (responsetijden, uptime-garanties).

Een retainer van €2.000 per maand klinkt als een significant bedrag. Maar voor een systeem waar medewerkers dagelijks in werken of waar klanten orders plaatsen, is het een kleine verzekering vergeleken met de kosten van een uur stilstand.

Time-and-materials

Je betaalt per gewerkt uur wanneer er onderhoud nodig is. Flexibel, maar onvoorspelbaar in kosten. En er is een fundamenteel probleem: proactief onderhoud wordt minder vanzelfsprekend. Als je alleen betaalt wanneer je belt, is de prikkel om proactief te handelen er niet.

Dit model werkt voor systemen met een zeer lage kritikaliteit en een laag volume aan wijzigingen. Voor productiesystemen die dagelijks worden gebruikt, is het onverstandig.

Vaste SLA met jaarcontract

Vergelijkbaar met een retainer, maar met meer formele afspraken over dienstverlening: expliciete uptime-garanties, gecertificeerde responsetijden, gedefinieerde escalatieprocedures. Dit is het model dat past bij systemen met hoge beschikbaarheidseisen — denk aan een webshop waarop omzet wordt gegenereerd, of een intern systeem waarop de hele operatie leunt.

Wat een SLA moet bevatten

Een Service Level Agreement is geen marketingdocument. Het is een contract met juridische consequenties. Controleer bij het beoordelen van een SLA de volgende punten:

Uptime-garantie. Hoeveel downtime is acceptabel? 99% uptime klinkt goed, maar betekent bijna vier uur downtime per maand. 99,9% is minder dan een uur per maand. 99,95% is het niveau dat je nodig hebt als continuïteit kritisch is. Vraag ook: over welke periode wordt uptime gemeten? Per maand is eerlijker dan per jaar (een storing van acht uur in januari telt in een jaargemiddelde nauwelijks mee).

Responsetijden per ernst. Wat wordt verstaan onder "kritiek", "significant" en "laag"? Wat is de eerste responstijd (wanneer hoor ik van jullie?) en de oplosingstijd (wanneer is het opgelost)? Dit zijn twee verschillende toezeggingen die in goede SLA's apart worden behandeld.

Reikwijdte. Wat valt er precies onder het contract? Security patches op de applicatie zelf, maar ook op de server? Monitoring van wat precies? Is een backup-herstel inbegrepen? Kleine feature-verzoeken — hoeveel per maand en wat is de definitie van "klein"?

Escalatieprocedure. Wie bel ik om 2 uur 's nachts als de webshop plat ligt? Is er een 24/7 bereikbaarheidsmogelijkheid voor criticals, of alleen op kantooruren? Dit is de vraag die de meeste onderhoudscontracten niet beantwoorden — totdat het nodig is.

Penaltystructuur. Wat gebeurt er als de SLA niet wordt gehaald? Creditering, verlenging van het contract, ontbinding? Een SLA zonder consequenties is een intentieverklaring, geen afspraak.

Het risico van geen onderhoudscontract

Stel: uw bedrijf heeft twee jaar geleden een webapplicatie laten bouwen voor €60.000. Het systeem werkt prima. Er is geen onderhoudscontract afgesloten — "dat zien we wel als er iets is". Het bureau heeft u de afgelopen zes maanden niet gesproken.

Dan gaat het op een dinsdagavond mis. De applicatie is onbereikbaar. Klanten kunnen niet inloggen. Orders stapelen zich op. U probeert het bureau te bereiken, maar buiten kantooruren is er niemand beschikbaar. De volgende ochtend om 9 uur spreekt u iemand — maar het bureau moet zich eerst weer inwerken in een systeem dat ze al maanden niet hebben aangeraakt. De diagnose kost een halve dag. De oorzaak blijkt een dependency die een brekende update heeft uitgebracht. De fix is een uur werk. De totale downtime: vierentwintig uur.

Dit scenario is niet hypothetisch. Het is een beschrijving van hoe de meeste spoedinterventies eruitzien. De kosten zijn: een dag omzetverlies, uren klantenservice-capaciteit, een spoedtarief bij het bureau, en reputatieschade die moeilijker te kwantificeren is.

Een retainer van €2.000 per maand had dit voorkomen.

Hoe u het gesprek met uw bureau voert

Softwareonderhoud is geen bijgedachte bij de oplevering van een project. Het is een beslissing die bij aanvang van een traject gemaakt moet worden. Vraag uw bureau bij de start van een project:

Wat is het standaard onderhoudsmodel dat jullie aanbevelen voor een systeem als dit?
Wat zijn jullie responsetijden buiten kantoortijd voor kritieke storingen?
Welk percentage van jullie klanten heeft een actief onderhoudscontract?
Hoe ziet een typische maandelijkse rapportage eruit?

Een bureau dat goed is in onderhoud, antwoordt direct en specifiek op deze vragen. Een bureau dat hier vaag over is, heeft onderhoud nog niet professioneel ingericht — en dat zult u voelen op het moment dat het er het meest toe doet.