Elke startup heeft technische schuld, en het meeste ervan was de juiste keuze. De vraag is niet hoe je die wegwerkt — het is welke delen rente vragen die je je niet meer kunt veroorloven.
Vertraging
Operationeel risico
Schuldregister
Technische schuld heeft een slechte naam die zij niet helemaal verdient. Een kortere weg nemen om een idee sneller te valideren is meestal juist — het alternatief is zorgvuldig bouwen aan iets wat niemand wilde. De fout is niet het aangaan van de schuld; het is nooit het rentepercentage controleren.
De vier soorten, en maar twee doen ertoe
| Soort | Voorbeeld | Oordeel |
|---|---|---|
| Bewust en kortlevend | Hardgecodeerde logica om vraag te testen, daarna verwijderd | Juist — zo werkt het gereedschap |
| Bewust en permanent | Bewust genomen kortere weg, nooit herzien | Gevaarlijk — de rente stapelt zich stilletjes op |
| Onbedoeld | Niemand kende destijds een betere manier | Normaal — repareren zodra het begint te kosten |
| Cosmetisch | Naamgeving, opmaak, structuurvoorkeuren | Volledig negeren |
Hoe je merkt dat het te veel is geworden
Er is geen absolute drempel; schuld is alleen betekenisvol ten opzichte van wat je probeert te doen. Maar deze signalen wijzen betrouwbaar op onbetaalbaar geworden rente:
- Schattingen blijven groeien voor features van vergelijkbare omvang — het duidelijkste kwantitatieve signaal
- Het team zegt routinematig «dat kan niet met de huidige opzet» over gewone verzoeken
- Bugs clusteren zich telkens weer in dezelfde modules
- Een nieuwe engineer inwerken duurt maanden in plaats van weken
- Mensen mijden bepaalde bestanden, en iedereen weet welke
- Deployments worden gebundeld en ingepland omdat ze riskant zijn
Wat aflossen, en wanneer
Schuld is het aflossen waard wanneer die iets specifieks blokkeert, niet uit principe. Drie regels die werken:
- Los schuld af die op de weg vooruit ligt. Lopen de komende twee kwartalen door een module, ruim die dan op voordat je er bouwt. Schuld in code die je niet aanraakt kost niets.
- Los schuld die geld, data of authenticatie raakt onmiddellijk af, ongeacht de roadmap — fouten daar zijn onherstelbaar in plaats van slechts irritant.
- Refactor opportunistisch. Verbeter wat je toch al wijzigt in plaats van aparte opruimprojecten in te plannen, die onder druk als eerste sneuvelen.
Het budget dat werkt
Geen universeel onderhoudspercentage houdt schuld automatisch stabiel. Plan capaciteit op basis van risico's en roadmap en herzie die. Herschrijven is een optie om te beoordelen, niet de vaste audituitkomst.
Het doel is niet nul technische schuld. Het is schuld die je koos, waarvan je weet, en die je zou kunnen aflossen als de roadmap dat vroeg.
Wat je investeerders vertelt
Oprichters proberen schuld vaak te verbergen tijdens due diligence. Dat werkt averechts: de diligence vindt hem, en de ontdekking kost in de onderhandeling meer dan openheid zou hebben gekost. De sterkere positie is een geschreven register — welke schuld er is, wat die blokkeert, wat herstel kost. Een team dat dat kan verwoorden komt over als competent; een team dat een schone codebase claimt komt over als naïef of ontwijkend.
Technische schuld met bewijs prioriteren
Codereview onderzoekt implementatie; architectuurreview grenzen en werking. Begin met een bedrijfsbeslissing: ondersteunt het systeem de volgende release of meer klanten? Beoordeel gevolg, waargenomen frequentie en herstelwerk. Behandel actieve beveiligings- of gegevensproblemen afzonderlijk als urgent.
| Maak de beslissing meetbaar | Spreek vooraf het bewijs af |
|---|---|
| Vertraging | Verbind een wijziging met modules, reviewwachttijd en testgaten. Vergelijk soortgelijke wijzigingen voor en na herstel. |
| Operationeel risico | Onderzoek incidenten, traces en herstelresultaten. Ontbrekende toegang betekent ongeverifieerd, niet geslaagd. |
| Schuldregister | Noteer bewijs, geraakt pad, eigenaar, inspanningsbandbreedte en een test die herstel aantoont. |
Geen universeel onderhoudspercentage houdt schuld automatisch stabiel. Plan capaciteit op basis van risico's en roadmap en herzie die. Herschrijven is een optie om te beoordelen, niet de vaste audituitkomst.
Veelgestelde vragen
Hoeveel technische schuld is normaal voor een startup?
Een aanzienlijke hoeveelheid, en dat is meestal juist — snelheid in de vroege fase is meer waard dan vroege afwerking. Het probleem is niet de hoeveelheid maar of die bekend en bewust is, en beperkt tot gebieden die de roadmap niet blokkeren en geen geld of data raken.
Welk percentage engineeringtijd hoort naar technische schuld te gaan?
Geen universeel onderhoudspercentage houdt schuld automatisch stabiel. Plan capaciteit op basis van risico's en roadmap en herzie die. Herschrijven is een optie om te beoordelen, niet de vaste audituitkomst.
Moeten we features pauzeren om technische schuld op te lossen?
Vrijwel nooit. Aparte opruimprojecten zijn moeilijk te verantwoorden, moeilijk af te maken en worden als eerste geschrapt. De uitzondering is schuld die actief geld of data verliest — die legt alles stil tot het opgelost is.
Niet zeker welke schuld er echt toe doet?
Wij triëren hem tegen je roadmap — wat je blokkeert, wat geld kost, wat je met rust laat.
Verder lezen
Een kapotte MVP repareren (zonder opnieuw te beginnen)
Vrijwel elke oprichter met een kapotte MVP vraagt of herschrijven moet. Vrijwel altijd is het antwoord nee — en de reden is rekenkunde, geen sentiment.
Architectuuraudit: wanneer je er een nodig hebt en wat hij vindt
Een architectuuraudit is geen mening over je stack. Het is een kaart van waar het systeem breekt onder het plan dat je werkelijk hebt.