Wat kost het onderhoud van maatwerk software per jaar?

Introductie

De vraag wat maatwerk software kost om te bouwen krijgt veel aandacht in offertes en boardrooms. De vraag wat het kost om te onderhouden krijgt veel te weinig, terwijl die over de levensduur van een systeem vaak zwaarder weegt dan de eerste bouwfase. Software is geen product dat je eenmalig koopt en daarna vergeet. Het is meer als een gebouw: zonder onderhoud gaat de kwaliteit achteruit, ook als je niets aan de functionaliteit verandert.

In dit artikel geven we een eerlijk beeld van onderhoudskosten, zonder de cijfers mooier te maken dan ze zijn. We schrijven dit vanuit onze praktijk bij MG Software in Haarlem, waar we zowel nieuwe systemen bouwen als bestaande applicaties beheren via vaste retainers. Wil je een eerste indicatie voor je eigen situatie? Onze calculator geeft een bandbreedte, en hieronder lees je waar die vandaan komt en hoe je onderhoud structureel plant.

Waarom onderhoud geen optie is maar een gegeven

Maatwerk software draait nooit op zichzelf. Het leunt op tientallen externe bibliotheken, een database, een hostingomgeving, een besturingssysteem en vaak koppelingen met systemen van derden. Al die onderdelen bewegen continu. Er verschijnen beveiligingsupdates, frameworks brengen nieuwe versies uit en API’s van leveranciers wijzigen endpoints of schakelen oude versies uit. Stilstand bestaat dus niet, ook niet als jouw functionaliteit gelijk blijft.

Dat sluit aan bij hoe de overheid digitalisering benadert: kritieke diensten moeten betrouwbaar blijven draaien terwijl de technologie eromheen verandert. De Digitale Overheid benadrukt dat beheer en doorontwikkeling structureel horen bij digitale voorzieningen, niet als incidentele klus achteraf. Hetzelfde geldt voor je eigen bedrijfsapplicatie: onderhoud is het werk dat je software meebeweegt met die veranderingen, van dependency-patches tot het meelopen met een gewijzigde boekhoud-API.

Het gevolg van stilstand is voorspelbaar. Een betaalkoppeling die vandaag werkt, kan over een jaar stoppen omdat de provider een oude API uitschakelt. Een library met een bekende kwetsbaarheid blijft in productie staan omdat niemand tijd heeft om te updaten. Onderhoud voorkomt dat soort verrassingen; het is geen luxe, maar de basisvoorwaarde om veilig door te kunnen opereren.

De vuistregel: 15 tot 20 procent per jaar

"Software die je niet onderhoudt wordt niet goedkoper. Hij wordt langzaam onveiliger, en uiteindelijk onhoudbaar."

— Jordan Munk, co-founder MG Software

In de software-industrie wordt vaak gerekend met 15 tot 20 procent van de oorspronkelijke bouwkosten per jaar voor onderhoud. Voor een applicatie die 50.000 euro kostte om te bouwen, kom je dan op grofweg 7.500 tot 10.000 euro per jaar aan ontwikkel- en beheerkosten, exclusief hosting. Dat is geen wet, maar een bruikbaar startpunt dat aansluit bij wat we in de praktijk zien bij portalen, dashboards en koppelingen.

Ook op macro-niveau blijft IT-budget een structurele post. Gartner verwacht wereldwijd groeiende IT-uitgaven, waarbij software en diensten een groot deel vormen. Dat bevestigt wat eigenaren van maatwerk vaak pas later merken: de eenmalige bouwkosten zijn het begin, niet het totaal.

De vuistregel is een gemiddelde, geen garantie. Een eenvoudige interne tool met weinig koppelingen zit eerder aan de onderkant. Een platform met meerdere integraties, veel gebruikers en strenge beveiligingseisen zit aan de bovenkant, en soms erboven in jaren waarin externe partijen grote wijzigingen doorvoeren. Het helpt om dit als een vast jaarlijks budget te zien, niet als een verrassing achteraf wanneer de eerste major upgrade van je framework voor de deur staat.

Wat onderhoud precies omvat

Onderhoud is meer dan af en toe een bug oplossen. Het omvat beveiligingsupdates van afhankelijkheden, het bijwerken van frameworks en bibliotheken, het meebewegen met API-wijzigingen van leveranciers, monitoring en alerting, back-upcontrole, en het oplossen van fouten die in productie naar boven komen. Daarnaast horen kleine verbeteringen bij die het dagelijks gebruik soepeler maken, zolang ze binnen de scope van "gezond houden" blijven.

Engineeringteams die op schaal draaien, behandelen dit als standaard discipline. Stripe beschrijft in Move fast without breaking things hoe geautomatiseerde tests, observability en gecontroleerde uitrol het verschil maken tussen snel itereren en productie-incidenten. Voor een mkb-applicatie hoeft dat niet op Stripe-niveau, maar de principes gelden wel: dependency-updates horen bij een vast ritme, niet bij "als er tijd over is".

Een vaak vergeten post zijn hostingkosten en externe diensten. Een gemiddelde zakelijke webapplicatie heeft maandelijkse kosten voor hosting, een database, e-mailbezorging, foutmonitoring en analytics. Die kosten zijn structureel en horen in je onderhoudsbegroting, niet in de eenmalige bouwkosten. Tel ze apart, zodat je niet denkt dat 15 procent "alles inclusief server" dekt.

Wat de kosten omhoog of omlaag drijft

Drie factoren bepalen grotendeels waar je in de bandbreedte valt. Ten eerste het aantal koppelingen: elke externe integratie is een onderdeel dat kan veranderen en dus onderhoud vraagt. Een portal met alleen login en eigen data is goedkoper te beheren dan een systeem dat praat met Exact Online, een CRM, een betaalprovider en een voorraadsysteem. Op onze pagina over software koppelingen en het API-koppelingen overzicht leggen we uit hoe die integraties het onderhoudsprofiel bepalen.

Ten tweede de gezondheid van de codebase. Een systeem met goede testdekking, heldere documentatie en een voorspelbare deploy-omgeving is goedkoper te onderhouden dan een ondoorzichtige codebase waar elke wijziging spannend is. Investeer in leesbare code en CI tijdens de bouw; dat betaalt zich terug in lagere onderhoudsuren.

Ten derde de leeftijd en keuze van de stack. Software die op moderne, breed ondersteunde technologie draait, is jarenlang goedkoop te onderhouden. Software op verouderde of niche-technologie wordt steeds duurder, omdat er minder ontwikkelaars zijn en updates lastiger worden. Loopt jouw systeem hier tegenaan, dan is onze pagina over legacy software moderniseren relevant: soms is gefaseerde herontwikkeling goedkoper dan jarenlang dure noodreparaties.

Onderhoud versus doorontwikkeling

Het loont om onderscheid te maken tussen onderhoud en doorontwikkeling. Onderhoud houdt het systeem gezond en veilig: patches, monitoring, kleine fixes en het meelopen met externe wijzigingen. Doorontwikkeling voegt nieuwe functionaliteit toe omdat je bedrijf groeit of verandert: een extra module, een nieuw rapport, een uitbreiding van je klantportaal. Beide zijn waardevol, maar als je ze op een hoop gooit, gebeurt er iets vervelends: zodra er even geen nieuwe features op de planning staan, valt ook het onderhoud stil.

Daarom werken wij vaak met een onderhoudsretainer met een vast aantal uren per maand voor beheer, en een apart budget voor nieuwe functionaliteit. Zo blijft de basis altijd gezond, ongeacht of er die maand nieuwe wensen zijn. In offertes scheiden we die posten expliciet, zodat finance begrijpt waarom "even niets nieuws bouwen" niet betekent dat de applicatie geen aandacht meer nodig heeft.

Bouw je een product dat blijft groeien, lees dan ook hoe we webapplicaties ontwerpen met onderhoud en doorontwikkeling in hetzelfde roadmap-model. De architectuurkeuzes in week een bepalen of jaar drie onderhoud voorspelbaar blijft of explodeert.

Wat gebeurt er als je niet onderhoudt

Niet onderhouden voelt op korte termijn als besparen. Op middellange termijn is het het tegenovergestelde. Technische schuld stapelt op, afhankelijkheden raken verouderd, en op een gegeven moment durft niemand nog een wijziging te maken omdat de gevolgen onvoorspelbaar zijn. Tegelijk groeien de beveiligingsrisico’s: bekende kwetsbaarheden in oude bibliotheken worden niet meer gedicht, terwijl aanvallers daar juist op jagen.

Het patroon herkennen we regelmatig bij applicaties die ooit snel live gingen en daarna "even geen budget" kregen. De eerste tekenen zijn klein: een trage deploy, een dependency die niet meer te updaten is zonder breuk, een koppeling die alleen nog via handmatige workarounds werkt. Het eindpunt is bijna altijd hetzelfde: een herbouw die vele malen duurder is dan structureel onderhoud zou zijn geweest.

Een paar duizend euro per jaar overslaan klinkt aantrekkelijk, totdat je drie jaar later voor de keuze staat om alles opnieuw te bouwen. Onderhoud is daarom geen kostenpost, maar een verzekering tegen een veel grotere uitgave. Wie dat moment bereikt, vindt op software herontwikkeling onze aanpak voor gefaseerde modernisering zonder wekenlang stilstand.

Lessen uit Haarlem: retainers in de praktijk

Bij MG Software in Haarlem beheren we meerdere maatwerkportalen en interne tools via vaste onderhoudsretainers. Een typisch voorbeeld: een klantportaal voor een dienstverlener in de regio Amsterdam, gekoppeld aan boekhouding en e-mail, met tientallen actieve gebruikers per week. Na livegang liep het eerste jaar op onderhoud ongeveer 12 procent van de bouwkosten. In jaar twee steeg dat naar 18 procent, niet omdat de code slecht was, maar omdat een externe API een major upgrade kreeg en we tegelijk de monitoring aanscherpten na een piek in verkeer.

Wat we daaruit meenemen: een retainer van acht tot twaalf uur per maand dekt voor veel mkb-applicaties de basis (dependency-updates, monitoring, kleine fixes en kwartaalreview). Piekjaren vragen een apart budget, bijvoorbeeld wanneer je framework een major release krijgt of wanneer een koppeling met Exact of een betaalprovider wijzigt. Klanten die onderhoud en doorontwikkeling gescheiden houden, hebben tot nu toe geen onplanned downtime gehad door verouderde dependencies.

Een retainer is geen SLA met 24/7-support voor elke klant, tenzij je dat expliciet afspreekt. Wel betekent het dat er elke maand iemand naar je systeem kijkt, dat security-updates niet maanden blijven liggen en dat je een vast aanspreekpunt hebt wanneer er iets schort. Dat verschil merk je vooral op de momenten waarop het wél misgaat: een failed deploy, een webhook die stilvalt, een certificaat dat verloopt.

Hoe je een onderhoudsbudget plant

Begin met een inventaris: welke afhankelijkheden, koppelingen en omgevingen heeft je applicatie? Noteer hosting, externe API’s, het aantal actieve gebruikers en of het systeem bedrijfskritisch is. Pas daarna de 15 tot 20 procent vuistregel toe op de oorspronkelijke bouwkosten, en tel hosting en SaaS-diensten erbij op.

Vraag je leverancier expliciet hoe onderhoud na oplevering is geregeld. Sommige bureaus leveren op en verdwijnen; anderen bieden een retainer of een overdrachtspakket met documentatie en monitoring. Zorg dat dependency-updates en security-patches in scope staan, niet alleen "bugfixes als we tijd hebben".

Wil je je cijfers toetsen? Gebruik onze calculator voor een bandbreedte op basis van scope en complexiteit, en plan een kort gesprek als je al bestaande software hebt die een health check kan gebruiken. Onderhoud begint het best vóór livegang, niet na de eerste storing.

Conclusie

Reken bij elk softwareproject vanaf het begin met onderhoud. Een goede vuistregel is 15 tot 20 procent van de bouwkosten per jaar aan beheer en kleine verbeteringen, met hosting en externe diensten apart begroot. Zie het niet als een onaangename verrassing, maar als de prijs van software die jarenlang betrouwbaar en veilig blijft draaien.

Wil je weten wat het onderhoud van jouw systeem realistisch kost, of beheer je nu software die wat aandacht kan gebruiken? Neem contact op met MG Software. We kijken eerlijk naar de staat van je codebase en stellen een onderhoudsplan of retainer voor dat past bij je budget en je koppelingen.