Technische schuld
Je engineers zeggen "technische schuld". Je boekhouder ziet niets.
Technische schuld kost een softwarebedrijf meestal 20 tot 40 procent van zijn engineeringcapaciteit, en een review van technische schuld zet daar per post een maandprijs op, zodat aflossen een bedrijfsbeslissing wordt in plaats van een klacht van engineering.
Schuld die nooit op een resultatenrekening verschijnt, wordt nooit afgelost. De oplossing is geen herbouw. Het is een prijs: wat elke schuldpost je per maand kost, in engineeruren, cloudkosten, incidenten en gemiste releases, naast wat ze eenmalig kost om op te lossen.
Waar de maandfactuur zich verstopt
Schuld verschijnt zelden als één lijn. Ze factureert je op 5 plaatsen, en maar één daarvan staat op een factuur.
- De levertaks. Elke feature die rond dezelfde fragiele modules moet, duurt 1,5 tot 3 keer langer dan nodig.
- De incidentenlast. Storingen op dezelfde gekende zwakke plekken, plus de onderbrekingen die ze veroorzaken. Bij een middelgroot team 1 tot 3 engineerdagen per week.
- De verspilde infrastructuur. Dubbele opslag, te grote clusters, een pipeline die niemand durft aan te raken. In één opdracht kostte één pipeline EUR 12 000 per maand.
- De sleutelfiguur. Maar één persoon kan de module aanpassen, dus zijn agenda is de roadmap. Onzichtbaar tot hij opzegt.
- De rem op aanwerven. Goede engineers lezen de codebase in week 1 en blijven stilletjes korter.
Technische schuld heeft een maandkost werkt elke vorm uit met grootteordes.
Er een getal op zetten
Vergeet de scores voor codekwaliteit. Ze meten wat tools kunnen tellen, niet wat de zaak betaalt. Schrijf in de plaats het schuldgrootboek: de 10 concrete schuldposten waar je engineers echt over klagen, elk met 2 getallen. Wat laten liggen per maand kost, in verloren uren, incidenten en infrastructuur. En wat oplossen eenmalig kost, in engineerweken tegen je volledige loonkost.
Wat je zo niet kan prijzen, is meestal een voorkeur die zich als schuld voordoet. "Het framework is oud" is geen schuld. "Upgraden zit vast, dus elke beveiligingspatch kost een week" is dat wel, en het heeft een getal. Dan is de regel eenvoudig: los een schuldpost af als de maandprijs binnen een jaar of zo groter is dan de eenmalige prijs. Een post die EUR 12 000 per maand kost en EUR 60 000 om op te lossen, verdient zich in 5 maanden terug. Dat is een gewone investeringsbeslissing, geen technische discussie.
Voor wie dit is
Founders, CEO's, CFO's en eigenaars die "technische schuld" blijven horen als reden voor schuivende deadlines en stijgende facturen, en niet kunnen inschatten of het klopt. Scale-ups met 15 tot 120 engineers, en kmo's met een eigenaar aan het hoofd en 5 tot 40 mensen in en rond software, of een agency die ze voor hen bouwt.
- Elke schatting komt met "maar eerst moet die module herschreven worden".
- Engineers vragen tijd voor refactoring en je kan die vraag niet beoordelen.
- Hetzelfde incident komt elk kwartaal terug.
- Er is maar één iemand die een kernsysteem durft aan te raken.
Voor wie het niet is
- Je wil een herbouw laten goedkeuren. De review concludeert vaak het omgekeerde, en zegt dat ook.
- Je wil een score voor codekwaliteit voor op een slide. Een tool doet dat goedkoper.
- Het product wordt binnenkort uitgefaseerd. Die schuld kost niets om te houden.
- Je zoekt iemand om de refactoring te doen. Je engineers doen het werk; ik prijs het en leg de volgorde vast.
Wanneer er gebeld wordt
- Er ligt een voorstel om te herbouwen op tafel, met een schatting van 9 maanden en geen business case.
- De levering vertraagde terwijl het team groeide.
- De lead developer die het oude systeem begrijpt, heeft zijn opzeg gegeven.
- Een ERP, een platform of een klantenportaal staat op de lijst om te herbouwen, en niemand kan zeggen wat het oude kost om te houden.
- Een koper of een investeerder gaat onder de motorkap kijken. Dat is technische due diligence, van de andere kant van de tafel.
- De cloudfactuur blijft stijgen, en een deel ervan is een architectuur die niemand bewust koos. Zie cloudkosten verlagen.
Hoe een review van technische schuld loopt
Het schuldgrootboek is deel van de diagnose van 3 weken: EUR 9 500, vast, afgesproken voor het werk begint.
| Wanneer | Werk |
|---|---|
| Week 1 | Gesprekken met elke engineer en met wie de leveranciers opvolgt. 6 maanden pull requests, incidenten en doorlooptijden gelezen. De cloud- en leveranciersfacturen. Een eerste lijst van de schuldposten die mensen echt noemen. |
| Week 2 | Elke post geprijsd: wat laten liggen per maand kost, wat oplossen eenmalig kost, getoetst aan de leverdata in plaats van aan meningen. Voorkeur gescheiden van schuld. |
| Week 3 | Het gerangschikte grootboek, een volgorde om af te lossen, de posten die je bewust houdt, en een geschreven rapport. Een werksessie met jou en de lead engineer. |
Na de diagnose
Het team lost de schuld af binnen de gewone levering, gerangschikt op terugverdientijd, niet in een apart refactoringkwartaal dat nooit eindigt. Wil je dat iemand de volgorde bewaakt, dan blijf ik 1 tot 2 kwartalen, een paar dagen per maand of 1 tot 2 dagen per week, afhankelijk van de grootte van het team.
Hoe het eindigt
Het grootboek krijgt een eigenaar, meestal de lead engineer, en elk kwartaal een update in de agenda. Nieuwe schuld komt erop met haar 2 getallen, voor iemand erover begint te discussiëren. Als het grootboek zonder mij draait, vertrek ik.
Wat het kost
De diagnose kost EUR 9 500, vast. Tijd daarna wordt gefactureerd aan dagtarieven in de normale West-Europese band van EUR 1 000 tot EUR 1 600, maandelijks. Geen equity, geen succesfee. Vindt de review schuld die goedkoper is om te houden dan om op te lossen, dan staat dat ook in het rapport, en dat is een van de redenen waarom de prijs niet afhangt van wat er opgelost wordt.
Wat het grootboek heeft opgeleverd
- Cloudfactuur min 42 procent. Een pipeline die elk tussenresultaat 3 keer opsloeg, kostte EUR 12 000 per maand. Zodra dat op papier stond, was oplossen geen technisch debat meer. Van EUR 74 000 naar EUR 43 000 per maand in 5 maanden, zonder ontslagen en zonder herbouw.
- Van 45 naar 22 engineers. Series B SaaS, releases die bleven schuiven, 2 platformteams die infrastructuur onderhielden voor klanten aan wie het bedrijf niet meer verkocht. Na 4 maanden opnieuw wekelijkse releases, loonkost van EUR 4 000 000 naar EUR 2 000 000.
- Het portaal geleverd in 11 weken. Kmo met eigenaar aan het hoofd, 60 mensen, achttien maanden leveranciersvertraging. Twee derde van het portaal bestond al; de rest zat vast op beslissingen, niet op code. EUR 180 000 per jaar van de agencyfactuur.
Een schuldreview, een tool voor codekwaliteit of een refactoringbudget
| Optie | Waar het goed in is | Waar het stopt |
|---|---|---|
| Een tool voor codekwaliteit | Telt complexiteit, duplicatie en verouderde dependencies. Goedkoop, continu, nuttig voor engineers. | Ze meet wat tools kunnen tellen, niet wat de zaak betaalt. Een rode score zegt niet welke schuld geld kost. |
| Een vast refactoringbudget | Geeft het team een deel van elke sprint en stopt de discussie een tijdje. | Niemand checkt wat de tijd opbracht. Ze gaat naar de schuld die engineers het vervelendst vinden, niet naar de duurste. |
| Een geprijsde schuldreview | Een maandprijs en een oplossingskost per post, gerangschikt op terugverdientijd, met de posten die je houdt benoemd. | Ze werkt in grootteordes, niet tot op de euro. Ze heeft een eigenaar nodig om actueel te blijven. |
De drie gaan goed samen. De review legt de rangorde vast, het budget betaalt ze, en de tool houdt nieuwe schuld zichtbaar.
Waar het past
Dezelfde lens stuurt de cloudkostenreview en de technische due diligence. Dezelfde methode, een andere koper. Het hoort bij platformkosten en technische schuld in het overzicht van de diensten, en het is een van de resultaten van de diagnose van 3 weken. Voor de cloudkant van het grootboek lees je AWS-kosten verlagen is een eigenaarschapsprobleem. Voor kmo's waar de schuld bij een leverancier zit, beschrijft de kmo die per ongeluk een softwarebedrijf werd het patroon.
Veelgestelde vragen
Wat kost technische schuld per maand?
Bij een doorsnee softwarebedrijf slorpt technische schuld 20 tot 40 procent van de engineeringcapaciteit op. Bij 20 engineers in België, met een volledige loonkost rond EUR 2 000 000 per jaar, is dat EUR 35 000 tot EUR 65 000 per maand, nog voor de infrastructuur die ze verspilt of de incidenten die ze veroorzaakt.
Hoe zet je een getal op technische schuld?
Elke schuldpost die ertoe doet, duikt ergens meetbaar op: de feature die 6 weken duurt in plaats van 2, het incident dat elk kwartaal terugkeert, het systeem dat maar één iemand durft aan te raken, de cloudfactuur opgeblazen door een architectuur die niemand bewust heeft gekozen. Ze uit de leverdata en de facturen lezen, maakt er een maandkost van, in engineeruren, cloudkosten en gemiste releases.
Wat is een review van technische schuld?
Een gestructureerde lezing van de codebase, de leverdata en de facturen die eindigt in een grootboek: elke schuldpost met wat laten liggen per maand kost en wat oplossen eenmalig kost, gerangschikt op terugverdientijd. Ze is deel van de diagnose van 3 weken, voor EUR 9 500, vast. Ze eindigt met een geschreven rapport, niet met een slide vol scores.
Wat verandert er zodra technische schuld geprijsd is?
Het gesprek verandert van eigenaar. Het stopt een klacht van engineering te zijn en wordt een lijn die de CEO kan rangschikken: deze post kost EUR 15 000 per maand en is in zes weken afgelost, die andere kost EUR 2 000 en kan wachten. Sommige schuld is het waard om te houden. Het rapport zegt welke, op papier, zodat de beslissing van het bedrijf is en gedocumenteerd.
Wanneer los je technische schuld af?
Wanneer wat laten liggen per maand kost, binnen een jaar of zo meer is dan wat oplossen eenmalig kost. Schuld in code die binnenkort vervangen wordt, kost niets om te houden. Schuld met een sleutelfiguur- of veiligheidsrisico kan het waard zijn om vroeger op te lossen.
Is herbouwen het antwoord op technische schuld?
Zelden. Een herbouw ruilt gekende schuld in voor ongekende schuld en legt de levering maandenlang stil. De meeste grootboeken tonen een handvol posten die zich binnen het jaar terugbetalen en die binnen de gewone levering op te lossen zijn. Herbouwen is juist als het oude systeem de zaak blokkeert en het grootboek geen goedkopere uitweg toont.
Wie doet het werk na de review?
Je eigen engineers, of je leverancier onder een herschreven scope. Ik schrijf geen productiecode. Ik prijs de schuld, leg met jou de volgorde vast, en bewaak die als je dat wil, tot de lead engineer het grootboek zelf bezit.