Wat moet ik doen als onze developer is vertrokken en niemand de code meer snapt?

Frank Teunissen · 27 mrt 2026

Je developer is vertrokken. De code draait nog, maar niemand in het team weet precies hoe het systeem in elkaar steekt. Dit scenario komt vaker voor dan je denkt, zeker bij MKB-bedrijven die jarenlang op één vaste ontwikkelaar hebben vertrouwd. De gevolgen kunnen groot zijn: van vastgelopen updates tot complete stilstand bij een technisch probleem.

In dit artikel beantwoorden we de meest prangende vragen over wat je moet doen als je met achtergelaten of onbegrijpelijke code zit. Van de eerste stappen tot de afweging of je de software opnieuw moet bouwen: je vindt hier concrete handvatten om de IT-continuïteit te herstellen en toekomstige risico’s te beperken.

Waarom is het zo gevaarlijk als maar één developer de code kent?

Als slechts één persoon de code begrijpt, creëer je een zogenoemd “single point of failure” in je organisatie. Vertrekt die developer, dan verdwijnt niet alleen de kennis over hoe de software werkt, maar ook de context achter elke keuze die ooit is gemaakt. Bugs worden moeilijk op te lossen, nieuwe functies zijn nauwelijks toe te voegen en de software wordt steeds kwetsbaarder.

Dit risico is bij maatwerksoftware extra groot. In tegenstelling tot standaardsoftware bestaat er geen externe documentatie of community waar je terechtkunt. De kennis zit volledig in het hoofd van de developer, en als die weg is, ben je afhankelijk van wat er in de code zelf te lezen valt. Zonder goede codedocumentatie is dat vaak weinig.

Bovendien groeit het probleem met de tijd. Hoe langer de software draait zonder dat iemand er goed in thuis is, hoe meer er wordt opgelapt zonder het grotere geheel te begrijpen. Het resultaat is een systeem dat technisch nog werkt, maar steeds moeilijker te onderhouden is. In de praktijk noemen we dit legacy code: code die functioneert, maar waarvan de structuur en logica voor buitenstaanders nauwelijks te doorgronden zijn.

Wat zijn de eerste stappen na het vertrek van een developer?

Direct na het vertrek van een developer zijn er vier concrete stappen die je zo snel mogelijk moet zetten: zorg dat je toegang hebt tot alle systemen, breng de bestaande documentatie in kaart, maak een veilige kopie van de codebase en stel vast welke delen van de software bedrijfskritisch zijn.

Toegang en beheer veiligstellen

Controleer of je toegang hebt tot de broncode, de server, het versiebeheer (zoals Git) en eventuele externe diensten of API-sleutels. Dit klinkt voor de hand liggend, maar in de praktijk blijkt toegang regelmatig te zijn gekoppeld aan persoonlijke accounts van de vertrokken developer. Zorg dat wachtwoorden worden gewijzigd en dat je als organisatie eigenaar bent van alle accounts.

Inventariseer wat er is

Zoek naar bestaande documentatie, al is het maar een README-bestand of een paar losse notities. Vraag ook aan teamleden of collega’s wat ze weten over de werking van het systeem. Zelfs fragmentarische kennis helpt bij de volgende stap: het beoordelen van de kwaliteit van de code.

Prioriteer op basis van bedrijfsrisico

Niet alles is even urgent. Stel vast welke onderdelen van de software dagelijks worden gebruikt en wat de gevolgen zijn als die uitvallen. Zo kun je gericht bepalen waar je als eerste aandacht aan besteedt bij de softwareoverdracht aan een nieuw team of een nieuwe developer.

Hoe beoordeel je de kwaliteit van achtergelaten code?

De kwaliteit van achtergelaten code beoordeel je op vier aspecten: leesbaarheid, structuur, testdekking en documentatie. Goede code is begrijpelijk voor een nieuwe developer zonder uitleg. Slechte code bevat veel ongedocumenteerde aannames, inconsistente naamgeving en ontbrekende tests.

Laat een onafhankelijke developer of een extern softwarebedrijf een technische audit uitvoeren. Zo’n legacy code-analyse geeft inzicht in de staat van de codebase en de risico’s die daarmee gepaard gaan. Je krijgt een eerlijk beeld van wat er is, zonder dat je zelf technische kennis nodig hebt om de conclusie te trekken.

Let tijdens de beoordeling op de volgende signalen:

Ontbreekt er versiebeheer, of is de Git-geschiedenis leeg of chaotisch?
Zijn er geen of nauwelijks geautomatiseerde tests aanwezig?
Is de code geschreven in verouderde of zeldzame technologieën?
Staan er hardgecodeerde waarden, zoals wachtwoorden of API-sleutels, in de code?
Ontbreekt er een duidelijke scheiding tussen de verschillende lagen van de applicatie?

Hoe meer van deze signalen aanwezig zijn, hoe groter het risico dat kleine aanpassingen grote, onverwachte gevolgen hebben. In dat geval is het verstandig om serieus te overwegen of repareren nog zinvol is.

Wanneer is het beter om software opnieuw te bouwen dan te repareren?

Het is beter om software opnieuw te bouwen dan te repareren wanneer de onderhoudskosten structureel hoger liggen dan de kosten van vervanging, of wanneer de bestaande code zo verouderd of ongedocumenteerd is dat elke aanpassing een nieuw risico introduceert. Repareren heeft dan geen langetermijnwaarde meer.

Er zijn concrete situaties waarin herbouwen de juiste keuze is:

De onderliggende technologie wordt niet meer ondersteund of is moeilijk te vinden op de arbeidsmarkt.
De software sluit niet meer aan op de huidige bedrijfsprocessen en er zijn ingrijpende aanpassingen nodig.
Elke bug die je oplost, introduceert nieuwe problemen elders in het systeem.
Er is geen testinfrastructuur aanwezig, waardoor je nooit zeker weet of een wijziging veilig is.
De software is een belemmering geworden voor groei in plaats van een ondersteuning daarvan.

Repareren is wél zinvol als de kern van de applicatie nog solide is, de technologie actueel genoeg is en de problemen beperkt zijn tot specifieke onderdelen. In dat geval kan gerichte refactoring, waarbij de structuur van de code wordt verbeterd zonder de functionaliteit te veranderen, voldoende zijn om de software weer beheerbaar te maken.

Hoe voorkom je dit probleem in de toekomst?

Je voorkomt kennisafhankelijkheid en verlies van IT-continuïteit door structureel te investeren in documentatie, versiebeheer, kennisdeling en heldere afspraken over softwareoverdracht. Dit hoeft niet ingewikkeld te zijn, maar vraagt wel discipline en consistentie.

Concrete maatregelen die je kunt nemen:

Verplicht versiebeheer: Alle code wordt beheerd in een systeem zoals Git, met duidelijke commitberichten die uitleggen waarom een wijziging is gedaan.
Schrijf documentatie als onderdeel van het werk: Niet achteraf, maar tijdens de ontwikkeling. Een README per module is al een grote stap vooruit.
Werk met meerdere developers: Zorg dat minimaal twee mensen elk onderdeel van de software kennen. Code reviews zijn hiervoor een effectief middel.
Leg afspraken vast in contracten: Als je met externe developers werkt, zorg dan dat eigendom van de code, overdrachtsverplichtingen en documentatie-eisen contractueel zijn geregeld.
Plan periodieke technische audits: Laat de staat van je software regelmatig beoordelen, ook als er geen acute problemen zijn. Zo signaleer je risico’s vroeg.

Softwareontwikkeling voor het MKB vraagt om een andere aanpak dan bij grote organisaties met vaste IT-afdelingen. Juist omdat de teams kleiner zijn, is het risico op kennisconcentratie groter. Door bewust te investeren in de overdraagbaarheid van kennis, bouw je aan een fundament dat ook bestand is tegen wisselingen in het team.

Hoe VL Software helpt bij legacy code en softwareoverdracht

VL Software helpt organisaties die vastzitten met onbegrijpelijke, slecht gedocumenteerde of verouderde maatwerksoftware. Of je nu een nieuwe developer zoekt die de bestaande code overneemt, of overweegt om de software volledig opnieuw te laten bouwen: VL Software begeleidt je door het hele traject.

Wat VL Software voor je kan doen:

Legacy code-analyse: Een grondige technische audit van de bestaande codebase, zodat je weet wat je hebt en welke risico’s er spelen.
Replatforming: Verouderde software wordt stap voor stap omgebouwd naar een moderne, onderhoudbare applicatie, zonder verlies van bedrijfslogica of data.
IT-detachering: Een ervaren softwareprofessional die tijdelijk bij jou instapt om de bestaande code te doorgronden, te documenteren en te stabiliseren.
Maatwerksoftwareontwikkeling: Als herbouwen de juiste keuze is, bouwt het team van VL Software een nieuwe applicatie op basis van moderne technologieën zoals Laravel en React.

Dankzij de combinatie van softwareontwikkeling en consultancy onder één dak zorgt VL Software voor strak projectmanagement, korte communicatielijnen en een oplossing die aansluit op jouw bedrijfsprocessen. Zit je met een vertrokken developer en weet je niet waar je moet beginnen? Neem contact op met VL Software voor een vrijblijvend gesprek.