Jedes Startup hat technische Schulden, und die meisten davon waren die richtige Entscheidung. Die Frage ist nicht, wie man sie beseitigt — sondern welche Teile Zinsen verlangen, die Sie sich nicht mehr leisten können.
Verzögerungen
Betriebsrisiken
Schuldenregister
Technische Schuld hat einen schlechten Ruf, den sie nicht ganz verdient. Eine Abkürzung zu nehmen, um eine Idee schneller zu validieren, ist meist richtig — die Alternative ist, sorgfältig auf etwas hinzubauen, das niemand wollte. Das Versagen liegt nicht im Aufnehmen der Schuld; es liegt darin, den Zinssatz nie zu prüfen.
Die vier Arten, und nur zwei zählen
| Art | Beispiel | Urteil |
|---|---|---|
| Bewusst und kurzlebig | Hartcodierte Logik, um Nachfrage zu testen, danach entfernt | Richtig — so funktioniert das Werkzeug |
| Bewusst und dauerhaft | Wissentlich genommene Abkürzung, nie wieder angefasst | Gefährlich — Zinsen wachsen lautlos |
| Unbeabsichtigt | Niemand kannte damals einen besseren Weg | Normal — beheben, wenn es zu kosten beginnt |
| Kosmetisch | Benennung, Formatierung, Strukturvorlieben | Vollständig ignorieren |
Woran Sie erkennen, dass es zu viel geworden ist
Es gibt keine absolute Schwelle; Schuld ist nur relativ zu dem sinnvoll, was Sie vorhaben. Aber diese Signale zeigen verlässlich, dass die Zinsen untragbar geworden sind:
- Die Schätzungen wachsen für ähnlich große Features immer weiter — das klarste quantitative Signal
- Das Team sagt bei gewöhnlichen Anfragen routinemäßig «das geht mit dem aktuellen Aufbau nicht»
- Bugs häufen sich wiederholt in denselben Modulen
- Das Onboarding eines neuen Entwicklers dauert Monate statt Wochen
- Leute meiden bestimmte Dateien, und alle wissen welche
- Deployments werden gebündelt und terminiert, weil sie riskant sind
Was abzuzahlen ist, und wann
Schuld lohnt sich zurückzuzahlen, wenn sie etwas Konkretes blockiert, nicht aus Prinzip. Drei Regeln, die funktionieren:
- Zahlen Sie Schuld, die auf dem Weg nach vorn liegt. Führen die nächsten zwei Quartale durch ein Modul, räumen Sie es auf, bevor Sie dort bauen. Schuld in Code, den Sie nicht anfassen werden, kostet nichts.
- Zahlen Sie Schuld, die Geld, Daten oder Auth berührt, sofort — unabhängig von der Roadmap. Fehler dort sind unwiederbringlich statt nur ärgerlich.
- Refaktorieren Sie opportunistisch. Verbessern Sie, was Sie ohnehin ändern, statt separate Aufräumprojekte zu planen — die werden unter Druck als Erstes gestrichen.
Das Budget, das funktioniert
Kein allgemeiner Wartungsprozentsatz hält Schulden automatisch konstant. Planen Sie Kapazität anhand von Risiken und Roadmap und überprüfen Sie diese nach Vorfällen. Eine Neuentwicklung ist eine zu prüfende Option, kein automatisches Auditergebnis.
Das Ziel sind nicht null technische Schulden. Es sind Schulden, die Sie gewählt haben, von denen Sie wissen und die Sie abzahlen könnten, wenn die Roadmap es verlangte.
Was Sie Investoren sagen
Gründer versuchen oft, Schulden während der Due Diligence zu verbergen. Das geht nach hinten los: Die Prüfung findet sie, und die Entdeckung kostet in der Verhandlung mehr, als Offenlegung gekostet hätte. Die stärkere Position ist ein schriftliches Register — welche Schuld existiert, was sie blockiert, was die Behebung kostet. Ein Team, das das artikulieren kann, wirkt kompetent; ein Team, das eine saubere Codebasis behauptet, wirkt entweder naiv oder ausweichend.
Technische Schulden anhand von Belegen priorisieren
Code-Review prüft die Umsetzung, Architektur-Review Grenzen, Abhängigkeiten und Betriebsverhalten. Beginnen Sie mit einer Geschäftsfrage: Trägt das System den nächsten Release oder Kundenzuwachs? Bewerten Sie Folgen, beobachtete Häufigkeit und Behebungsaufwand. Aktive Sicherheits- oder Datenintegritätsprobleme sind gesondert dringlich.
| Die Entscheidung messbar machen | Nachweise vor Beginn vereinbaren |
|---|---|
| Verzögerungen | Eine konkrete Änderung mit betroffenen Modulen, Review-Wartezeiten und Testlücken verknüpfen. Ähnliche Änderungen vor und nach der Behebung vergleichen. |
| Betriebsrisiken | Vorfälle, Traces und Wiederherstellungsergebnisse prüfen. Fehlenden Zugang als ungeprüft dokumentieren, nicht als bestanden. |
| Schuldenregister | Je Eintrag Belege, betroffenen Ablauf, Verantwortlichen, Aufwandsspanne und Nachweis der Behebung festhalten. |
Kein allgemeiner Wartungsprozentsatz hält Schulden automatisch konstant. Planen Sie Kapazität anhand von Risiken und Roadmap und überprüfen Sie diese nach Vorfällen. Eine Neuentwicklung ist eine zu prüfende Option, kein automatisches Auditergebnis.
Häufige Fragen
Wie viel technische Schuld ist normal für ein Startup?
Eine erhebliche Menge, und das ist meist richtig — Geschwindigkeit in der Frühphase ist mehr wert als Politur in der Frühphase. Das Problem ist nicht die Menge, sondern ob sie bekannt, bewusst und auf Bereiche begrenzt ist, die weder die Roadmap blockieren noch Geld und Daten berühren.
Welcher Anteil der Entwicklungszeit sollte in technische Schulden gehen?
Kein allgemeiner Wartungsprozentsatz hält Schulden automatisch konstant. Planen Sie Kapazität anhand von Risiken und Roadmap und überprüfen Sie diese nach Vorfällen. Eine Neuentwicklung ist eine zu prüfende Option, kein automatisches Auditergebnis.
Sollen wir Features pausieren, um technische Schulden zu beheben?
Fast nie. Eigenständige Aufräumprojekte sind schwer zu rechtfertigen, schwer zu beenden und werden zuerst gestrichen. Die Ausnahme ist Schuld, die aktiv Geld oder Daten verliert — die stoppt alles, bis sie behoben ist.
Unsicher, welche Schuld tatsächlich zählt?
Wir triagieren sie gegen Ihre Roadmap — was Sie blockiert, was Geld kostet, was Sie in Ruhe lassen sollten.
Weiterführend
Ein kaputtes MVP reparieren (ohne von vorn anzufangen)
Fast jeder Gründer mit einem kaputten MVP fragt, ob man es neu schreiben soll. Fast jedes Mal lautet die Antwort nein — und der Grund ist Arithmetik, nicht Sentimentalität.
Architektur-Audit: Wann Sie eines brauchen und was es findet
Ein Architektur-Audit ist keine Meinung über Ihren Tech-Stack. Es ist eine Karte davon, wo das System unter dem Plan bricht, den Sie tatsächlich haben.