AI Hiring

Maatwerksoftware laten maken: wat het kost en wat je vastlegt

Maatwerksoftware laten maken: wat het kost, wanneer een standaardpakket beter is, wat de branchevoorwaarden met je broncode doen, en hoe je wel eigenaar wordt.

aiworktalent Redactie · 5 september 2026 · 29 min leestijd

Maatwerksoftware laten maken is een van de weinige aankopen waarbij je vooraf niet kunt zien wat je krijgt en achteraf moeilijk kunt overstappen. De belangrijkste afspraken staan bovendien niet in de offerte, maar in de algemene voorwaarden. Deze post gaat over wat je vooraf niet ziet: wat het realistisch kost, wanneer je het beter niet doet, en wat die voorwaarden met je code, je gegevens en je rechten doen.

We bouwen zelf geen software en verkopen hier geen ontwikkeluren. Dat is precies waarom deze post begint met het hoofdstuk waarin staat wanneer je helemaal geen maatwerk moet laten maken.

Wanneer maatwerk juist niet moet

Het Adviescollege ICT-toetsing is een onafhankelijk bij wet ingesteld college. Op 7 april 2026 schreef het iets opvallend directs: "Maatwerk in het pakket zelf is sterk af te raden, zeker als dit voor rekening is van de opdrachtgever." Die laatste bijzin gaat over jou, want bij maatwerk betaal jij de rekening. Het advies zelf gaat over projecten van de rijksoverheid en niet over jouw bedrijf. De redenering geldt wel breder. Elke aanpassing in de kern van een pakket moet je bij elke nieuwe versie opnieuw laten meeverhuizen, en dat betaal je jaar na jaar.

Hetzelfde advies geeft de grens aan. Een standaardpakket past als de onderliggende processen grotendeels generiek zijn en aansluiten bij wat er in de markt gangbaar is. Wijken jouw processen daar wezenlijk van af, dan wordt maatwerk verdedigbaar. Moet er toch iets in het pakket zelf veranderen, dan is de eerste vraag of de leverancier dat in zijn eigen product wil opnemen.

Er staat nog een waarschuwing in die je bij offertes meteen kunt gebruiken. "Leveranciers prijzen soms iets aan als een standaardpakket, terwijl er toch veel configuratie en maatwerk nodig is." Laat een offerte daarom altijd in drieën splitsen. Wat is standaard, wat is instellen, en wat is echt bouwen? Die derde categorie bepaalt je risico, en die staat in veel offertes verstopt tussen de andere twee.

Het college noemt vijf dingen die een project beheersbaar houden. Kies op vooraf vastgelegde eisen, beperk maatwerk tot een minimum, rol stapsgewijs uit met momenten waarop je kunt stoppen, stuur je leverancier actief aan, en leg vooraf een vertrekplan vast. Die laatste twee worden bij mkb-projecten bijna altijd overgeslagen. Ze kosten vooraf een middag en achteraf soms je hele investering.

Vergelijk het ook met de tussenvormen. Veel gangbare mkb-pakketten breid je uit met losse uitbreidingen: je zet er iets naast in plaats van de kern te verbouwen. Bij low-codeplatformen betaal je per gebruiker per maand, en er gelden limieten op het aantal handelingen per dag. Dat kan prima werken, maar reken door wat het over vijf jaar kost bij het aantal gebruikers dat je dan verwacht. Herken je het gevoel dat je systeem je in de weg zit, dan is de vraag welk deel dat veroorzaakt vaak nuttiger dan de vraag wat een nieuw systeem kost. Het stappenplan voor AI in het mkb helpt om die vraag eerst scherp te krijgen.

Wat maatwerksoftware kost

Begin met het slechte nieuws: geen onafhankelijke Nederlandse bron publiceert wat een compleet maatwerkproject gemiddeld kost. Het Knab Zzp Uurtarievenboekje 2026 komt er nog het dichtst bij. Daarin werkt 22 procent van de zelfstandige softwareontwikkelaars ook met een projectprijs, en die ligt meestal tussen 5.000 en 10.000 euro. Zulke ontwikkelaars deden in 2025 gemiddeld drie van die projecten. Dat zijn dus afgebakende klussen van één zelfstandige, zonder analyse, koppelingen, migratie en nazorg eromheen. Op de eerste pagina met zoekresultaten staan verder uitsluitend bureaus die de dienst zelf verkopen. De bedragen die zij noemen lopen van 2.500 tot ruim 250.000 euro, een verschil van honderd keer. Eén bureau noemt 30.000 tot 200.000 euro, een ander belooft een vaste prijs in acht weken. Beide beloftes komen van de verkoper zelf.

Wat wel meetbaar is, is het uurtarief. Voor dat boekje vroeg Knab ruim 20.000 zelfstandigen naar hun tarief. Een zelfstandige softwareontwikkelaar rekent daarin gemiddeld 94 euro per uur exclusief btw. Een IT-consultant zit op 108 euro en een IT-architect op 115 euro. Over alle beroepen heen is het gemiddelde 83 euro, tegen 81 euro het jaar ervoor. Let op de kleine letters. De cijfers over omzet, winst en declarabele uren gaan alleen over zelfstandigen die minstens een jaar ondernemen en geen baan ernaast hebben. Bij de uurtarieven noemt Knab die beperking niet. Je weet dus niet of starters en parttimers daarin zijn meegeteld.

Die drie tarieven verklaren meteen waarom een offerte hoger uitvalt dan je op basis van "een programmeur" verwacht. Analyse en architectuur zitten er ook in, en die liggen vijftien tot ruim twintig procent boven het ontwikkelaarstarief. De Talent Monitor van HeadFirst Group en Intelligence Group kwam begin september 2026 uit op ongeveer 105 euro voor softwareontwikkelaars en 121 euro voor ontwerpers en beheerders van databases. Dat zijn gerealiseerde tarieven uit bemiddelde opdrachten, geen prijslijst. Let op wie er in dat cijfer zitten: zowel zelfstandigen als gedetacheerden. Bij detachering zit de marge van het bureau al in het tarief, dus leg die 105 euro niet naast de 94 euro van een zelfstandige.

Er is één openbare bron die geen belang heeft bij een hoog getal: de Handleiding Overheidstarieven 2026 van het ministerie van Binnenlandse Zaken. De rijksoverheid rekent daarin met een integrale kostprijs van 95 euro per uur voor schaal 11 en 107 euro voor schaal 12, inclusief overhead en exclusief btw. Die handleiding zegt er zelf bij: "Over het algemeen zijn tarieven van marktpartijen hoger, bijvoorbeeld vanwege aanvullende componenten in de overhead en/of winstopslagen." Een bureautarief boven de 107 euro is dus niet automatisch een afzetterij. Ter vergelijking: voor inhuur buiten raamovereenkomsten hanteert het Rijk in 2026 een maximum van 235 euro per uur exclusief btw.

Over budgetoverschrijdingen circuleren spectaculaire cijfers. Wees daar voorzichtig mee. Een veelgeciteerd onderzoek naar 1.471 ict-projecten vond een gemiddelde overschrijding van 27 procent, met één op de zes projecten die 200 procent uitliep. Alleen: 92 procent daarvan waren overheidsprojecten met een gemiddelde omvang van 167 miljoen dollar. Die steekproef gaat niet over jouw project, maar het risico verdwijnt daarmee niet. Een breder onderzoek onder 5.392 ict-projecten nuanceert dat gemiddelde, maar niet in jouw voordeel. Overschrijdingen en meevallers komen er ongeveer even vaak voor en de mediaan komt precies op de begroting uit. Tegelijk zijn de uitschieters zo extreem dat een gemiddelde overschrijding volgens de onderzoekers niet te berekenen valt. Hun eigen conclusie: ict-projecten zijn veel riskanter dan besluitvormers doorgaans aannemen. Klein betekent daarbij niet veilig. De onderzoekers splitsten hun projecten op grootte, en bij de kleine kwamen extreme uitschieters net zo vaak voor als bij de grote. De grootste overschrijding ten opzichte van de begroting zat op een kleine aanpassingsklus: begroot op 1.500 dollar, geëindigd op 425.000 dollar. De vraag is dus niet of je tien procent marge hebt, maar of je een uitschieter kunt dragen.

De praktische conclusie is dezelfde als bij elke uitbesteding: vraag geen prijs, vraag een urenraming per onderdeel. Analyse, bouw, koppelingen, testen, migratie van je bestaande gegevens, opleiding en de eerste maanden nazorg horen er allemaal apart in te staan. Een bedrag zonder uren vergelijkt niets, want de goedkoopste offerte is meestal gewoon de kleinste opdracht.

Wat er in de kleine lettertjes staat

Dit is het hoofdstuk dat je nergens anders vindt, en het is het duurste om over te slaan. Veel Nederlandse ict-leveranciers verklaren de branchevoorwaarden van hun brancheorganisatie van toepassing. De actuele versie daarvan zijn de NLdigital Voorwaarden 2025, gedeponeerd bij de rechtbank Midden-Nederland. NLdigital noemt ze zelf dé standaard voorwaarden voor de digitale sector. Op een lopend contract geldt de versie die daarin van toepassing is verklaard. Bij recente contracten is dat meestal de versie uit 2020; bij oudere kan het nog de Nederland ICT-, ICT~Office- of FENIT-voorwaarden zijn. Kijk dus eerst in je eigen overeenkomst, want de artikelnummers hieronder komen uit de versie van 2025.

Die voorwaarden zijn niet onredelijk, maar ze zijn wel geschreven vanuit de leverancier. Zet ze naast de inkoopvoorwaarden die de overheid gebruikt, en je ziet precies welke punten je zelf moet bedingen.

Twee dingen verdienen extra aandacht. Artikel 7.3 bepaalt dat de leverancier, ook ná een overdracht van rechten, de onderliggende ontwerpen en algoritmen mag hergebruiken en soortgelijke systemen voor anderen mag bouwen. Wil je exclusiviteit, dan moet je die apart afspreken. En de versie uit 2020 had nog een smalle uitweg. Stond in de schriftelijke overeenkomst uitdrukkelijk dat jij alle ontwerp- en ontwikkelkosten volledig en als enige droeg, dan golden er voor jou geen gebruiksbeperkingen. Betaald hebben was op zichzelf niet genoeg. Die bepaling staat niet meer in de versie van 2025.

Nog een detail dat veel ondernemers geruststelt terwijl het dat niet hoort te doen: het woord escrow komt in de tweeëntwintig pagina's van deze voorwaarden niet voor. "Wij hanteren de branchevoorwaarden" zegt dus niets over wat er met je broncode gebeurt als je leverancier omvalt.

Dit is geen reden om leveranciers te wantrouwen die met deze voorwaarden werken; het is de gebruikelijke gang van zaken en ze zijn openbaar in te zien. Het is wel de reden om ze te lezen vóór je tekent, en om de punten die je nodig hebt uitdrukkelijk in de opdracht te zetten. Afwijken mag altijd, maar alleen schriftelijk.

Wie eigenaar wordt van de code

Betalen voor de bouw maakt je nog geen rechthebbende. NLdigital schrijft dat zelf op: vaak wordt ten onrechte gedacht dat wie betaalt voor de softwareontwikkeling vanzelfsprekend de eigenaar is. De brancheorganisatie adviseert leveranciers om te licentiëren in plaats van over te dragen. Dat is hun goed recht, en het is precies waarom jij het gesprek moet openen.

De Auteurswet is per 1 januari 2026 gewijzigd. Sindsdien geldt dat je de overdracht van auteursrecht schriftelijk moet afspreken, en dat de levering in een akte moet gebeuren. Dat mag hetzelfde document zijn, als daarin staat dat het recht bij dat stuk overgaat. Een tweede papier is dus niet nodig. De oude tekst eiste alleen de akte. Een contractmodel dat nog op de oude tekst leunt, klopt dus niet meer. Ook als je leverancier een bv is, blijven beide eisen staan.

Twee routes waar mensen te veel van verwachten. De eerste is loondienst. Hoort het maken van dit soort werk bij de taken waarvoor je je medewerker betaalt, dan wijst artikel 7 jou als maker aan, tenzij jullie iets anders hebben afgesproken. Bij een ingehuurde zelfstandige gaat dat niet op, en bij een gedetacheerde of uitzendkracht evenmin: die is bij een ander in dienst, niet bij jou. De tweede is artikel 6, dat de opdrachtgever als maker aanwijst wanneer het werk naar zijn ontwerp én onder zijn leiding en toezicht tot stand is gekomen. Een wensenlijst aanleveren is daarvoor niet genoeg.

Software heeft in de Auteurswet bovendien een eigen positie, en die pakt voor de maker minder gunstig uit. Artikel 45n sluit het hele auteurscontractenrecht uit voor computerprogramma's. Daardoor mist een softwaremaker de beschermingen die een schrijver of fotograaf wel heeft. Denk aan een billijke vergoeding, een jaarlijkse opgave van de exploitatie, een bestsellerregeling, opzegging als het werk blijft liggen en vernietiging van onredelijke bedingen. Ook de gang naar de geschillencommissie is voor hem dicht. Voor jou als opdrachtgever betekent dat vooral één ding: bij software leunt alles op het contract. Reken er niet op dat de wet achteraf iets rechtzet.

Wat je wél altijd houdt, is een bodem. Artikel 45j bepaalt dat niemand je bij contract mag verbieden om fouten in je eigen software te herstellen, en om die te laden en in beeld te brengen. Je mag een reservekopie maken als dat nodig is, en je mag de software bestuderen en testen. Een recht op de broncode levert dat allemaal niet op. Zonder broncode kun je in de praktijk niets laten veranderen.

De uitzondering om software uit elkaar te halen helpt daar niet bij. Decompileren mag alleen om koppelingen met een ander programma mogelijk te maken, en wat je zo leert mag je niet gebruiken om zelf iets vergelijkbaars te bouwen. Het Europese Hof van Justitie oordeelde in 2021 dat het ook mag om fouten te herstellen, maar je contract mag daar voorwaarden aan stellen. Datzelfde arrest zegt erbij dat decompileren niet aan de orde is als je de broncode al via de wet of het contract kunt krijgen. Het levert bovendien meestal niet de originele broncode op, maar een derde versie. Het is een laatste redmiddel, geen noodplan.

Gaat je leverancier failliet, dan is het beeld genuanceerder dan vaak wordt verteld. Uit een arrest van de Hoge Raad uit 2018 volgt dat een curator een al verleende licentie niet zomaar kan intrekken. Maar een beëindigingsbeding in het contract of in de wet mag hij wel gebruiken, dus loop je opzegbepalingen na. En wat de curator zeker mag, is nog niet geleverde prestaties weigeren. Beloofd onderhoud, toegezegde updates en een nog niet overhandigde broncode worden dan een gewone vordering in het faillissement. Dat is in de praktijk hetzelfde als niets.

Daarom komt escrow ter sprake: een onafhankelijke partij bewaart de broncode en geeft die vrij als er gebeurt wat je vooraf hebt afgesproken. In Nederland bieden onder meer Software Borg, Escrow4all, Escrow Alliance, Softcrow en Codekeeper zoiets aan. Er is geen toezichthouder en geen register. De tarieven verschillen sterk en zijn slecht te vergelijken: één aanbieder publiceert 1.250 euro om te starten, 1.440 euro per jaar en 2.895 euro voor de eerste dag verificatie, exclusief btw. Een andere publiceert geen tarieven en verwijst naar een gesprek. Stel bij zo'n regeling twee vragen: wordt het depot gecontroleerd op volledigheid en bouwbaarheid, en is de leverancier zelf volledig rechthebbende op de code die hij deponeert? Zo niet, dan kan het depot juridisch leeg blijken. Bij maatwerk is het meestal eenvoudiger om vanaf dag één zelf eigenaar te zijn.

Let ten slotte op de open source in je maatwerk, want die zit er vrijwel zeker in. Draai je de software alleen intern, dan verplicht een GPL-onderdeel je tot niets. Verstrek je hem aan anderen, dan kan die licentie over het geheel gaan gelden. De AGPL gaat verder. Zit er een aangepast AGPL-onderdeel in en draait je software als webapplicatie, dan moet je iedere gebruiker de broncode van die aangepaste versie aanbieden. Dat je de software aan niemand verstrekt, helpt je hier dus niet. Of je eigen code meegaat, hangt ervan af of die er één programma mee vormt. Zulke onderdelen zijn in een gangbare stack de uitzondering, maar je merkt het pas als je ernaar vraagt. Mildere licenties vragen ook iets terug, zoals het meeleveren van de licentie en het markeren van gewijzigde bestanden. Vraag daarom bij elke oplevering een actuele componentenlijst met de bijbehorende licenties, en zet die eis in het contract.

Meerwerk, acceptatie en de datum die geen deadline is

Eerst een misverstand uit de weg. Veel ondernemers denken dat een richtprijs wettelijk met hooguit tien procent mag worden overschreden, en dat een aannemer je vooraf op hogere kosten moet wijzen. Beide regels bestaan, maar ze staan in het bouwrecht. Software maken is naar Nederlands recht meestal geen aanneming van werk maar een opdracht, omdat er niets tastbaars ontstaat. Voor een softwareproject zegt de wet dit: spreek je geen prijs af, dan betaal je wat daarvoor gebruikelijk is. Bestaat er geen gebruikelijke prijs, dan betaal je een redelijk bedrag. Een maximumpercentage staat er niet in.

Wat de wet wel geeft, is een norm: de opdrachtnemer moet de zorg van een goed opdrachtnemer in acht nemen. Een rechtbank vertaalde dat voor software naar het handelen van een redelijk bekwaam ict-deskundige. Daar hoort bij dat hij je begrijpelijk informeert over de voortgang en let op mijlpalen en kosten. Maar dat jij iets anders had verwacht, is op zichzelf geen grond voor een claim.

Werk je op uurbasis zonder afgesproken eindresultaat en zonder urenplafond, dan betaal je in beginsel alle uren. Ook het herstellen van een tegenvallend resultaat betaal je dan gewoon door. In een zaak uit 2014 eiste een opdrachtgever zijn geld terug en verloor: hij moest 82.647,84 euro aan de leverancier betalen, plus ruim veertienduizend euro aan kosten, en al zijn tegeneisen werden afgewezen. Twee dingen braken hem daar op. Hij gaf geen enkele technische analyse van wat er mis was, en hij kreeg geen technische documentatie omdat de FENIT-voorwaarden van zijn leverancier die alleen bij een uitdrukkelijke afspraak beloofden.

Acceptatie is de tweede plek waar het misgaat. Loop je de afgesproken acceptatieprocedure niet helemaal af, dan kun je je leverancier meestal niet rechtsgeldig in gebreke stellen. Een rechter kan dat gebrek passeren, maar alleen als je leverancier echt tekortschoot én er meer aan de hand is. In een zaak uit 2013 ontbraken een ondertekend gebrekenoverzicht en een finale acceptatietest. De opdrachtgever eiste bijna 1,7 miljoen euro terug en werd zelf veroordeeld tot betaling van 696.227,15 euro.

De branchevoorwaarden maken die procedure heel concreet, en niet in jouw voordeel. Spreek je geen acceptatietest af, dan geldt de software bij aflevering al als geaccepteerd, met alle zichtbare en onzichtbare fouten. Wat je dan nog overhoudt, is de garantie. Meld je een fout meteen, en in elk geval binnen drie maanden na aflevering, schriftelijk en gedetailleerd, dan moet je leverancier zich inspannen om die te herstellen. Bij een vaste prijs is dat gratis; heb je geen vaste prijs afgesproken, dan mag hij zijn gebruikelijke tarief rekenen. Meld je later, dan vervalt die plicht helemaal. De testperiode duurt veertien dagen en je mag de software dan niet in productie gebruiken; doe je dat toch, dan geldt hij op dat moment als geaccepteerd. Een fout is bovendien alleen het substantieel afwijken van schriftelijk overeengekomen specificaties, en je moet die kunnen aantonen én herhalen. "Het ziet er niet uit" is uitdrukkelijk geen geldige reden om acceptatie te weigeren. Werk je agile, dan aanvaard je het eindresultaat zoals het aan het einde van de laatste fase is, zonder de normale acceptatietest en zonder die drie maanden garantie.

Meerwerk is de derde. Onder de branchevoorwaarden hoef je extra werk alleen te vergoeden als jij erom hebt gevraagd of er vooraf mee hebt ingestemd. Schriftelijk hoeft die instemming niet: mondeling ja zeggen telt ook. De leverancier rekent dan de tarieven die jullie hebben afgesproken; pas als die er niet zijn geldt zijn gebruikelijke tarief. Je mag daar strengere afspraken over maken, en dat werkt. In een zaak uit 2022 hield één zin in de inkoopvoorwaarden stand: meerwerk komt pas voor vergoeding in aanmerking na schriftelijke instemming van de opdrachtgever. Een meerwerkvordering van 137.362,50 euro sneuvelde daarop. Tegen de leverancier telde mee dat hij het werk niet op verzoek maar uit eigen beweging had gedaan. Let wel: zo'n clausule is niet absoluut. De leverancier probeerde er via de redelijkheid en billijkheid onderuit te komen, maar de lat daarvoor is hoog en hij haalde die hier niet.

Tot slot de planning. Een go-livedatum in een projectplanning is niet automatisch een harde deadline. Wil je een datum kunnen afdwingen, benoem hem dan in het contract uitdrukkelijk als fatale termijn. En besef dat het ook aan jouw kant kan liggen: een rechtbank stelde vast dat een leverancier niet verantwoordelijk is voor veranderende beleidskeuzes van de opdrachtgever. Verander je halverwege van koers, dan is dat jouw risico. In een grote zaak uit 2017 kon de rechtbank bij geen van beide partijen aanwijzen waardoor het project was mislukt. De leverancier eiste ruim 22,7 miljoen euro, de opdrachtgever 14,3 miljoen terug, en beiden kregen vrijwel niets.

Na de oplevering: software heeft een houdbaarheidsdatum

Voor het onderhoudspercentage van tien tot twintig procent van de bouwsom dat overal circuleert, hebben wij geen onderbouwing kunnen vinden. Zet daarom een kalender in je begroting in plaats van een percentage. Dat kan, want de makers van de onderdelen waarop je software draait publiceren zelf hun einddatums. Het Nationaal Cyber Security Centrum adviseert die datums vooraf te controleren en te kiezen voor versies met langdurige ondersteuning.

Ook de bouwstenen daarboven hebben zo'n klok. Het veelgebruikte PHP-raamwerk Laravel geeft elke versie achttien maanden bugfixes en twee jaar beveiligingsfixes; versie 11 kreeg in maart 2026 zijn laatste fix. Dit zijn geen bijzondere gevallen, het is de normale gang van zaken. Vraag daarom vóór de bouw op welke versies je leverancier bouwt en tot wanneer die worden ondersteund. Dan weet je in welk jaar er hoe dan ook een rekening komt, en kun je die inplannen in plaats van hem te ondergaan.

Er zit ook wetgeving achter. De Europese verordening over de cyberweerbaarheid van producten met digitale elementen eist een ondersteuningsperiode van minstens vijf jaar, of zoveel korter als het product meegaat. Ook moet een product worden geleverd met de einddatum van die ondersteuning erbij, plus instructies om het veilig uit te faseren en gebruikersgegevens te wissen. Die verordening geldt volledig vanaf 11 december 2027.

Denk daarnaast na over waar je software draait en op wiens naam dat staat. Bij een .nl-domeinnaam mag alleen de geregistreerde houder wijzigingen laten doorvoeren. Staat je bureau als houder geregistreerd, dan beslist dat bureau. Bij een clouddienst geldt sinds 12 september 2025 de Europese dataverordening. Vanaf 12 januari 2027 mag een clouddienst niets meer rekenen voor het overstappen, ook niet voor het meegeven van je gegevens; de Autoriteit Consument en Markt houdt daar toezicht op. Twee kanttekeningen. Je krijgt je gegevens terug, niet je functionaliteit. En er is een uitzondering die op maatwerk is geschreven. Die geldt als het merendeel van de belangrijkste functies speciaal voor jou is gemaakt, of als alles voor jou alleen is gebouwd. Voorwaarde is wel dat de aanbieder die dienst niet op grote schaal in zijn catalogus verkoopt. Valt jouw dienst eronder, dan hoeft de aanbieder het overstappen niet gratis te doen. De overige overstapregels blijven wel gelden, en hij moet vóór het tekenen melden welke regels wegvallen.

Dat overstappen in de praktijk moeilijk is, blijkt uit een enquête die de ACM in april 2026 publiceerde onder 420 zakelijke cloudgebruikers, vooral uit het mkb. Ruim 61 procent was nog nooit overgestapt, en van wie het probeerde lukte het ongeveer drie op de tien niet. Zet daarom nu al in je contract wat je bij een vertrek in handen krijgt. Dat zijn je gegevens in een bruikbaar bestandsformaat, een beschrijving van het datamodel, en documentatie die zowel de software als de gemaakte instellingen beschrijft. In de gemeentelijke inkoopvoorwaarden staat dat zo uitgewerkt, inclusief een exit-plan dat partijen op verzoek opstellen en tussentijds mogen oefenen. Je mag hetzelfde vragen.

Wat de wet van jou vraagt, niet van je bouwer

Sinds 15 augustus 2026 geldt de Cyberbeveiligingswet, die de Wet beveiliging netwerk- en informatiesystemen vervangt. Volgens het Nationaal Cyber Security Centrum ben je er groot genoeg voor zodra je vijftig of meer medewerkers hebt, gerekend in fte. Heb je er minder, dan tel je pas mee als je jaaromzet én je balanstotaal allebei boven tien miljoen euro liggen. Je moet daarnaast in een aangewezen sector zitten. Dat is breder dan veel ondernemers denken: bijlage 2 noemt onder meer post en koeriers, afval, chemie, voedselgroothandel en -industrie, en een afgebakend deel van de maakindustrie. Daarbij gaat het om medische hulpmiddelen, computers, elektronica en optiek, elektrische apparatuur, machines, apparaten en werktuigen, motorvoertuigen en andere transportmiddelen. Maak je iets anders, bijvoorbeeld metaal, kunststof, meubels of textiel, dan valt dat er niet onder. Tel je omvang mee volgens de Europese regels, inclusief partner- en verbonden ondernemingen, en niet alleen je eigen bv.

Val je eronder, dan raakt dat je softwareproject rechtstreeks. De wet eist dat je de beveiliging van je toeleveringsketen regelt, en noemt daarbij met zoveel woorden de veilige ontwikkelingsprocedures van je leverancier. In een apart onderdeel eist zij ook beveiliging bij het verwerven, ontwikkelen en onderhouden van je eigen netwerk- en informatiesystemen. Het Cyberbeveiligingsbesluit noemt daar het verwerven van software, hardware of diensten uitdrukkelijk bij. Het bestuur moet de maatregelen bovendien zelf goedkeuren; dat kun je niet doorschuiven naar je ict-partij. Bij een ernstig incident meld je binnen 24 uur een eerste waarschuwing, binnen 72 uur een eerste beoordeling en uiterlijk een maand later een eindrapport.

Belangrijk voor je contract: het Nationaal Cyber Security Centrum schrijft dat een toezichthouder geen toezicht houdt op toeleveranciers. De organisatie die zelf onder de wet valt, is aanspreekbaar. Je kunt de eisen dus niet naar je bouwer doorschuiven met een verwijzing naar de wet; je moet ze in de opdracht zetten. Beheert of host je bouwer de software ook, dan kan hij overigens zelf onder de wet vallen, want beheerde diensten staan er als aparte categorie in.

Er komt nog een datum aan die dichterbij is dan de meeste. De Europese verordening over cyberweerbaarheid legt de maker vanaf 11 september 2026 een meldplicht op, ook voor producten die er dan al zijn: een kwetsbaarheid die actief wordt misbruikt, moet hij snel melden. Die plicht ligt dus bij je bouwer, maar hij kan hem alleen nakomen als iemand je software in de gaten houdt. Spreek dus vóór de bouw af wie dat doet en hoe je diegene buiten kantooruren bereikt. Diezelfde verordening verplicht makers ook een softwarestuklijst op te stellen, maar pas vanaf 11 december 2027. Dat is een machineleesbaar overzicht dat wettelijk alleen de bovenste laag hoeft te bevatten: de onderdelen die je software rechtstreeks gebruikt. Openbaar maken hoeft ook niet. Is je software vóór die datum opgeleverd, dan geldt de eis pas na een ingrijpende wijziging. Vraag die lijst daarom nu al contractueel op bij elke oplevering, en spreek af dat alle onderdelen erin staan, ook de lagen eronder.

Let bij maatwerk op één uitzondering in die verordening. Bij software die voor één zakelijke klant wordt gemaakt, mag de maker afwijken van twee eisen: de veilige standaardinstelling en gratis beveiligingsupdates. Dat mag alleen als beide partijen daar uitdrukkelijk mee instemmen. Kom je zo'n bepaling in een contract tegen, lees hem dan goed voordat je tekent.

Komt je bouwer bij je persoonsgegevens, doordat hij host, beheert, gegevens migreert of met echte data test, dan sluit je met hem een verwerkersovereenkomst. De Autoriteit Persoonsgegevens noemt die verplicht en houdt beide partijen aansprakelijk als hij ontbreekt. Zet erin dat je bouwer niet zomaar andere partijen mag inschakelen, vraag om een lijst van wie hij inschakelt, en leg vast dat hij persoonsgegevens na afloop wist of teruggeeft. Die laatste afspraak is ook je verzekering bij een vertrek. Bouwt hij alleen, en komt hij hooguit bij toeval bij echte gegevens, dan hoeft die overeenkomst niet. Regel dan wel geheimhouding en strak toegangsbeheer, zodat het bij toeval blijft.

Bureau of zelfstandige, en wat er in je opdracht moet

Bij maatwerksoftware is deze keuze scherper dan bij een website, omdat er meer rollen in het spel zijn: analyse, bouw, gegevensmigratie, testen en beheer. Wie op uurtarief vergelijkt, vergelijkt daarom vaak het verkeerde. De vraag is niet wat een uur kost, maar wat je voor dat uur níet krijgt.

Wat de keuze eerlijk maakt, is een opdrachtomschrijving die voor allebei hetzelfde is. Zet deze punten erin, dan zijn twee offertes pas echt vergelijkbaar:

• Een urenraming per onderdeel. Analyse, bouw, koppelingen, migratie van je huidige gegevens, testen, opleiding en nazorg apart benoemd.
• Wie de rechten krijgt en wanneer ze overgaan. Schriftelijk, met een akte voor de levering, en met het voorbereidend materiaal er met zoveel woorden in.
• Levering van de broncode en de technische documentatie. In een vorm waarmee een andere ontwikkelaar de software kan wijzigen; dat is de toets die de rijksvoorwaarden hanteren.
• Hoe meerwerk wordt goedgekeurd. Alleen na jouw voorafgaande schriftelijke instemming, en met een verplichting om vroeg te waarschuwen.
• Een acceptatieprocedure met een einddatum. Inclusief wie tekent, wat er in het gebrekenoverzicht komt en binnen hoeveel dagen jij moet reageren.
• Een vertrekplan. Welke bestanden, accounts, gegevens en documentatie je krijgt als de samenwerking stopt, en tegen welk tarief.
• De versies waarop wordt gebouwd, met hun einddatum. Zo weet je vooraf wanneer de eerste verplichte onderhoudsronde valt.

Overweeg ook of het in één keer moet. Stapsgewijs uitrollen met momenten waarop je kunt stoppen, is het advies dat het Adviescollege niet voor niets herhaalt. Welk deel je het eerst laat bouwen, is dan de belangrijkste beslissing; het artikel over uitbesteden of zelf doen helpt om die keuze te maken. Gaat het vooral om koppelingen tussen systemen die je al hebt, lees dan eerst wat er misgaat bij het koppelen aan bestaande systemen. En twijfel je welke rol je eigenlijk zoekt, dan zet wat een AI automation engineer doet de functies naast elkaar.

Maatwerksoftware wordt zelden duur door het uurtarief. Het wordt duur door wat er niet is afgesproken: wie de rechten krijgt, of je de broncode meekrijgt, hoe meerwerk wordt goedgekeurd en wat je in handen hebt als de samenwerking stopt. Vraag de algemene voorwaarden op vóór je tekent, zet de zeven punten hierboven in je opdracht, en begin kleiner dan je van plan was. Weet je nog niet of je een zelfstandige of een team nodig hebt? Plaats je opdracht op aiworktalent en ontvang voorstellen van specialisten, zodat je de aanpakken naast elkaar kunt leggen voordat je kiest.