Kort antwoord
Software laten onderhouden kost bij CleverTech AI 500 tot 750 euro per maand voor een draaiende MKB-applicatie, maandelijks opzegbaar; als vuistregel 10 tot 20 procent van de bouwsom per jaar, richting de bovenkant zodra er koppelingen onder hangen. Een overname loopt zelden stuk op die prijs maar op de sleutels: repository, hosting, domein, secrets en back-ups staan op naam van de vertrekkende partij, en een zip-bestand met code is geen overdracht. Regel daarom eerst de toegang, laat dan een code-audit uitvoeren en begroot stabilisatie eenmalig, apart van het maandbedrag. En leg de overdracht van het auteursrecht vast bij akte, want in Nederland is de maker rechthebbende — ook wanneer jij hebt betaald.
Van lezen naar doen.
Business Center Altena / HVS Trading (Henk Verhoeven)Multi-tenant Huurdersportaal met IoT-energiemonitoring
IoT + AIgeautomatiseerd meterstanden aflezen

Software laten onderhouden kost bij CleverTech AI 500 tot 750 euro per maand voor een draaiende MKB-applicatie, maandelijks opzegbaar.
Als vuistregel rekenen wij 10 tot 20 procent van de bouwsom per jaar: richting 10 procent zonder externe koppelingen, 15 tot 20 procent zodra er integraties onder hangen. Dit zijn onze eigen ranges, geen marktgemiddelden.
Die prijs is zelden waar een overname op stukloopt. De toegang wel.
Wie zijn softwarebureau kwijtraakt, mist meestal niet de kennis maar de sleutels: repository, hosting, domein en API-sleutels staan op naam van de vertrekkende partij, en een zip-bestand met code is geen overdracht.
Hieronder staat wat er wel en niet in onderhoud hoort, welke toegang je terug moet hebben voordat je tekent, wat een code-audit oplevert, welke schuld je erft en welke clausules dat allemaal afdwingbaar maken. Het bredere traject van bouwen tot beheren staat in onze complete gids over maatwerk software.
Wat valt er onder onderhoud, en wat niet
Onderhoud houdt je software veilig en werkend. Doorontwikkeling maakt hem beter, en dat is een aparte post op de begroting.
Het onderscheid klinkt vanzelfsprekend en is de meest voorkomende bron van ruzie na een overstap. Zet daarom in het contract welke van deze vier je afneemt.
| Wat je afneemt | Wat erin zit | Hoe het geprijsd wordt |
|---|---|---|
| Onderhoud | Monitoring, beveiligingsupdates, bugfixes, kleine aanpassingen | Vast bedrag per maand |
| Doorontwikkeling | Nieuwe schermen, nieuwe koppelingen, nieuwe functionaliteit | Afroepbudget tegen een vast uurtarief |
| Hosting en beheer | Servers, back-ups, certificaten, herstel na uitval | Per maand, vaak apart van het onderhoud |
| Stabilisatie | Het wegwerken van achterstand die je bij overname aantreft | Eenmalig, na een audit |
Ons onderhoudspakket van 500 tot 750 euro per maand bevat monitoring, beveiligingspatches, bugfixes en acht uur support per maand, met kleine doorontwikkeling daarbinnen. De bovenkant van die bandbreedte geldt voor grotere applicaties met koppelingen en een afgesproken responstijd.
Die vuistregel is een startpunt, geen formule; het werkelijke bedrag volgt vooral het aantal koppelingen. Een applicatie van 25.000 euro met drie koppelingen kost meer onderhoud dan een applicatie van 60.000 euro die volledig op zichzelf staat.
Reken de bouwsom zelf door met de bandbreedtes uit kosten maatwerk software, en tel daar het onderhoudspercentage bij op voordat je twee offertes vergelijkt.
De sleutelinventaris: wat je terug moet hebben voordat je tekent
Vraag niet om de broncode. Vraag om eigenaarschap van de accounts waarin de broncode, de servers en de sleutels staan.
Het verschil is groot. Een kopie van de code laat je een nieuwe partij lezen; eigenaarschap van de repository laat haar uitrollen.
Loop deze lijst punt voor punt af, met per regel een naam en een datum waarop de overdracht rond is.
| Sleutel | Waar het meestal staat | Waarom het klemt |
|---|---|---|
| Repository | GitHub, GitLab of Bitbucket van het bureau | Zonder eigenaarsrol geen historie, geen branches, geen rechten |
| CI/CD en deploy-rechten | Gekoppeld aan diezelfde repository | Zonder deploy kan niemand een fix live zetten |
| Hosting en servers | Account van het bureau bij de hoster | Facturatie stopt, de server stopt mee |
| Domein en DNS | Registrar-account van het bureau | Mailverkeer en certificaten hangen eraan |
| Secrets en API-sleutels | Betaalprovider, boekhoudpakket, mailserver | Sleutels die meeverhuizen zonder rotatie blijven bij de oude partij werken |
| Database en back-ups | Bij de hosting, soms bij een derde | Een back-up die je niet kunt terugzetten is geen back-up |
| Monitoring en foutmeldingen | Sentry, uptime-checks, logging | Zonder dit weet je pas van storingen als een klant belt |
| App-store-accounts | Developer-account van het bureau | Publiceren onder een vreemd account is later niet te herstellen |
| Betaalde componenten | Licenties op naam van het bureau | Verlopen licenties leggen functionaliteit stil |
Roteer elk gedeeld geheim op de dag van de overdracht, ook wanneer je in goede verstandhouding uit elkaar gaat. Sleutels die blijven staan zijn geen kwestie van vertrouwen maar van opruimen.
Twee punten worden structureel overgeslagen. Het domein staat verrassend vaak op naam van de bouwer, en de back-ups zijn zelden ooit teruggezet in een oefening.
Die tweede is te testen voordat je tekent: laat een herstel uitvoeren op een testomgeving. Hoe je dat inricht staat in disaster recovery plan MKB.
De code-audit voordat je ja zegt
Een code-audit is geen formaliteit maar een prijsbepaling. Hij beantwoordt drie vragen: wat is herbruikbaar, waar zit het risico, en wat kost overname.
Wij doen die audit eenmalig voordat we een bestaande applicatie in beheer nemen. Pas daarna noemen we een maandbedrag, omdat een maandbedrag zonder audit een gok is.
Waar een audit naar kijkt:
- Versiehistorie — is er versiebeheer, of zijn er losse backupbestanden met een datum in de naam?
- Testdekking — draait er iets geautomatiseerd, of is elke wijziging handwerk met risico?
- Afhankelijkheden — welke onderdelen zijn hun einde-support gepasseerd?
- Secrets in de code — staan wachtwoorden of sleutels hard in bestanden?
- Uitrolproces — is er een pijplijn, of wordt er via FTP in productie gewerkt?
- Waarneembaarheid — is er foutmonitoring, of merk je storingen pas via gebruikers?
Onderzoeken mag je sowieso. Artikel 45l van de Auteurswet geeft wie bevoegd is tot het laden en uitvoeren van een programma het recht tijdens die handelingen de werking waar te nemen, te bestuderen en te testen om de onderliggende ideeën en beginselen te achterhalen.
Dat is geen recht op de broncode zelf. Inzage in de code regel je in het contract, en zonder die inzage is een audit een blackbox-test.
Hoe zo een audit uitpakt, laat onze eigen overname van een Brits thuiszorgplatform zien. De applicatie was in bijna negen jaar gegroeid zonder versiebeheer, zonder geautomatiseerde tests en zonder gestructureerde foutmonitoring.
De gestructureerde audit bracht 21 defecten aan het licht, waarvan 2 kritiek en 11 hoog. Daaronder een facturatiefout die een live-in-tarief per boeking vermenigvuldigde, waardoor 875 pond per week als 6.125 pond werd aangeslagen.
Die fout stond er jaren en niemand zag hem, omdat er niets was dat hem kon zien. Het volledige verloop staat in de case legacy thuiszorg-platform gemoderniseerd.
Welke schuld je erft
Bij een overname koop je geen schone lei. Je koopt de optelsom van elke keuze die onder tijdsdruk is gemaakt.
Die schuld valt in vier soorten uiteen, en ze hebben elk een ander prijskaartje.
| Soort schuld | Hoe je het herkent | Wat het kost om weg te werken |
|---|---|---|
| Achterstallige updates | Onderdelen buiten support, openstaande kwetsbaarheden | Eenmalige inhaalslag, daarna maandelijks ritme |
| Ontbrekende tests | Elke wijziging vraagt handmatige controle | Structurele opslag op elk uur doorontwikkeling |
| Fragiele koppelingen | Koppelingen zonder time-out, retry of logging | Per koppeling herbouwen, niet repareren |
| Ontbrekende documentatie | Kennis zat in het hoofd van één developer | Inwerktijd die je hoe dan ook betaalt |
De eerste maanden na een overname gaan grotendeels op aan het werk dat de vorige partij niet deed. Dat is normaal, en het is geen reden om die partij zwart te maken.
Wel een reden om het apart te begroten. Stop stabilisatie niet in de maandelijkse onderhoudsprijs, want dan betaal je vijf jaar lang een inhaalslag die drie maanden duurde.
Achterstallige updates zijn daarbij de urgentste categorie, omdat ze niet stil blijven liggen maar actief risico opbouwen. Het ritme dat daarna nodig is staat in patch management MKB.
Een redelijke inwerkperiode
Reken op twee tot zes weken overlap waarin de oude partij bereikbaar is tegen een afgesproken uurtarief. Korter kan bij een kleine applicatie, langer is meestal een teken dat de documentatie ontbreekt.
Een overdrachtsvergadering is minder waard dan één begeleide uitrol. Laat de nieuwe partij een kleine wijziging doorvoeren en live zetten terwijl de oude meekijkt, want daar komt boven water wat geen enkel document vertelt.
Leg vier dingen vast voor die periode:
- Een einddatum waarop de oude partij klaar is, niet "voorlopig bereikbaar".
- Een wijzigingsstop op productie vanaf de dag dat de nieuwe partij begint.
- Een uurtarief en een maximum voor de vragen die tijdens de overdracht opkomen.
- Een opleveringslijst met code, data-export, documentatie en accounts, afgetekend per regel.
De koppelingen verdienen apart aandacht in die weken, omdat ze vaker breken dan de applicatie zelf. Wat daarbij komt kijken staat in api koppeling laten maken.
Wat je op papier zet
In Nederland is de maker rechthebbende, ook wanneer jij hebt betaald. Dat maakt de papieren kant van een overname bepalender dan de technische.
De Auteurswet bepaalt in artikel 2, derde lid, dat de overeenkomst waarmee auteursrecht wordt overgedragen schriftelijk wordt aangegaan, en dat de levering voor die overdracht bij akte geschiedt. Een zin in een offerte dat de code "van jou" is, is dus geen overdracht.
Er is één recht dat je hoe dan ook houdt. Artikel 45j bepaalt dat verveelvoudiging die geschiedt in het kader van het laden, het in beeld brengen of het verbeteren van fouten niet bij overeenkomst kan worden verboden.
Vertaald: zelfs met alleen een gebruiksrecht mag je fouten laten herstellen, door wie je wilt. Voor doorontwikkeling geldt dat niet, en dáár knelt een ontbrekende akte.
Ook nuttig bij overnames met koppelingen: artikel 45m staat het kopiëren en vertalen van de codevorm toe wanneer dat onmisbaar is om de interoperabiliteit van een onafhankelijk vervaardigd programma met andere programma’s tot stand te brengen, onder voorwaarden.
Vier clausules die het verschil maken bij de volgende overstap:
- Overdracht van het auteursrecht bij akte, niet een toezegging in de offerte.
- Een exitparagraaf met uitlevering van code, een data-export in gangbaar formaat en overdracht van accounts.
- Een opzegtermijn die bij het onderhoud past; maandelijks opzegbaar is voor MKB-onderhoud de gezonde norm.
- Een escrow-regeling voor bedrijfskritische software, zodat de code vrijkomt als de leverancier omvalt.
Welke afspraken je bij een nieuwe bouwopdracht vooraf vastlegt, staat in software ontwikkeling uitbesteden; hier gaat het om wat je achteraf nog kunt repareren.
Een escrow zonder verificatie is een archiefdoos met onbekende inhoud. Escrow Alliance onderscheidt vier niveaus, van een integriteitscontrole tot een volledige verificatie waarbij de consultant de stappen bij afgifte simuleert, en adviseert minimaal één keer per jaar niveau 3 of 4.
Wanneer overnemen geen goed idee is
Niet elke bestaande applicatie verdient een tweede leven. Drie situaties waarin doorgaan duurder is dan opnieuw beginnen.
Het draait op een eigen framework van de oude partij. Dan neem je geen software over maar een afhankelijkheid, en de enige partij die hem kent vertrekt net.
De functionaliteit past niet meer bij het proces. Dan betaal je maandelijks om software in stand te houden die je bedrijf van vier jaar geleden ondersteunt.
De stabilisatie loopt richting de herbouwprijs. Onze rescue-trajecten liggen op 15.000 tot 25.000 euro, tegenover 50.000 tot 75.000 euro voor volledig opnieuw bouwen; zodra een audit boven die eerste bandbreedte uitkomt, is de rekensom open.
Er is ook een vierde die vaker voorkomt dan je zou denken: een standaardpakket dat de leverancier voor jou heeft aangepast. Wat je dan overneemt is een aftakking die niet meer met updates meebeweegt, en een nieuwe partij erft een pakket dat ze niet kent.
Overnemen is dan alsnog verdedigbaar als tussenstap. Spreek het wel zo af: een jaar stabiel houden terwijl je de vervanging voorbereidt, niet vijf jaar hopen.
De afweging tussen doorgaan en vervangen is dezelfde als die tussen pakket en maatwerk, maar met sunk cost erbij. Het kader daarvoor staat in maatwerk software of standaardpakket.
Zo pak je het aan
Begin met de sleutelinventaris uit dit artikel, want zolang de toegang niet geregeld is, is elke offerte een schatting.
Vraag daarna een code-audit aan bij de partij die het onderhoud zou overnemen, en vraag om een uitkomst met drie posten: stabilisatie eenmalig, onderhoud per maand, doorontwikkeling per uur.
Leg tot slot de overdracht vast op één A4 met per regel een naam en een datum. Wat er niet op staat, wordt niet overgedragen.
Weet je nog niet wat jouw applicatie aan onderhoud zou moeten kosten? Reken het door met de prijsindicatie, of bekijk hoe wij bestaande software in beheer nemen op de pagina over maatwerk software.
Staat je software stil omdat niemand hem meer aanraakt? Neem contact op voor een code-audit, dan weet je binnen een paar weken wat overname kost en of het verstandig is.
Opgesteld met AI-ondersteuning, geredigeerd en inhoudelijk verantwoord door het Redactieteam CleverTech AI.








