Technische schuld: waarom elke aanpassing aan je website meer kost

Technische schuld is het werk dat je later alsnog moet doen, omdat er eerder voor een snelle of goedkope oplossing is gekozen. Het Engelse woord is technical debt. Net als bij een lening betaal je rente: elke volgende wijziging kost meer tijd, tot je de schuld aflost.

Meestal omdat er eerst iets anders opgelost moet worden. Een plugin is verouderd, een eerdere snelle oplossing zit in de weg, of niemand weet precies wat er gebeurt als je iets verandert. Elke wijziging betaalt dan rente over keuzes van vroeger. Dat is technische schuld, en het wordt elk jaar erger als je het laat liggen.

Nee. Soms is het een bewuste en verstandige keuze, bijvoorbeeld om een campagne of webshop op tijd live te krijgen. Het wordt een probleem als niemand de schuld bijhoudt en terugbetaalt. Dan stapelt de rente zich op.

Let op signalen: kleine wijzigingen die steeds langer duren, fouten die terugkomen, updates die worden uitgesteld omdat er iets stuk kan gaan, en kennis die bij één persoon zit. Kijk ook naar versies: draait je site op een PHP-versie, WordPress-versie of Laravel-versie die geen beveiligingsupdates meer krijgt, dan heb je in ieder geval achterstallig onderhoud.

Dat verschilt per situatie, maar het kost op drie manieren: tijd bij elke wijziging, risico door verouderde en onveilige software, en gemiste kansen omdat nieuwe ideeën te duur worden. Onderzoek van Stripe uit 2018 liet zien dat ontwikkelaars wereldwijd gemiddeld een derde van hun werkweek aan technische schuld besteden. Heb je geen eigen ontwikkelaar, dan zie je het terug als meer uren voor dezelfde wijziging.

Achterstallig onderhoud is één vorm van technische schuld: updates van PHP, WordPress, plugins of Laravel die zijn blijven liggen. Technische schuld zit ook in hoe de site is gebouwd: haastige oplossingen, maatwerk dat niemand meer begrijpt, of een opbouw die niet meer past. Updates installeren lost dat tweede deel niet op.

Omdat de rekening oploopt terwijl alles nog lijkt te werken. Software die geen beveiligingsupdates meer krijgt, wordt een doelwit zodra er een lek bekend wordt, zoals bij het recente PHP-lek. En hoe langer je wacht, hoe groter de stap naar een actuele versie.

Meestal niet. In de meeste gevallen los je het stap voor stap af: eerst de onveilige onderdelen, dan wat het meeste tijd kost. Opnieuw bouwen is pas logisch als de basis niet meer past bij wat je nodig hebt, of als bijwerken duurder is dan vervangen. Dat zeggen we je dan eerlijk.

Nee. We werken op een testomgeving, een kopie van je site die niet zichtbaar is voor bezoekers en Google. Pas als formulieren, betalingen en koppelingen daar werken, gaat de wijziging live.

Ja. We beginnen met in kaart brengen hoe de site of het platform in elkaar zit, welke versies er draaien en waar de risico's zitten. Daarna weet je wat je hebt en wat er nodig is, ook als er geen documentatie is.

Vertaal het naar geld en risico: hoeveel langer duren wijzigingen nu dan een jaar geleden, welke onderdelen krijgen geen beveiligingsupdates meer, en wat kost een storing of datalek. Een overzicht met prioriteiten en kosten per stap maakt de keuze concreet.