Technische schuld in euro's — wat het je echt kost

Technische schuld in euro's — wat het je echt kost

Elke week vertraging bij een nieuwe feature kost gemiddeld €2.400. Dat getal berekenden wij voor een klant die klaagde dat zijn developers "zo langzaam" waren. Het lag niet aan de developers.

Het lag aan acht jaar technische schuld die zich had opgestapeld tot een codebasis waar niemand nog zonder angst in durfde te werken.

Wat je leert in dit artikel

• Hoe je technische schuld concreet in euro's berekent
• Welke vormen van technische schuld het meest kosten
• Hoe je het kunt kwantificeren zonder engineering-achtergrond
• Een plan van aanpak om het om te keren

Wat is technische schuld eigenlijk

Technische schuld is de optelsom van shortcuts die je hebt genomen. Soms bewust — "we doen het nu snel, later beter". Vaker onbewust — niemand wist dat het later problemen zou geven.

Elke shortcut heeft rente. Die rente betaal je niet eenmalig, maar iedere maand opnieuw. In de vorm van:

• Langere development tijd voor nieuwe features
• Meer bugs in productie
• Hogere kosten voor het oplossen van die bugs
• Developers die gefrustreerd zijn en vertrekken
• Klanten die weglopen door instabiliteit

De schuld zelf los je niet op door er omheen te werken. Die groeit gewoon door.

Hoe je het berekent

We gebruiken een eenvoudig model. Je hoeft geen engineer te zijn om het te begrijpen.

Stap 1: meet de velocity.

Hoeveel features levert je team per sprint op? Als je een scrum-team hebt, kijk dan naar de story points of het aantal features in de afgelopen 6 maanden. Noteer de trend: gaat het omhoog, omlaag, of staat het stil?

Stap 2: bereken de opportunity cost.

Wat is een gemiddelde feature waard? Denk aan: hogere conversie, tijdsbesparing voor de operations, nieuwe inkomsten. Stel het is €3.000 gemiddeld per feature. Als je team 20% minder features oplevert dan een jaar geleden, mis je 0,2 × €3.000 = €600 per feature-slot per sprint.

Stap 3: tel de bug-kosten.

Hoeveel tijd gaat er per maand in bugs zitten? Tel developer-uren (gemiddeld €100-150/uur bij een bureau of €60-80/uur bij een interne developer). Voeg klantenservice-uren toe. Voeg eventuele downtime-kosten toe.

Stap 4: tel de onboarding-kosten.

Een nieuwe developer die instroomt in een codebasis met hoge technische schuld, is 2-3 maanden minder productief dan normaal. Bij een gemiddeld developer-salaris van €4.500/maand kost dat €9.000-13.500 per nieuwe developer.

Een rekenvoorbeeld

Een middelgrote webshop met 5 developers. De codebasis is 6 jaar oud, nooit grondig gerenoveerd.

€236.400 per jaar. Dat was de technische schuld van deze klant, uitgedrukt in geld. Het team van 5 kostte €50.000/maand. Bijna 40% van de loonkosten verdween in het beheer van de eigen rommel.

De vijf duurste vormen van technische schuld

1. Geen of slechte tests

Code zonder tests is code die je niet durft aan te raken. Elke wijziging is een gok. Dat maakt developers langzamer — niet omdat ze lui zijn, maar omdat ze handmatig moeten verifiëren wat een test in seconden zou kunnen doen.

Richtlijn: onder 60% testdekking begint het pijn te doen. Onder 30% is elke release een risicomoment.

2. Verouderde dependencies

Een pakket dat 3 jaar niet geüpdated is, is een beveiligingsrisico en een compatibiliteitsprobleem. Updaten kost tijd. Niet updaten kost meer tijd — namelijk wanneer je een kritieke update niet kunt uitstellen maar de upgrade een week werk blijkt.

3. God objects en spaghetti-code

Een klasse die 2.000 regels heeft en "alles doet" is een teken dat niemand ooit nee heeft gezegd. Elke feature die erin komt, vergroot het probleem. Elke bug erin is moeilijk te isoleren.

4. Geen documentatie

"We weten hoe het werkt" is geen documentatie. Als de developer die iets heeft gebouwd vertrekt, ben je €5.000-15.000 kwijt aan uitzoekwerk. We hebben dit meerdere keren gezien bij overnames van codebases.

5. Inconsistente architectuur

Drie manieren om hetzelfde te doen in dezelfde codebase. Dat betekent dat iedere developer een andere keuze maakt, bugs op drie plaatsen kunnen zitten, en nieuwe developers niet weten welke aanpak "de juiste" is.

Hoe je technische schuld aanpakt zonder alles te stoppen

De vraag die we altijd krijgen: "Maar we kunnen niet stoppen met nieuwe features. Wat dan?"

Het antwoord is: de boy scout regel. Laat de code altijd iets beter achter dan je hem aantrof. Niet perfect — iets beter.

Concrete aanpak:

20% van elke sprint reserveren voor technische verbetering. Niet als extraatje als er tijd over is, maar als vaste afspraak. Dit is moeilijk te verkopen aan stakeholders. De manier om het te framen: "We investeren 20% van de development-capaciteit in het verlagen van onze operationele kosten." Schrijf tests voor code die je aanraakt. Je hoeft de hele codebase niet in één keer te coveren. Maar elke module die je aanpast, lever je op met tests. Na twee jaar heb je automatisch dekking op de plekken die het meest veranderen. Refactor op basis van pijn, niet op basis van principes. Begin niet met een architecturale redesign van modules die niemand aanraakt. Begin met de code die elke sprint problemen veroorzaakt. Maak schuld zichtbaar. Houd bij welke modules de meeste bugs produceren. Dat zijn de prioriteiten. Een heatmap van bugs per module geeft stakeholders een concreet beeld.

Wanneer is een herschrijving de juiste keuze

Soms is refactoring niet genoeg. Als de architectuur fundamenteel verkeerd is — denk aan een monoliet die ooit voor 100 gebruikers is gebouwd en nu 100.000 bedient — kan een herschrijving goedkoper zijn dan doormodderen.

Signalen dat een herschrijving serieus is:

• Features duren 5× langer dan normaal door de bestaande code
• Developers weigeren verantwoordelijkheid te nemen voor modules
• Elke deploy is een risicomoment
• De codebase heeft geen tests en niemand durft die toe te voegen

Herschrijvingen kosten €50.000-€500.000+ afhankelijk van de omvang. Dat is een grote investering. Maar als de technische schuld €20.000/maand kost, is de terugverdientijd van een €200.000 herschrijving 10 maanden.

Conclusie

Technische schuld is geen abstract engineering-concept. Het is een maandelijkse factuur die je betaalt zonder dat het op de rekening staat. Door het te kwantificeren in euro's kun je het gesprek voeren dat nodig is: met management, met investors, met jezelf.

De eerste stap is meten. Bereken de velocity-trend, tel de bug-uren, bereken de opportunity cost. Dan heb je een getal om mee te werken.

Wil je weten wat de technische schuld van jouw platform kost? Neem contact op voor een vrijblijvende analyse. We kijken ook graag naar de totale eigendomskosten — lees daarvoor ons artikel over de TCO van een webshop.

Dit geldt voor elk platform: Magento, Shopify of Laravel maatwerk. De oplossing verschilt, het probleem is universeel.

---

Veelgestelde vragen

Hoe weet ik of mijn codebase hoge technische schuld heeft?

Vraag je developers: "Hoe lang duurt het gemiddeld om een nieuwe feature te bouwen die vorig jaar 2 dagen kostte?" Als het antwoord "3-4 dagen" is, heb je te maken met structurele vertraging. Een andere indicator: hoeveel van de development-tijd gaat naar bugs versus nieuwe features?

Kun je technische schuld volledig elimineren?

Nee, en dat hoeft ook niet. Enige technische schuld is onvermijdelijk — soms is een snelle oplossing de juiste keuze. Het doel is niet nul schuld, maar beheerde schuld: je weet waar hij zit, wat hij kost, en je hebt een plan om hem te verminderen.

Is technische schuld altijd de schuld van de developers?

Nee. In de meeste gevallen is het het resultaat van externe druk: te krappe deadlines, te veel features tegelijk, geen budget voor onderhoud. Developers die technische schuld maken, doen dat zelden omdat ze lui zijn.

Hoe verkoop ik technische schuld-reductie aan management?

Met geld. Bereken de maandelijkse kosten zoals hierboven beschreven. Presenteer het als: "We betalen €X per maand aan rente op technische schuld. Door Y te investeren, verlagen we die maandelijkse kosten met Z." Dat is een businesscase, geen engineeringwens.

Hoe lang duurt het om technische schuld terug te dringen?

Met 20% sprint-capaciteit: 12-18 maanden om een middelgrote codebase substantieel te verbeteren. Niet perfect — maar functioneel en beheersbaar. Grotere codebases of fundamentelere problemen vereisen meer tijd of een gerichte refactor-sprint.