[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fNzCJUy60coUYJezGueXYZqsAPtrjUfvskO7Py1QAVcQ":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":27,"hasDownload":28,"fileName":9,"youtubeId":27},"420","5D194478-0616-4642-8BFC-D0577CBDA297","8FB77283-8FB1-A247-851E-65269E8983E0","3434E0DD-DD9C-7048-9B98-536F3C5E867E","","how-to-prevent-dependency-on-one-supplier-or-developer","Hoe u afhankelijkheid van één leverancier of ontwikkelaar voorkomt","Vertrouwen op één enkele ontwikkelaar voor uw bedrijfskritische software is een serieus risico. Zo kunnen IT-specialisten de controle terugkrijgen en veerkracht opbouwen.","Uw kernbedrijfssysteem draait op een maatwerkapplicatie, en precies één persoon begrijpt het echt. Die developer heeft het gebouwd, kent elke workaround en heeft de sleutels in handen — en als hij of zij vertrekt, ziek wordt, of simpelweg de tarieven verhoogt, heeft u een serieus probleem. Dit artikel geeft IT-specialisten een concreet, uitvoerbaar plan om die afhankelijkheid te identificeren, structureel te verminderen en ervoor te zorgen dat het nooit meer sluipenderwijs terugkeert.\n\n## Waarom is afhankelijkheid van één developer zo gevaarlijk?\n\nHet voelt zelden gevaarlijk — totdat het dat is. De developer reageert snel, het systeem werkt, en er is geen voor de hand liggende reden om iets te veranderen. Dan wordt hij of zij op een dag stil. Of er komt een offerte voor een kleine aanpassing die drie keer zo hoog is als verwacht, omdat ze weten dat u geen alternatief heeft. Of ze gaan met pensioen en leveren een systeem op zonder documentatie, zonder testomgeving en zonder dat iemand anders de code kan lezen.\n\nDit heet **vendor lock-in op menselijk niveau** — en het komt vaker voor in maatwerksoftwareomgevingen dan de meeste IT-managers willen toegeven. Een observatie vanuit de praktijk: organisaties die draaien op FileMaker, low-code ERP of legacy maatwerk databases zijn bijzonder kwetsbaar, omdat deze platformen kleinere ontwikkelaarsgemeenschappen hebben en de oorspronkelijke bouwer het systeem vaak organisch heeft laten groeien over de jaren, waarbij alle institutionele kennis in zijn of haar hoofd zit.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F3?w=700&f=webp\" alt=\"Single developer holding keys to a complex system, team locked out\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## Hoe weet u of u al afhankelijk bent?\n\nBeantwoord deze vragen eerlijk:\n\n- Kan iemand in uw team — of een andere developer die u morgen zou kunnen inhuren — het systeem openen en de structuur begrijpen zonder een rondleiding?\n- Is er schriftelijke documentatie van het datamodel, de bedrijfslogica en de integratiepunten?\n- Heeft u toegang tot alle inloggegevens: server, database, hosting, licenties, API-sleutels van derden?\n- Heeft u in de afgelopen 90 dagen een back-up van de broncode ontvangen die u ook daadwerkelijk heeft getest?\n- Kunt u een betekenisvolle offerte opvragen bij een tweede developer zonder dat uw huidige developer daarbij betrokken is?\n\nAls u op twee of meer van deze vragen \"nee\" heeft geantwoord, bent u afhankelijk. Niet op weg om afhankelijk te worden — u bent het al.\n\n## Wat zijn de structurele oorzaken van deze afhankelijkheid?\n\nAfhankelijkheid ontstaat meestal niet door kwade bedoelingen. Het gebeurt omdat:\n\n1. **Het systeem groeide zonder governance.** Wat begon als een kleine database werd een bedrijfskritische applicatie, maar het bouwproces werd nooit geformaliseerd. Geen overdrachtslocumentatie, geen vastgelegde architectuurbeslissingen.\n2. **Toegang werd nooit gecentraliseerd.** De developer beheert de hosting, heeft de FileMaker-licentie in handen en beheert de serverinloggegevens. Gemak werd controle.\n3. **Er was nooit een second opinion.** Omdat de developer vertrouwd en beschikbaar was, was er nooit een reden om iemand anders in te schakelen. In de loop van de tijd verdween de interne kennis.\n4. **Contracten dekte IP en escrow niet af.** De code werd voor u geschreven, maar eigendom werd nooit expliciet overgedragen, of er werd nooit een broncode-escrow opgezet.\n\n## Hoe vermindert u de afhankelijkheid — stap voor stap?\n\n### Stap 1: Voer een afhankelijkheidsaudit uit\n\nVoordat u het probleem kunt oplossen, moet u het in kaart brengen. Besteed één gerichte sessie aan het inventariseren van:\n\n- Elk systeem dat de developer heeft gebouwd of onderhoudt\n- Elke inlogcode of licentie die ze namens u beheren\n- Elke integratie (API's, data-exports, e-mailconnectors) die ze beheren\n- Welke documentatie er momenteel bestaat en waar die zich bevindt\n\nDeze audit is ongemakkelijk maar essentieel. Het laat u de werkelijke schaalomvang zien als de relatie morgen eindigt.\n\n### Stap 2: Claim alle inloggegevens en licenties terug\n\nDit is niet onderhandelbaar en moet vóór alles anders gebeuren. Uw hostingaccount, uw FileMaker-licentie, uw domein, uw API-sleutels — al deze zaken moeten geregistreerd zijn op naam van uw organisatie, niet op naam van een individuele developer of hun bureau. Als dat niet het geval is, vraag dan onmiddellijk om de overdracht. Een professionele developer zal zich hier niet tegen verzetten.\n\n### Stap 3: Eis — en financier — levende documentatie\n\nDocumentatie is geen luxe. Maak er een contractueel op te leveren onderdeel van. U heeft minimaal nodig:\n\n- Een overzicht van het datamodel (welke tabellen bestaan er, wat slaan ze op, hoe verhouden ze zich)\n- Een lijst van alle scripts, automatiseringen en geplande processen met een beschrijving in gewone taal van wat elk doet\n- Een beschrijving van elke externe integratie en wat er kapotgaat als die uitvalt\n- Een deployment- en herstelprocedure: als de server vanavond uitvalt, wat zijn dan de exacte stappen om de dienst te herstellen?\n\nAls uw huidige developer zich verzet tegen het documenteren van hun eigen werk, is die weerstand op zich al een rode vlag die serieus genomen moet worden.\n\n### Stap 4: Introduceer nu een tweede developer — niet wanneer u er een nodig heeft\n\nHet slechtste moment om een back-up developer te vinden is tijdens een crisis. Introduceer een tweede developer terwijl het systeem stabiel is. Geef ze een kleine, echte taak — een rapport, een kleine UI-wijziging, een nieuwe data-export. Dit doet drie dingen: het test of de documentatie daadwerkelijk voldoende is voor een buitenstaander om mee te werken, het bouwt een relatie op voordat er urgentie is, en het geeft een stille boodschap dat u niet gebonden bent.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F2?w=700&f=webp\" alt=\"Two developers reviewing system documentation together, IT manager observing\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n### Stap 5: Stel een broncode-escrow of versiebeheeroverdracht in\n\nAls uw maatwerksoftware bedrijfskritisch is, moet de broncode in een versiebeheerde repository (Git is de standaard) staan die *u* bezit. Elke release moet worden vastgelegd. Als een formele escrow niet haalbaar is, spreek dan contractueel minimaal af dat u bij elke grote release een volledige broncode-export ontvangt en dat u die test aan de hand van een herstelprocedure.\n\n### Stap 6: Verwerk afhankelijkheidspreventie in toekomstige contracten\n\nZodra u uw huidige blootstelling heeft verminderd, legt u de juiste voorwaarden vast voor toekomstig werk:\n\n- **IP-eigendomsclausule**: alle voor u geschreven code is uw intellectueel eigendom na betaling\n- **Documentatieplicht**: documentatie maakt deel uit van de definitie van \"klaar\"\n- **Toegangsbeleid**: alle inloggegevens moeten op naam van uw organisatie staan\n- **Overdrachtsclausule**: bij het einde van het contract is de developer verplicht een gestructureerde overdrachtsperiode te ondersteunen\n- **Niet-exclusiviteit**: u behoudt uitdrukkelijk het recht om andere developers in te schakelen voor hetzelfde systeem\n\n## Wat als de developer ook uw platformleverancier is?\n\nSommige organisaties werken met één partij die zowel hun maatwerksoftware bouwt als host — bijvoorbeeld een FileMaker-partner die ook de server beheert en de licentie in handen heeft. Dit versterkt de afhankelijkheid. In dat geval gelden dezelfde principes, maar u moet expliciet zijn: scheid de *platformlicenties* van de *ontwikkelrelatie* en van de *hostingrelatie*. Dit zijn drie afzonderlijke zaken die indien nodig van drie afzonderlijke aanbieders kunnen worden betrokken.\n\nUw leverancier vragen om u te helpen de afhankelijkheid van hen te verminderen is een ongemakkelijk gesprek — maar een betrouwbare leverancier zal het verwelkomen, omdat het duidt op een volwassen klantrelatie gebaseerd op keuze in plaats van gebondenheid.\n\n## FAQ\n\n**Wat als ik om documentatie vraag en mijn developer mij een enorm aantal uren offereert?**\nDie offerte vertelt u iets belangrijks: het systeem is complexer en minder gestructureerd dan u dacht, *en* er heeft niemand een kennisbank bijgehouden. Onderhandel over een gefaseerd documentatieplan en behandel het als essentiële infrastructuurinvestering, niet als optionele overhead.\n\n**Is het realistisch om twee developers te hebben die beide ons systeem kennen?**\nJa — en het doel is niet dat beiden elke coderegel kennen. Het doel is dat een competente tweede developer het systeem kan oppakken, zichzelf kan oriënteren aan de hand van documentatie en een wijziging kan doorvoeren zonder een rondleiding. Dat is de lat om naar te streven.\n\n**Wat is de minimaal haalbare versie hiervan als we momenteel geen budget hebben?**\nConcentreer u eerst op drie dingen: claim alle inloggegevens en licenties terug, zorg voor een geteste broncode-back-up, en voer één eerlijk gesprek met een tweede developer om te ontdekken of uw systeem begrijpelijk is voor een buitenstaander. Die drie stappen kosten vrijwel niets en brengen alles aan het licht.\n\n**Onze developer werkt al tien jaar voor ons en is volledig betrouwbaar. Moeten we dit toch doen?**\nJa — want dit gaat niet over vertrouwen. Het gaat over continuïteit. Uw developer kan ziek worden, besluiten met pensioen te gaan of gewoon verder gaan. Het risico is niet dat ze slecht handelen; het is dat de kennis met hen mee verdwijnt. Zich daartegen beschermen is voor beide partijen eerlijk.\n\n## Een korte checklist om deze week mee te beginnen\n\n- [ ] Inventariseer elk systeem en elke inlogcode die uw developer momenteel beheert\n- [ ] Bevestig dat alle licenties en hostingaccounts op naam van uw organisatie staan\n- [ ] Vraag een actuele broncode-export op en test die aan de hand van een herstelprocedure\n- [ ] Vraag uw developer om systeemdocumentatie op te stellen of bij te werken\n- [ ] Identificeer een tweede developer en betrek die bij een kleine, echte taak\n- [ ] Controleer uw huidige contract op IP-eigendom en overdrachtsclausules\n\n---\n\nAfhankelijkheid van één developer is geen teken dat er iets fout is gegaan — het is een teken dat iets heeft gewerkt, lange tijd, zonder voldoende governance daaromheen. Het goede nieuws is dat het volledig omkeerbaar is met gestructureerde stappen. Begin met de audit, claim uw toegang terug en zorg voor een tweede stel ogen op het systeem voordat u ze dringend nodig heeft.","\u003Cp>Uw kernbedrijfssysteem draait op een maatwerkapplicatie, en precies één persoon begrijpt het echt. Die developer heeft het gebouwd, kent elke workaround en heeft de sleutels in handen — en als hij of zij vertrekt, ziek wordt, of simpelweg de tarieven verhoogt, heeft u een serieus probleem. Dit artikel geeft IT-specialisten een concreet, uitvoerbaar plan om die afhankelijkheid te identificeren, structureel te verminderen en ervoor te zorgen dat het nooit meer sluipenderwijs terugkeert.\u003C\u002Fp>\n\u003Ch2>Waarom is afhankelijkheid van één developer zo gevaarlijk?\u003C\u002Fh2>\n\u003Cp>Het voelt zelden gevaarlijk — totdat het dat is. De developer reageert snel, het systeem werkt, en er is geen voor de hand liggende reden om iets te veranderen. Dan wordt hij of zij op een dag stil. Of er komt een offerte voor een kleine aanpassing die drie keer zo hoog is als verwacht, omdat ze weten dat u geen alternatief heeft. Of ze gaan met pensioen en leveren een systeem op zonder documentatie, zonder testomgeving en zonder dat iemand anders de code kan lezen.\u003C\u002Fp>\n\u003Cp>Dit heet \u003Cstrong>vendor lock-in op menselijk niveau\u003C\u002Fstrong> — en het komt vaker voor in maatwerksoftwareomgevingen dan de meeste IT-managers willen toegeven. Een observatie vanuit de praktijk: organisaties die draaien op FileMaker, low-code ERP of legacy maatwerk databases zijn bijzonder kwetsbaar, omdat deze platformen kleinere ontwikkelaarsgemeenschappen hebben en de oorspronkelijke bouwer het systeem vaak organisch heeft laten groeien over de jaren, waarbij alle institutionele kennis in zijn of haar hoofd zit.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F3?w=700&f=webp\" alt=\"Single developer holding keys to a complex system, team locked out\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>Hoe weet u of u al afhankelijk bent?\u003C\u002Fh2>\n\u003Cp>Beantwoord deze vragen eerlijk:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Kan iemand in uw team — of een andere developer die u morgen zou kunnen inhuren — het systeem openen en de structuur begrijpen zonder een rondleiding?\u003C\u002Fli>\n\u003Cli>Is er schriftelijke documentatie van het datamodel, de bedrijfslogica en de integratiepunten?\u003C\u002Fli>\n\u003Cli>Heeft u toegang tot alle inloggegevens: server, database, hosting, licenties, API-sleutels van derden?\u003C\u002Fli>\n\u003Cli>Heeft u in de afgelopen 90 dagen een back-up van de broncode ontvangen die u ook daadwerkelijk heeft getest?\u003C\u002Fli>\n\u003Cli>Kunt u een betekenisvolle offerte opvragen bij een tweede developer zonder dat uw huidige developer daarbij betrokken is?\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Als u op twee of meer van deze vragen "nee" heeft geantwoord, bent u afhankelijk. Niet op weg om afhankelijk te worden — u bent het al.\u003C\u002Fp>\n\u003Ch2>Wat zijn de structurele oorzaken van deze afhankelijkheid?\u003C\u002Fh2>\n\u003Cp>Afhankelijkheid ontstaat meestal niet door kwade bedoelingen. Het gebeurt omdat:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Het systeem groeide zonder governance.\u003C\u002Fstrong> Wat begon als een kleine database werd een bedrijfskritische applicatie, maar het bouwproces werd nooit geformaliseerd. Geen overdrachtslocumentatie, geen vastgelegde architectuurbeslissingen.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Toegang werd nooit gecentraliseerd.\u003C\u002Fstrong> De developer beheert de hosting, heeft de FileMaker-licentie in handen en beheert de serverinloggegevens. Gemak werd controle.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Er was nooit een second opinion.\u003C\u002Fstrong> Omdat de developer vertrouwd en beschikbaar was, was er nooit een reden om iemand anders in te schakelen. In de loop van de tijd verdween de interne kennis.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Contracten dekte IP en escrow niet af.\u003C\u002Fstrong> De code werd voor u geschreven, maar eigendom werd nooit expliciet overgedragen, of er werd nooit een broncode-escrow opgezet.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>Hoe vermindert u de afhankelijkheid — stap voor stap?\u003C\u002Fh2>\n\u003Ch3>Stap 1: Voer een afhankelijkheidsaudit uit\u003C\u002Fh3>\n\u003Cp>Voordat u het probleem kunt oplossen, moet u het in kaart brengen. Besteed één gerichte sessie aan het inventariseren van:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Elk systeem dat de developer heeft gebouwd of onderhoudt\u003C\u002Fli>\n\u003Cli>Elke inlogcode of licentie die ze namens u beheren\u003C\u002Fli>\n\u003Cli>Elke integratie (API's, data-exports, e-mailconnectors) die ze beheren\u003C\u002Fli>\n\u003Cli>Welke documentatie er momenteel bestaat en waar die zich bevindt\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Deze audit is ongemakkelijk maar essentieel. Het laat u de werkelijke schaalomvang zien als de relatie morgen eindigt.\u003C\u002Fp>\n\u003Ch3>Stap 2: Claim alle inloggegevens en licenties terug\u003C\u002Fh3>\n\u003Cp>Dit is niet onderhandelbaar en moet vóór alles anders gebeuren. Uw hostingaccount, uw FileMaker-licentie, uw domein, uw API-sleutels — al deze zaken moeten geregistreerd zijn op naam van uw organisatie, niet op naam van een individuele developer of hun bureau. Als dat niet het geval is, vraag dan onmiddellijk om de overdracht. Een professionele developer zal zich hier niet tegen verzetten.\u003C\u002Fp>\n\u003Ch3>Stap 3: Eis — en financier — levende documentatie\u003C\u002Fh3>\n\u003Cp>Documentatie is geen luxe. Maak er een contractueel op te leveren onderdeel van. U heeft minimaal nodig:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Een overzicht van het datamodel (welke tabellen bestaan er, wat slaan ze op, hoe verhouden ze zich)\u003C\u002Fli>\n\u003Cli>Een lijst van alle scripts, automatiseringen en geplande processen met een beschrijving in gewone taal van wat elk doet\u003C\u002Fli>\n\u003Cli>Een beschrijving van elke externe integratie en wat er kapotgaat als die uitvalt\u003C\u002Fli>\n\u003Cli>Een deployment- en herstelprocedure: als de server vanavond uitvalt, wat zijn dan de exacte stappen om de dienst te herstellen?\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Als uw huidige developer zich verzet tegen het documenteren van hun eigen werk, is die weerstand op zich al een rode vlag die serieus genomen moet worden.\u003C\u002Fp>\n\u003Ch3>Stap 4: Introduceer nu een tweede developer — niet wanneer u er een nodig heeft\u003C\u002Fh3>\n\u003Cp>Het slechtste moment om een back-up developer te vinden is tijdens een crisis. Introduceer een tweede developer terwijl het systeem stabiel is. Geef ze een kleine, echte taak — een rapport, een kleine UI-wijziging, een nieuwe data-export. Dit doet drie dingen: het test of de documentatie daadwerkelijk voldoende is voor een buitenstaander om mee te werken, het bouwt een relatie op voordat er urgentie is, en het geeft een stille boodschap dat u niet gebonden bent.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F2?w=700&f=webp\" alt=\"Two developers reviewing system documentation together, IT manager observing\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch3>Stap 5: Stel een broncode-escrow of versiebeheeroverdracht in\u003C\u002Fh3>\n\u003Cp>Als uw maatwerksoftware bedrijfskritisch is, moet de broncode in een versiebeheerde repository (Git is de standaard) staan die \u003Cem>u\u003C\u002Fem> bezit. Elke release moet worden vastgelegd. Als een formele escrow niet haalbaar is, spreek dan contractueel minimaal af dat u bij elke grote release een volledige broncode-export ontvangt en dat u die test aan de hand van een herstelprocedure.\u003C\u002Fp>\n\u003Ch3>Stap 6: Verwerk afhankelijkheidspreventie in toekomstige contracten\u003C\u002Fh3>\n\u003Cp>Zodra u uw huidige blootstelling heeft verminderd, legt u de juiste voorwaarden vast voor toekomstig werk:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>IP-eigendomsclausule\u003C\u002Fstrong>: alle voor u geschreven code is uw intellectueel eigendom na betaling\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Documentatieplicht\u003C\u002Fstrong>: documentatie maakt deel uit van de definitie van "klaar"\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Toegangsbeleid\u003C\u002Fstrong>: alle inloggegevens moeten op naam van uw organisatie staan\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Overdrachtsclausule\u003C\u002Fstrong>: bij het einde van het contract is de developer verplicht een gestructureerde overdrachtsperiode te ondersteunen\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Niet-exclusiviteit\u003C\u002Fstrong>: u behoudt uitdrukkelijk het recht om andere developers in te schakelen voor hetzelfde systeem\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Wat als de developer ook uw platformleverancier is?\u003C\u002Fh2>\n\u003Cp>Sommige organisaties werken met één partij die zowel hun maatwerksoftware bouwt als host — bijvoorbeeld een FileMaker-partner die ook de server beheert en de licentie in handen heeft. Dit versterkt de afhankelijkheid. In dat geval gelden dezelfde principes, maar u moet expliciet zijn: scheid de \u003Cem>platformlicenties\u003C\u002Fem> van de \u003Cem>ontwikkelrelatie\u003C\u002Fem> en van de \u003Cem>hostingrelatie\u003C\u002Fem>. Dit zijn drie afzonderlijke zaken die indien nodig van drie afzonderlijke aanbieders kunnen worden betrokken.\u003C\u002Fp>\n\u003Cp>Uw leverancier vragen om u te helpen de afhankelijkheid van hen te verminderen is een ongemakkelijk gesprek — maar een betrouwbare leverancier zal het verwelkomen, omdat het duidt op een volwassen klantrelatie gebaseerd op keuze in plaats van gebondenheid.\u003C\u002Fp>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Wat als ik om documentatie vraag en mijn developer mij een enorm aantal uren offereert?\u003C\u002Fstrong>\nDie offerte vertelt u iets belangrijks: het systeem is complexer en minder gestructureerd dan u dacht, \u003Cem>en\u003C\u002Fem> er heeft niemand een kennisbank bijgehouden. Onderhandel over een gefaseerd documentatieplan en behandel het als essentiële infrastructuurinvestering, niet als optionele overhead.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is het realistisch om twee developers te hebben die beide ons systeem kennen?\u003C\u002Fstrong>\nJa — en het doel is niet dat beiden elke coderegel kennen. Het doel is dat een competente tweede developer het systeem kan oppakken, zichzelf kan oriënteren aan de hand van documentatie en een wijziging kan doorvoeren zonder een rondleiding. Dat is de lat om naar te streven.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Wat is de minimaal haalbare versie hiervan als we momenteel geen budget hebben?\u003C\u002Fstrong>\nConcentreer u eerst op drie dingen: claim alle inloggegevens en licenties terug, zorg voor een geteste broncode-back-up, en voer één eerlijk gesprek met een tweede developer om te ontdekken of uw systeem begrijpelijk is voor een buitenstaander. Die drie stappen kosten vrijwel niets en brengen alles aan het licht.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Onze developer werkt al tien jaar voor ons en is volledig betrouwbaar. Moeten we dit toch doen?\u003C\u002Fstrong>\nJa — want dit gaat niet over vertrouwen. Het gaat over continuïteit. Uw developer kan ziek worden, besluiten met pensioen te gaan of gewoon verder gaan. Het risico is niet dat ze slecht handelen; het is dat de kennis met hen mee verdwijnt. Zich daartegen beschermen is voor beide partijen eerlijk.\u003C\u002Fp>\n\u003Ch2>Een korte checklist om deze week mee te beginnen\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Inventariseer elk systeem en elke inlogcode die uw developer momenteel beheert\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Bevestig dat alle licenties en hostingaccounts op naam van uw organisatie staan\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Vraag een actuele broncode-export op en test die aan de hand van een herstelprocedure\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Vraag uw developer om systeemdocumentatie op te stellen of bij te werken\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Identificeer een tweede developer en betrek die bij een kleine, echte taak\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Controleer uw huidige contract op IP-eigendom en overdrachtsclausules\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Chr>\n\u003Cp>Afhankelijkheid van één developer is geen teken dat er iets fout is gegaan — het is een teken dat iets heeft gewerkt, lange tijd, zonder voldoende governance daaromheen. Het goede nieuws is dat het volledig omkeerbaar is met gestructureerde stappen. Begin met de audit, claim uw toegang terug en zorg voor een tweede stel ogen op het systeem voordat u ze dringend nodig heeft.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901680000,[19,20,21,22,23,24,25,26],"IT governance","vendor lock-in","custom software","business continuity","FileMaker","developer dependency","software maintenance","IT risk management",null,false]