Project overnemen en doorontwikkelen.

Het verhaal dat ik steeds opnieuw hoor

Een aanzienlijk deel van mijn klanten komt bij mij terecht omdat ze vastlopen met hun huidige development partner. Het verhaal is bijna altijd een variatie op hetzelfde thema: de communicatie stokt, afspraken worden niet nagekomen, kosten lopen op en het gevoel groeit dat er iets fundamenteel mis is. Maar de vinger erop leggen is lastig als je zelf geen developer bent.

De klachten die ik hoor zijn opvallend consistent. Het helpt om ze te herkennen, want ze hangen vaak samen en hebben dezelfde onderliggende oorzaak.

Communicatieproblemen

Je wordt niet gehoord. Feedback verdwijnt in een zwart gat. Vragen over voortgang worden beantwoord met vage termen. Deadlines verschuiven zonder uitleg. Je hebt het gevoel dat je partner niet begrijpt wat je nodig hebt — of erger: het niet wil begrijpen.

Beperkingen die uit het niets opduiken

Features die eerder "geen probleem" waren, zijn ineens "technisch niet haalbaar" of "veel complexer dan verwacht." Kleine wijzigingen kosten weken. Je krijgt het gevoel dat je software niet meewerkt maar tegenwerkt. En je partner kan niet goed uitleggen waarom.

Kosten die uit de hand lopen

Elke sprint kost meer dan de vorige. Elke wijziging heeft onverwachte bijeffecten die ook weer gefixed moeten worden. De facturen stijgen, maar de voortgang daalt. Je investeert steeds meer om steeds minder resultaat te zien.

De echte oorzaak zit meestal in de code

Hier komt het eerlijke verhaal. In veel gevallen zijn de communicatieproblemen, de beperkingen en de stijgende kosten geen gevolg van een luie of onbekwame partner. Ze zijn symptomen van een dieper probleem: de code zelf.

Slechte architectuur, ongestructureerde code, het ontbreken van tests, gebrekkige documentatie en jarenlang opgestapelde technische schuld maken een applicatie steeds moeilijker om mee te werken. Je development partner worstelt net zo hard met de codebase als jij met de resultaten. Het verschil is dat zij de technische realiteit zien en jij alleen de gevolgen ervan ervaart.

Dat maakt de situatie niet minder frustrerend. Maar het betekent wel dat simpelweg wisselen van development partner het probleem niet per definitie oplost. Een nieuw team dat dezelfde rommelige codebase erft, loopt binnen enkele maanden tegen exact dezelfde muren aan.

De meest eerlijke vraag is niet "wie kan dit overnemen?" maar "is deze code het waard om op door te bouwen?"

Stap één: de code audit

Voordat ik een oordeel vel of advies geef, wil ik de feiten zien. De eerste stap bij elke overname is een grondige technische audit van de bestaande codebase. Geen aannames, geen vooroordelen. Gewoon de code opentrekken en beoordelen op de punten die ertoe doen:

• Architectuur en structuur — Is er een herkenbaar patroon? Zijn verantwoordelijkheden logisch verdeeld? Of is het een grabbelton van functies die door elkaar heen grijpen?
• Code kwaliteit — Is de code leesbaar en consistent? Zijn er conventies gevolgd? Of schrijft elke developer in een eigen stijl zonder samenhang?
• Testdekking — Zijn er automatische tests? Kun je met vertrouwen wijzigingen doorvoeren zonder dat er ergens anders iets omvalt?
• Technische schuld — Hoeveel workarounds, hardcoded waarden en tijdelijke oplossingen zijn permanent geworden?
• Dependencies en security — Zijn frameworks en packages up-to-date? Zijn er bekende kwetsbaarheden?
• Schaalbaarheid — Kan de applicatie groeien met je bedrijf, of zit je nu al tegen de limieten aan?

Het resultaat van zo'n audit is een helder beeld: waar staat de applicatie technisch, wat zijn de risico's, en wat zijn de opties om verder te gaan.

De drie scenario's

Na een audit zijn er in de praktijk drie mogelijke uitkomsten. Welk scenario van toepassing is, hangt af van de staat van de code, de ambities van de organisatie en het beschikbare budget.

Scenario 1: de code is prima, het team niet

Soms is er niets mis met de codebase. De architectuur is solide, de code is onderhoudbaar, maar de samenwerking met het vorige team werkte gewoon niet. In dat geval is overname en doorontwikkeling de logische route. Ik pak de bestaande code op en ga er effectief mee verder. Dit is het meest efficiënte scenario en komt vaker voor dan je denkt.

Scenario 2: gedeeltelijke migratie

In veel gevallen is het beeld gemengd. Sommige delen van de applicatie zijn degelijk gebouwd, andere zijn een bron van problemen. Dan is een hybride aanpak het slimst: behoud wat goed werkt, herbouw wat niet werkt. Dit vraagt om een zorgvuldige analyse van welke modules je overneemt en welke je vervangt, maar het is vaak de meest kosteneffectieve route.

Scenario 3: opnieuw bouwen met de applicatie als referentie

En dan het scenario dat niemand wil horen, maar dat soms de eerlijke conclusie is: de codebase is te ver heen. De technische schuld is zo diep dat elke fix drie nieuwe problemen veroorzaakt. Elke feature kost het drievoudige van wat het in een schone codebase zou kosten. In dat geval is doorontwikkelen weggegooid geld.

Maar — en dit is belangrijk — opnieuw bouwen betekent niet alles weggooien. De bestaande applicatie is een waardevolle referentie. Alle bedrijfslogica, alle flows, alle edge cases die in de loop der jaren zijn ontdekt: die kennis zit in die applicatie. Ik bouw een nieuwe, goed gestructureerde applicatie die dezelfde functionaliteit biedt, maar dan op een fundament dat wel meegroeit.

Opnieuw bouwen is niet opnieuw beginnen. Het is hetzelfde huis bouwen, maar dan met een fundering die niet scheurt.

De kosten van plakken versus investeren

Het voelt contraproductief om geld uit te geven aan iets dat je al hebt. Maar de rekening van doormodderen op een slechte codebase is verraderlijk. De kosten zijn niet zichtbaar op een enkele factuur — ze zitten verspreid over maanden van vertraagde development, gemiste deadlines, bugs die terugkomen en features die niet gebouwd kunnen worden.

Een concreet voorbeeld: als een feature in een schone codebase 40 uur kost en in de huidige codebase 120 uur, betaal je bij elke feature het verschil. Na tien features heb je het verschil in development-uren betaald dat een herbouw had gekost. Maar je hebt nog steeds dezelfde problematische codebase.

Investeren in een solide herbouw is geen kostenpost. Het is het stopzetten van een kostenlek.

Mijn aanpak bij een overname

Of het nu gaat om een directe overname, een gedeeltelijke migratie of een volledige herbouw: ik begin altijd met luisteren. Niet naar de code, maar naar jou. Wat doet de applicatie? Wat moet die doen? Waar zitten de frustraties? Wat zijn de plannen?

Daarna duik ik in de techniek. De code audit levert een eerlijk rapport op, inclusief mijn aanbeveling. Geen verkooppraatje, geen overdrijving. Als de code goed genoeg is om mee verder te gaan, zeg ik dat. Als herbouwen het eerlijke advies is, leg ik uit waarom en wat het kost.

Bij een herbouw gebruik ik de bestaande applicatie als levende specificatie. In plaats van weken te besteden aan het schrijven van requirements-documenten, heb ik een werkende referentie die exact laat zien wat de software moet doen. Dat scheelt enorm in doorlooptijd en voorkomt dat er functionaliteit verloren gaat.

Wanneer actie ondernemen

Wacht niet tot de situatie onhoudbaar is. Als je je herkent in de signalen uit dit artikel — stijgende kosten, toenemende beperkingen, het gevoel dat je software tegen je werkt — dan is nu het moment om de situatie te laten beoordelen. Hoe langer je wacht, hoe meer je investeert in een fundament dat niet deugt.

Neem contact op voor een eerlijk gesprek over de staat van je software. Geen verplichtingen, geen verkooppraatjes. Gewoon een ervaren blik op je situatie en een helder advies over de beste route vooruit.