Softwareonderhoud Uitbesteden voor het MKB: SLA, Kosten en Checklist

Je hebt een applicatie laten bouwen, of een systeem al jaren draaien, en het werkt. Tot het niet meer werkt: een browser-update breekt de loginpagina, een leverancier stopt met een koppeling, een security-onderzoek stipt een verouderde library aan. Softwareonderhoud is het minst sexy deel van maatwerk-IT, maar het bepaalt of je investering na drie jaar nog levert. In dit artikel lees je waarom softwareonderhoud uitbesteden voor het MKB vaak verstandig is, welke soorten onderhoud er zijn, wat het kost en waar je op moet letten in het SLA.

Wat softwareonderhoud eigenlijk is

Softwareonderhoud is niet één ding. In de theorie (Lientz en Swanson, 1978) worden vier categorieën onderscheiden, en die verdeling helpt je begrijpen wat je koopt:

• Correctief onderhoud. Bugs oplossen die na oplevering ontdekt worden. Denk aan een berekening die verkeerd afrondt of een formulier dat crasht bij een specifiek karakter.
• Adaptief onderhoud. De software werkend houden in een veranderende omgeving: nieuwe browser, nieuw besturingssysteem, geüpdatete koppelingen, nieuwe versies van externe API's.
• Perfectief onderhoud. Verbeteringen aan performance, gebruikerservaring en onderhoudbaarheid. Nieuwe functies vallen hier ook onder.
• Preventief onderhoud. Proactief refactoren, updaten van dependencies, herzien van architectuur om toekomstige problemen te voorkomen.

Wat opvalt in het klassieke onderzoek van Lientz, Swanson en Tompkins uit 1978: 17,4 procent van het onderhoudseffort ging naar correctief werk, 18,2 procent naar adaptief en maar liefst 60,3 procent naar perfectief. De les: het meeste onderhoud is geen bugfixing. Het is doorontwikkeling en aanpassing aan een veranderende wereld.

Voor een MKB-bedrijf betekent dit dat een pure "we bellen alleen als iets stuk is" aanpak leidt tot verwaarlozing. Onderhoud gaat over doorontwikkeling, niet alleen brandjes blussen.

Waarom softwareonderhoud uitbesteden

Er zijn drie soorten redenen om softwareonderhoud niet zelf te doen: capaciteit, kennis en risico.

Capaciteit. Zelfs als je één developer intern hebt, is die persoon één punt van uitval. Vakantie, ziekte, vertrek: en jouw applicatie staat op de wachtlijst. Uitbesteden geeft je toegang tot een team en dus tot continuïteit.

Kennis. Softwareonderhoud vraagt naast de codebase kennis van security, dependency management, DevOps, browser-compatibiliteit, cloud-hosting en soms compliance. Die combinatie is voor een MKB-bedrijf zelden efficiënt om zelf op te bouwen. Uitbesteden koopt je een breder skillset.

Risico. Een verwaarloosde codebase wordt langzaam onbeheersbaar. Verouderde libraries met bekende kwetsbaarheden, versienummers die decennia achterlopen, technische schuld die zich opstapelt. Uitbesteden aan een partij die dat proactief bijhoudt, dekt dit risico af.

Zelf doen is niet fout, maar realistisch: voor de meeste MKB-bedrijven is 100 procent intern doen zelden houdbaar. Zie ook onze afweging van voordelen en nadelen van IT-uitbesteden.

Wat softwareonderhoud typisch kost

De brede regel voor maatwerk-software is dat je jaarlijkse onderhoudskosten kunt begroten op 15 tot 20 procent van de initiële ontwikkelkosten. Sommige bronnen noemen 10 procent als ondergrens, andere lopen op tot 25 procent inclusief hosting en licenties. Voor webapplicaties zie je vaak ranges van 15 tot 30 procent, omdat browser- en framework-updates daar sneller gaan.

Wat betekent dat concreet? Als je software 60.000 euro heeft gekost om te bouwen, reken dan op ongeveer 9.000 tot 12.000 euro onderhoud per jaar. Voor een 100.000-euro-project loopt dat op tot 15.000 tot 20.000 euro per jaar. En vanaf jaar drie zie je vaak een piek door verplichte grote refactor-slagen op verouderde delen.

Uurtarieven van Nederlandse ontwikkelaars voor onderhoud liggen ruwweg tussen 75 en 150 euro exclusief btw voor MKB-aanbieders, en 90 tot 175 euro voor nichebureaus of gespecialiseerde partijen. Buiten kantoortijden (nacht, weekend) rekenen partijen doorgaans anderhalf tot driemaal het reguliere tarief.

Ter oriëntatie op maatwerk-software zelf: wat maatwerk-software laten maken kost geeft een breder beeld.

Vaste prijs, uurtarief of pot met uren?

Voor softwareonderhoud zie je drie contractmodellen. Elk heeft eigen valkuilen.

Vaste prijs per maand of jaar. Je betaalt een vast bedrag voor een omschreven scope (bijvoorbeeld: patching, hosting, monitoring, X uur wijzigingswerk). Voordeel: voorspelbaar. Nadeel: onderhoud dat niet in de scope past, kost extra.

Pot met uren (prepaid uren). Je koopt bijvoorbeeld 40 uur per maand af, waar je alle soorten onderhoud uit haalt. Voordeel: flexibel. Nadeel: als je pot leeg is midden in de maand en er is een productie-issue, sta je onder tijdsdruk om een aanvullend budget te akkorderen.

Puur uurtarief zonder retainer. Je betaalt achteraf per gewerkt uur. Voordeel: geen minimum. Nadeel: geen prioriteit. Als je leverancier drukke klanten met vaste contracten heeft, val jij achteraan.

De meeste MKB-bedrijven zijn het best geholpen met een combinatie: een vast basisbedrag voor patching, monitoring en bereikbaarheid, plus een pot met uren voor daadwerkelijk ontwikkelwerk. Meer over het bredere plaatje in SLA voor IT-dienstverlening: welke afspraken moet je eisen.

Wat moet er in het SLA staan

Een goede SLA voor softwareonderhoud is meer dan "we reageren binnen 8 uur". De volgende punten horen erin:

• Reikwijdte. Welke applicatie(s), welke omgevingen (productie, staging), welke onderdelen (frontend, backend, koppelingen, hosting).
• Responstijden per prioriteit. P1 (productie down), P2 (kritieke functie kapot), P3 (hinderlijk), P4 (cosmetisch). En per prioriteit een reactietijd en een oplossingstijd. Reactie is niet hetzelfde als oplossing.
• Beschikbaarheid. Kantoortijden alleen of 24/7? De helft van de MKB-applicaties heeft geen 24/7 nodig, en dat scheelt fors in kosten.
• Onderhoudscadans. Hoe vaak worden dependencies bijgewerkt, security-patches uitgevoerd, back-ups getest?
• Rapportage. Maandelijks overzicht van gedane wijzigingen, uren, incidenten en tickets.
• Escrow of code-toegang. Wat gebeurt er met de broncode bij faillissement of contractbeëindiging? Een broncode-escrow-clausule beschermt je toegang.
• Exit-clausule. Wat kost het om over te stappen naar een andere partij? Wordt kennisdocumentatie meegeleverd?
• Change control. Hoe worden wijzigingen aangevraagd, geaccordeerd en gefactureerd?

Voor bedrijfskritieke systemen wil je bovendien een RTO/RPO in het SLA (Recovery Time Objective, Recovery Point Objective) en een geoefend uitwijkscenario. Meer daarover in het disaster recovery plan voor het MKB.

Onderhoud en security: waarom updates uitstellen duur is

De meest onderschatte kostenpost in softwareonderhoud is uitgesteld security-werk. Elke week dat je een kritieke library-update uitstelt, wordt je aanvalsoppervlak groter. Bekende kwetsbaarheden in populaire frameworks worden binnen dagen door aanvallers ingezet.

Preventief onderhoud dekt dit af. Concreet:

• Dependency-monitoring. Automatische scans (Dependabot, Snyk, Renovate) die kwetsbare libraries signaleren en updates voorbereiden.
• Patch-cadans. Kritieke patches binnen dagen, gewone updates in een maandelijkse cyclus.
• Framework-updates. Grotere versies (major) op geplande momenten, niet ad hoc.
• Security-testen. Periodieke code-scans en, voor bedrijfskritieke applicaties, een periodieke pentest.

Meer diepgang in wat is patchmanagement en waarom is het cruciaal en in de checklist voor cybersecurity in het MKB.

Wat je vaak ziet in de markt: leveranciers rekenen aparte tarieven voor "grote upgrades" (bijvoorbeeld een major-versie van je framework). Bij een goede partner zit dat bij het contract in, uitgevoerd in kleine slagen. Bij een reactieve partij krijg je periodiek een offerte voor een groot brok werk. Dat is een teken dat er te weinig preventief is gedaan.

Vendor lock-in: hoe je overstap-vrij blijft

Softwareonderhoud is een intieme relatie. Je leverancier kent de codebase, de architectuur, de historie. Dat is voor snelheid handig, maar het maakt overstappen lastig. Om lock-in te voorkomen:

• Broncode in escrow. Contractueel geregeld dat je bij faillissement of eenzijdige beëindiging toegang krijgt tot de code.
• Documentatie als deliverable. Systeemdocumentatie, architectuurschets, deploy-instructies en runbooks horen bij het contract, niet als afhankelijkheid van één persoon.
• Standaardstack. Software gebouwd op mainstream frameworks en talen is over te dragen. Een exotisch framework of een eigen ontwikkelplatform is een lock-in.
• Eigenaarschap infrastructuur. Als de hosting en accounts (cloud-provider, domeinen, DNS) op naam van jouw bedrijf staan, blijf je in controle. Als alles op naam van de leverancier staat, ben je afhankelijk.

Zie ook onze checklist voor het kiezen van een IT-partner, waar dezelfde principes gelden.

Wanneer softwareonderhoud uitbesteden niet slim is

Om eerlijk te blijven: niet elke situatie vraagt om uitbesteding. Uitbesteden is ongunstig als:

• Je software binnen een jaar wordt vervangen door een pakketapplicatie of SaaS. Dan is beperkt intern doorschuiven vaak goedkoper.
• Je een sterk intern developmentteam hebt met specialisten die de codebase al kennen.
• De applicatie zo kritiek en zo specifiek is dat je een leverancier alleen in dienst kunt hebben, en de kosten daarvan de meerwaarde van uitbesteden opvreten.

Voor de meeste MKB-bedrijven wegen de argumenten juist door in het voordeel van uitbesteden. Zeker als je alternatief "we bellen wanneer het stukgaat" is.

Veelgestelde vragen over softwareonderhoud uitbesteden

Wat kost softwareonderhoud gemiddeld per jaar? Voor maatwerk-software is de gangbare richtlijn 15 tot 20 procent van de initiële ontwikkelkosten per jaar. Sommige bronnen noemen 10 procent als ondergrens; voor webapplicaties zie je ranges van 15 tot 30 procent. Voor een applicatie van 60.000 euro betekent dat ongeveer 9.000 tot 12.000 euro per jaar. Complexiteit, koppelingen en gewenst serviceniveau bepalen waar je in die range uitkomt.

Wat is het verschil tussen preventief en correctief softwareonderhoud? Correctief onderhoud is het oplossen van bugs die na oplevering worden ontdekt. Preventief onderhoud is proactief werk om toekomstige problemen te voorkomen: dependency-updates, refactoring, security-patches, monitoring-verbeteringen. Bedrijven die veel correctief werk hebben, hebben vaak te weinig preventief werk gedaan.

Wat hoort minimaal in een SLA voor softwareonderhoud? Reikwijdte, prioriteitsniveaus met responstijden en oplossingstijden, beschikbaarheid (kantoor of 24/7), onderhoudscadans voor patches en dependencies, maandelijkse rapportage, een broncode-escrow-clausule, een exit-clausule met documentatie-overdracht, en een change-control-proces.

Kan ik softwareonderhoud combineren met werkplekbeheer bij dezelfde partij? Ja, en het heeft voordelen: één aanspreekpunt, gedeeld inzicht in incidenten en compliance. Nadeel is dat je meer afhankelijk wordt van één leverancier. Voor bedrijfskritieke maatwerk-software is een specialistische ontwikkelpartij vaak beter, terwijl generiek beheer bij een gecombineerde IT-partner kan blijven.

Hoe voorkom ik vendor lock-in bij softwareonderhoud? Zorg dat de broncode in escrow zit, dat de documentatie een contractuele deliverable is, dat de software gebouwd is op mainstream technologie, en dat cloud-accounts, domeinen en DNS op naam van jouw bedrijf staan. Zo blijf je in controle en houd je de overstap-optie realistisch.

Waarom lopen onderhoudskosten vaak op na jaar drie? Omdat er dan grotere refactoring-slagen nodig zijn (major-versies van frameworks, gedateerde koppelingen, verouderde architectuur), en omdat de codebase in complexiteit is toegenomen door drie jaar wijzigingen. Een leverancier die preventief onderhoud goed doet, spreidt die kosten en voorkomt piekfacturen; een reactieve leverancier laat de piek juist in jaar drie of vier vallen.

Conclusie

Softwareonderhoud uitbesteden is voor de meeste MKB-bedrijven verstandiger dan zelf doen: het levert continuïteit, breder skillset en een gestructureerde aanpak van preventief werk. Begroot ruwweg 15 tot 20 procent van de bouwkosten per jaar, verwacht een piek rond jaar drie, en tuig een SLA op met duidelijke prioriteitsniveaus, escrow, exit-clausule en preventieve cadans.

TRON Group werkt als software-engineering-partner met MKB-bedrijven aan onderhoud dat verder gaat dan brandjes blussen: patch-cadans, dependency-monitoring, geplande upgrades en heldere rapportage. Wil je weten of jouw contract nog passend is of wat een goed onderhoudsplan voor jouw applicatie zou kosten? Bel voor een vrijblijvend gesprek naar 085-3035869 of neem contact op via de site. Moving IT Forward, ook nadat de eerste release live is.