Een platform dat alleen nog onderhouden kon worden, weer doorontwikkelbaar maken.
De software werkte, maar veranderen was riskant. De vorige ontwikkelpartij deed geen reguliere ontwikkeling meer en greep alleen nog in wanneer iets kapotging. Wij begonnen niet met alles opnieuw bouwen. Eerst moesten we begrijpen wat er stond, wat goed was en waar de echte technische blokkades zaten.
Case in het kort
Van onderhoudsmodus naar actieve doorontwikkeling
Van circa 10% naar 92%
Refactor, tests, monitoring en technische grip
Jarenlange doorontwikkeling op dezelfde basis
Waar liep het vast?
Het platform bestond uit meerdere apps, webomgevingen en een omvangrijke backend. Er zat veel waarde in de bestaande software, maar de technische schuld maakte nieuwe ontwikkeling steeds moeilijker. Voordat we iets veranderden, hebben we daarom eerst de bestaande code en architectuur systematisch onderzocht.
Bekijk de aanpakNieuwe ontwikkeling was praktisch stilgevallen
De vorige ontwikkelpartij deed geen reguliere development meer. Alleen wanneer iets daadwerkelijk kapotging werd nog ingegrepen. Het platform draaide, maar kwam technisch nauwelijks meer vooruit.
De backend was moeilijk te doorgronden
Functionaliteit was verdeeld over meerdere Elixir-apps binnen een umbrella-structuur. Namen als old, new, v2 en v3 leefden naast elkaar, documentatie ontbrak op belangrijke plekken en verschillende ontwikkelstijlen en conventies maakten moeilijk zichtbaar welke code nog leidend was.
Kritieke code was nauwelijks afgedekt
In een belangrijk backendonderdeel maten we bij de start ongeveer 10% line coverage op circa 3.400 regels code. Andere onderdelen hadden eveneens beperkte of vrijwel geen testdekking. Daardoor kon een wijziging ongemerkt bestaande functionaliteit breken.
Hoe hebben we het aangepakt?
- 01
Eerst het systeem begrijpen
We brachten architectuur, actieve functionaliteit, databases, parsers, integraties en infrastructuur in kaart. Niet met de aanname dat alles vervangen moest worden, maar om te bepalen wat goed was en waar verandering werkelijk nodig was.
- 02
Feedback en monitoring organiseren
We richtten onder andere coverage-metingen, error monitoring en een acceptatieomgeving in. Daardoor werd sneller zichtbaar wat wijzigingen deden en hoefden problemen niet pas via gebruikers of handmatige controles ontdekt te worden.
- 03
Gericht refactoren en testen
We verwijderden ongebruikte code, brachten meer structuur en conventies aan en verbeterden onderdelen zodra we ze voldoende begrepen. Tegelijk bouwden we de automatische tests systematisch uit.
- 04
Daarna weer verder ontwikkelen
Naarmate de codebase beter bekend, getest en beheersbaar werd, konden we opnieuw features ontwikkelen en grotere technische verbeteringen uitvoeren zonder iedere wijziging als een gok te behandelen.
Wat hebben we gebouwd?
Het belangrijkste resultaat was een professionele technische basis onder een bestaand product. We maakten de backend explicieter, testbaarder en beter te beheren zonder werkende onderdelen onnodig te vervangen.
Een backend die we daadwerkelijk begrepen
We onderzochten en verbeterden de code totdat duidelijk was welke onderdelen waarvoor verantwoordelijk waren. Oude, dubbele of onduidelijke implementaties konden vervolgens gericht worden verwijderd of verbeterd.
Tests als veiligheidsnet
Test coverage werd onderdeel van de normale ontwikkelworkflow. De relevante backendcode groeide van circa 10% coverage bij de start naar 92%, met tests op de onderdelen waar die daadwerkelijk waarde toevoegden.
Professionele engineering rond de code
Naast de code zelf verbeterden we ook de omgeving eromheen, waaronder error monitoring, coverage tooling, acceptatie, infrastructuur en het technische beheer dat nodig is om een productieplatform verantwoord verder te ontwikkelen.
Wat veranderde er?
Van circa 10% naar 92% test coverage
De belangrijkste backendcode begon met ongeveer 10% line coverage. Tijdens de professionalisering brachten we de testdekking naar 92%. Daardoor konden wijzigingen veel sneller en met aanzienlijk meer zekerheid worden gecontroleerd.
Nieuwe ontwikkeling kwam weer op gang
Het platform bleef niet steken in onderhoud. In de jaren daarna ontwikkelden we veel nieuwe functionaliteit en voerden we grotere technische verbeteringen door op dezelfde codebase.
De basis werd sterk genoeg voor nieuwe technologie
De technische basis werd stabiel en begrijpelijk genoeg om verder te vernieuwen. Zo trainden we later onder andere een eigen machine-learningmodel om aanbiedingen automatisch te herkennen in PDF's van winkelfolders.
Bewijs
De vooruitgang was niet alleen zichtbaar in schonere code. We konden hem meten en daarna jarenlang in de praktijk bewijzen door het platform verder uit te bouwen. De oorspronkelijke analyse liet bovendien zien dat niet alles slecht was. Onderdelen van infrastructuur, schaalbaarheid en performance stonden al behoorlijk. Daarom kozen we voor gericht professionaliseren in plaats van automatisch alles opnieuw bouwen.
Bekijk cases10% → 92% line coverage
Bij de start had een belangrijk backendonderdeel circa 3.400 regels code en bijna 10% line coverage. Uiteindelijk kwam de relevante backendcode op 92% test coverage.
Van break-fix naar jarenlang nieuwe features
Voor de overname was afgesproken dat de vorige ontwikkelpartij alleen nog zou ingrijpen als iets kapotging. Na de professionalisering hebben we het platform jarenlang verder ontwikkeld met nieuwe functionaliteit en technische verbeteringen.
Later zelfs eigen machine learning
Een van de latere ontwikkelingen was een zelfgetraind model voor het herkennen van aanbiedingen in PDF-winkelfolders. Een goed voorbeeld van hoeveel technische ruimte er na de overname en professionalisering weer was ontstaan.
Gerelateerde AI-vraagstukken
Een andere leverancier heeft iets achtergelaten waar we niet goed mee verder kunnen
Er staat software, maar kennis, documentatie of technische grip ontbreekt nadat een andere partij vertrokken is.
Bekijk vraagstukOns eigen developmentteam loopt technisch vast
Het team kan prima software bouwen, maar mist specifieke senior ervaring om een lastig AI-probleem technisch goed op te lossen.
Bekijk vraagstukWe willen van prototype naar een onderhoudbaar softwareproduct
De kern werkt, maar de software moet zo worden opgebouwd dat een team hem ook over zes of twaalf maanden nog veilig kan veranderen.
Bekijk vraagstukVibe Code Rescue Audit
We onderzoeken wat er staat, waar de echte technische risico's zitten en wat behouden, gerepareerd of vervangen moet worden.
Bekijk aanbod€2.950 excl. btw
- Resultaat
- Technische analyse met concreet rescueplan
- Doorlooptijd
- Vaste scope
- Volgende stap
- Daarna weet je of een Rescue Sprint of grotere aanpak nodig is