De situatie
Softwarebedrijf. 20 medewerkers, waarvan 8 developers. SaaS-product voor de logistieke sector — routeplanning, voorraadbeheer, klantportaal. Tienduizenden gebruikers.
Features duurden structureel 2x langer dan ingeschat. De CTO’s analyse: de codebase is te complex geworden. We hebben meer developers nodig.
Wat er werkelijk speelde
De code was niet het probleem. Het probleem was onzichtbaar — het zat in de overgangen.
Elke keer dat een developer een feature oppakte na een weekend, vergadering of contextwissel, begon hetzelfde ritueel. Git log doorlopen. Slack-berichten teruglezen. Eigen notities zoeken — als die er al waren. 30 tot 60 minuten per keer om te reconstrueren wat er gedaan was, welke beslissingen genomen waren, en waarom.
Dat klinkt als een klein probleem. Het was het niet.
Bij 8 developers, 2–3 contextwisselingen per dag, verloor het team dagelijks 8 tot 16 uur aan reconstructie. Niet aan bugs. Niet aan complexe code. Aan het opnieuw opbouwen van kennis die er al was maar nergens vastlag.
De escalatie
Pull requests bleven 2+ dagen open. Niet omdat reviewers traag waren, maar omdat ze de context niet begrepen. Waarom deze aanpak? Welke alternatieven zijn overwogen? Wat is het effect op andere modules? Ze moesten het vragen. De auteur moest het uitleggen. Soms wist die het zelf niet meer.
Senior developers werden het bottleneck. Alleen zij konden beslissingen toelichten die weken eerder genomen waren. Ze werden wandelende documentatie — onmisbaar, onschaalbaar.
Nieuwe medewerkers deden 3+ maanden om productief te worden. Niet door de code, maar door het ontbreken van context rond de code. Waarom is dit zo gebouwd? Waar hangt dit mee samen? Niemand had het opgeschreven.
Sprintsnelheid daalde 35% in zes maanden. De oplossing die het management zag: meer developers aannemen. De werkelijke kosten: 2 extra salarissen om een probleem te compenseren dat geen mensenprobleem was.
De interventie
We bouwden een systeem dat context persistent maakt — niet als documentatie achteraf, maar als onderdeel van het ontwikkelproces zelf.
Bij elke commit legt het systeem automatisch vast: wat er gedaan is, welke beslissingen genomen zijn en waarom, wat wel en niet werkte. Geen extra stap voor de developer — het haalt de informatie uit de code-wijzigingen, commit-berichten en bijbehorende tickets.
Per feature ontstaan persistente contextbestanden die sessiewisselingen overleven. Een developer pakt maandagochtend een feature op en heeft binnen 2 minuten het volledige beeld: wat er staat, wat de volgende stap is, welke randgevallen al afgevangen zijn.
Pull requests worden automatisch gegenereerd met volledige beslissingshistorie en testresultaten. De reviewer ziet niet alleen wát er veranderd is, maar waarom — inclusief welke alternatieven overwogen en afgewezen zijn.
Het resultaat
PR review-tijd ging van 2 dagen naar 4 uur. Reviewers begrepen direct de context. Geen heen-en-weer meer over “waarom deze aanpak?”
Elke developer kon elk feature binnen 10 minuten oppakken — ongeacht wie eraan begonnen was. De afhankelijkheid van senior developers als kennisbron verdween.
Sprintsnelheid herstelde binnen één kwartaal naar het niveau van een jaar eerder. Zonder extra aannames.
Onboarding-tijd voor nieuwe medewerkers halveerde. Van 3+ maanden naar 6 weken productief. De context was er al — ze hoefden alleen te lezen in plaats van te vragen.