Wat is het risico van software die alleen één persoon nog begrijpt?

Frank Teunissen · 19 apr 2026

Stel je voor: de enige persoon die jullie kritieke bedrijfssoftware echt begrijpt, stapt op. Of erger nog: valt langdurig uit. Wat dan? Voor veel MKB-bedrijven is dit geen theoretisch scenario, maar een reëel risico dat elke dag op de loer ligt. Dit fenomeen heeft zelfs een naam: de busfactor, ook wel het kennismonopolie in software genoemd.

In dit artikel beantwoorden we de meest gestelde vragen over softwarerisico’s rondom kennisafhankelijkheid. Je leest hoe zo’n situatie ontstaat, wat de gevolgen zijn en, belangrijker nog, wat je eraan kunt doen voordat het misgaat.

Wat is het risico van software die maar één persoon begrijpt?

Het risico is dat jouw organisatie volledig afhankelijk wordt van de beschikbaarheid, de kennis en de goodwill van één persoon. Als die persoon wegvalt, komt je softwarebeheer stil te liggen. Aanpassingen, bugfixes en nieuwe functionaliteiten worden onmogelijk of extreem kostbaar, omdat niemand anders weet hoe het systeem in elkaar zit.

Dit risico wordt in de softwarewereld aangeduid als de busfactor, of als het kennismonopolie. De term verwijst naar de vraag: hoeveel mensen moeten er uitvallen voordat een project in gevaar komt? Als het antwoord “één” is, zit je in een kwetsbare positie. Zeker bij maatwerksoftware, waarbij de applicatie specifiek voor jouw bedrijf is gebouwd, is dit een veelvoorkomend probleem.

Wat het extra gevaarlijk maakt, is dat dit risico vaak onzichtbaar is. De software werkt prima, alles loopt soepel en er lijkt geen vuiltje aan de lucht. Totdat er iets verandert.

Hoe ontstaat een kennismonopolie binnen softwareprojecten?

Een kennismonopolie in software ontstaat wanneer kennis over de werking, structuur en logica van een systeem zich concentreert bij één persoon, zonder dat die kennis structureel wordt gedocumenteerd of gedeeld. Dit gebeurt zelden bewust, maar is vaak het gevolg van tijdsdruk, snelle groei of een gebrek aan duidelijke afspraken.

In de praktijk zien we dit patroon regelmatig bij bedrijven die jarenlang met dezelfde ontwikkelaar hebben gewerkt. Die persoon kende het systeem door en door, bouwde het stap voor stap uit en droeg alles in zijn of haar hoofd. Documentatie werd steeds uitgesteld, want: “We weten toch hoe het werkt.”

Andere veelvoorkomende oorzaken zijn:

Geen overdrachtsprotocol bij wisselingen van personeel of leveranciers
Maatwerksoftware die nooit formeel is opgeleverd met technische documentatie
Legacysoftware die zo oud is dat de oorspronkelijke bouwer de enige is met kennis van de architectuur
Kleine teams waarin kennis automatisch bij één persoon belandt

Het resultaat is een systeem dat technisch nog functioneert, maar waarvan de kennis langzaam verdampt naarmate de tijd verstrijkt.

Wat zijn de concrete gevolgen voor een bedrijf als die persoon wegvalt?

Als de enige kenner van jouw software wegvalt, krijg je direct te maken met operationele stilstand, hoge kosten voor kennisoverdracht en een verhoogd risico op fouten. Aanpassingen die normaal een dag kosten, kunnen weken in beslag nemen, terwijl een nieuwe partij het systeem probeert te doorgronden.

De gevolgen zijn concreet en voelbaar:

Geen bugfixes: Een storing in het systeem kan niet worden opgelost omdat niemand begrijpt waar het probleem zit.
Geen doorontwikkeling: Nieuwe functionaliteiten zijn onmogelijk zonder het systeem volledig te begrijpen.
Hoge herstelkosten: Een externe partij moet het systeem vanaf nul leren kennen, wat tijd en geld kost.
Dataverlies of beveiligingsrisico’s: Bij verouderde of slecht gedocumenteerde systemen kunnen updates uitblijven, wat beveiligingslekken oplevert.
Bedrijfsstilstand: Als het systeem uitvalt en niemand het kan repareren, komen bedrijfsprocessen stil te liggen.

Vooral bij MKB-bedrijven die sterk leunen op maatwerksoftware voor hun kernprocessen, kan softwareafhankelijkheid van één persoon existentiële gevolgen hebben. De schade is niet alleen financieel, maar raakt ook de continuïteit en reputatie van je organisatie.

Hoe herken je of jouw software dit risico loopt?

Je software loopt dit risico als er maar één persoon is die vragen over het systeem kan beantwoorden, als documentatie ontbreekt of verouderd is, en als het idee dat die persoon wegvalt direct onrust veroorzaakt. Dat gevoel van onrust is op zichzelf al een signaal.

Stel jezelf de volgende vragen om het risico te beoordelen:

Wie kan een storing in ons systeem oplossen als de vaste beheerder niet beschikbaar is?
Bestaat er actuele technische documentatie van de applicatie?
Heeft meer dan één persoon toegang tot de broncode en begrijpt die persoon de structuur?
Wanneer is de software voor het laatst door een externe partij beoordeeld?
Is de software gebouwd op moderne, gangbare technologie of op verouderde stacks die nog maar weinig ontwikkelaars kennen?

Beantwoord je meerdere van deze vragen negatief, dan is de kans groot dat je te maken hebt met een serieus softwarerisico. Een legacy scan van je bestaande systeem kan helpen om dit risico objectief in kaart te brengen voordat het een probleem wordt.

Hoe verklein je de afhankelijkheid van één softwareontwikkelaar?

Je verkleint softwareafhankelijkheid door kennis actief te spreiden, documentatie structureel bij te houden en ervoor te zorgen dat minimaal twee mensen het systeem begrijpen. Dit vraagt om bewuste keuzes in hoe je samenwerkt met ontwikkelaars en hoe je softwareprojecten inricht.

Concrete stappen die je kunt zetten:

Eis documentatie als onderdeel van de oplevering: Zorg dat elke nieuwe functionaliteit wordt gedocumenteerd, inclusief technische keuzes en architectuurbeslissingen.
Gebruik gangbare, moderne technologieën: Software die is gebouwd op veelgebruikte frameworks zoals Laravel of React is makkelijker over te dragen dan nichetechnologie.
Codereview door meerdere ontwikkelaars: Zorg dat meer dan één persoon de broncode kent en beoordeelt.
Regelmatige kennisoverdrachtsessies: Plan periodiek momenten waarop kennis actief wordt gedeeld binnen het team.
Broncode in eigen beheer: Zorg dat jij als opdrachtgever eigenaar bent van de broncode en toegang hebt tot de repository.

Bij maatwerksoftware is het extra belangrijk om dit al bij de start van het project te regelen. Achteraf kennis overdragen is mogelijk, maar duurder en tijdrovender dan het vanaf het begin goed inrichten.

Wanneer is het tijd om over te stappen naar een betrouwbare softwarepartner?

Het is tijd om over te stappen als je merkt dat je systeem niet meer onderhoudbaar is, als de huidige leverancier of ontwikkelaar niet meer beschikbaar is, of als je software zo verouderd is dat doorontwikkeling niet langer haalbaar is. Wacht niet tot er een crisis ontstaat.

Signalen die aangeven dat actie nodig is:

De huidige ontwikkelaar of leverancier reageert traag of is moeilijk bereikbaar
Kleine aanpassingen kosten disproportioneel veel tijd en geld
De software draait op technologie die niet meer actief wordt onderhouden
Nieuwe medewerkers of partners kunnen het systeem niet begrijpen of gebruiken
Beveiligingsupdates blijven uit omdat niemand de software nog aanpast

Overstappen naar een nieuwe softwarepartner voelt soms als een grote stap, maar het alternatief—namelijk blijven hangen in een systeem met een hoge softwareafhankelijkheid—is op de lange termijn een groter risico. Een goede partner helpt je niet alleen met de overstap, maar zorgt er ook voor dat de nieuwe situatie robuuster en toekomstbestendiger is dan de oude.

Hoe VL Software helpt bij softwareafhankelijkheid en legacy risico’s

VL Software helpt organisaties die vastlopen op verouderde of slecht gedocumenteerde software om die afhankelijkheid te doorbreken. Dat doen we concreet via replatforming van legacysystemen: het omzetten van een kwetsbaar, moeilijk onderhoudbaar systeem naar een robuuste, moderne webapplicatie, zonder dat waardevolle bedrijfslogica verloren gaat.

Wat je kunt verwachten:

Een grondige analyse van je huidige systeem, architectuur en knelpunten
Een migratiestrategie op maat, afgestemd op jouw processen en planning
Ontwikkeling met moderne technologieën zoals Laravel, React (TypeScript) en GraphQL
Volledige documentatie en kennisoverdracht als standaard onderdeel van het traject
Strak projectmanagement dankzij de combinatie van consultancy en ontwikkeling onder één dak

Twijfel je of jouw software dit risico loopt? Neem dan contact op met VL Software voor een vrijblijvend gesprek. We kijken samen naar jouw situatie en geven je een eerlijk beeld van de risico’s en de mogelijkheden.