Wanneer herbouw je een digitaal product en wanneer refactor je het?

Het gesprek komt in elk team vroeg of laat voor. De technische schuld stapelt zich op, nieuwe features kosten drie keer zoveel tijd als gepland, en iemand gooit het eruit: "Kunnen we dit niet gewoon opnieuw bouwen?"

Dat gevoel is begrijpelijk. Maar herbouwen is duur, riskant en duurt altijd langer dan verwacht. En refactoren op de verkeerde plek is geld weggooien aan een systeem dat toch niet meer te redden is.

Bij Livewall bouwen en verbeteren we digitale producten voor merken als KLM, AvroTros en Decathlon. We kennen beide scenario's van binnenuit. Wat we hebben geleerd: de keuze draait niet om technische voorkeur, maar om een handvol concrete vragen die je eerlijk moet beantwoorden.

Begin met de businessvraag, niet de technische klacht

De meeste gesprekken over herbouwen beginnen bij de technologie: een verouderd framework, een moeilijk te onderhouden codebase, een architectuur die niemand meer begrijpt. Maar technische frustratie is zelden het echte probleem.

De vraag die er echt toe doet: kan dit systeem leveren wat het bedrijf nodig heeft in de komende twee tot drie jaar?

Als het antwoord ja is, ook al zijn er belemmeringen, dan is refactoren bijna altijd de slimmere keuze. Als het antwoord nee is, dan is dat je echte argument voor herbouwen.

Wat wij zien in de praktijk: teams besluiten tot herbouwen op basis van technische ergernissen, terwijl de onderliggende businesslogica en de gebruikersflows prima zijn. Het resultaat is een splinternieuw systeem dat precies dezelfde problemen oplevert, maar dit keer met een volledig leeg trackrecord.

De vijf vragen die de keuze bepalen

1. Blokkeert de architectuur nieuwe functionaliteit?

Er is een verschil tussen trage ontwikkeling en geblokkeerde ontwikkeling. Als features structureel niet kunnen worden gebouwd vanwege fundamentele architectuurkeuzes, dan is dat een signaal voor herbouwen. Als features alleen traag gaan, is dat bijna altijd oplosbaar met gerichte refactoring.

2. Zijn er kritieke beveiligings- of schaalbaarheidsrisico's?

Sommige systemen draaien op verouderde infrastructuur die niet veilig te updaten is zonder de gehele architectuur aan te raken. Als je een platform hebt dat bij piekverkeer omvalt of dat fundamentele beveiligingsproblemen heeft die niet lokaal te repareren zijn, is herbouwen verdedigbaar.

3. Begrijpt het huidige team het systeem nog?

Kennis die alleen in hoofden zit is gevaarlijk, maar het kan worden gedocumenteerd en overgedragen. Als niemand meer begrijpt hoe het systeem werkt en documentatie ontbreekt volledig, dan stijgen de onderhoudskosten exponentieel. Dat is een serieuze indicator.

4. Hoe groot is het risico van verlies van bedrijfskritieke logica?

Jaren van edge cases, gebruikersfixes en bedrijfslogica zitten vaak verborgen in een bestaand systeem. Bij herbouwen verdwijnt dat. We zien dit regelmatig: een nieuw systeem dat na launch problemen introduceert die het oude systeem allang had opgelost, alleen stilletjes.

5. Wat is de tijdshorizon en de businessdruk?

Herbouwen duurt langer dan teams inschatten, altijd. Als er businessdruk is om binnen zes maanden te leveren, is een volledige rebuild bijna nooit haalbaar zonder concessies te doen aan kwaliteit. Gerichte refactoring is dan de realistischere optie.

Wanneer refactoren de juiste keuze is

Refactoren werkt goed wanneer het product functioneel gezond is maar technisch verouderd. Concrete signalen:

• De kernfunctionaliteit werkt zoals verwacht door gebruikers
• Problemen zijn lokaliseerbaar en herhaalbaar
• Het team kan aangeven welke modules het meest problematisch zijn
• De businesslogica is waardevol en goed begrepen

In zulke situaties is een modulaire refactoring-aanpak effectief: werk van buiten naar binnen, begin bij de meest pijnlijke onderdelen, en valideer continu met gebruikers. Dit is ook hoe we webapplicatie-ontwikkeling benaderen bij Livewall: iteratief, risicogestuurd en met aandacht voor wat het bestaande systeem al goed doet.

Een concreet voorbeeld: de Sportvisunie community is gedurende de levensduur van het platform meerdere keren verbeterd zonder volledige herbouw. De kern van de community-functionaliteit bleef intact terwijl de technische stack geleidelijk werd gemoderniseerd.

Wanneer herbouwen gerechtvaardigd is

Er zijn situaties waarin herbouwen de enige eerlijke keuze is. Voorbeelden:

Fundamentele architectuurmismatch. Sommige systemen zijn zo opgebouwd dat de kernarchitectuur letterlijk in de weg staat van wat het product moet worden. Een monolithisch systeem dat over moet naar een multi-tenant architectuur, of een legacy systeem dat diepe API-integraties vereist die de huidige opzet niet toelaat.

Technologie die buiten onderhoud valt. Als de gebruikte technologie geen actieve community of vendor support meer heeft, dan is refactoren bouwen op drijfzand.

Het product verandert fundamenteel van doelstelling. Soms is een nieuw product simpelweg het eerlijkste antwoord. Niet omdat het bestaande systeem slecht is, maar omdat de businessvereisten zo fundamenteel zijn veranderd dat de match er niet meer is.

De AvroTros Eurovision-app is een goed voorbeeld van een product waarbij de schaalvereisten, de live-omgeving en de gebruiksintensiteit de basis legden voor een bewuste keuze voor een nieuwe architectuur vanaf het begin.

De valkuil van het hybride traject

Een patroon dat we regelmatig zien: teams kiezen voor een herbouw maar proberen ondertussen het bestaande systeem draaiende te houden. Dat lijkt veilig, maar het is bijna altijd de duurste optie. Twee systemen parallel onderhouden, twee sets bugs oplossen, twee keer onboarden.

Als je besluit te herbouwen, wees dan helder over de migratiedatum en werkt naar die datum toe. Onzekerheid over de overgang zorgt voor halfslachtige keuzes aan beide kanten.

Een goede digitale strategie helpt bij het structureren van die beslissing: wat gaat wanneer over, welke data moet worden gemigreerd, en wat is het vangnet als de planning uitloopt. Dat geeft teams de ruimte om de juiste keuze te maken in plaats van de veilige keuze.