Es gibt eine Datei in eurer Codebasis, die niemand öffnet. Ihr wisst, welche gemeint ist. Sie verwaltet Authentifizierung, Zahlungen oder eine zentrale Datenlogik, die der ursprüngliche Entwickler in einem Sprint geschrieben und nie wieder angefasst hat. Sie funktioniert - meistens - also arbeitet jeder drum herum. Neue Features werden darauf aufgebaut. Bugs, die sich auf sie zurückführen lassen, werden an den Rändern geflickt. Seit acht Monaten wurde sie nicht mehr angerührt, weil die unausgesprochene Vereinbarung im Team lautet: Wer sie anfasst, ist dafür verantwortlich. Und niemand will sie besitzen.
Das ist nicht einfach nur Technical Debt. So sieht Technical Debt aus, wenn sie lange genug in Ruhe gelassen wurde, um zur tragenden Wand zu werden.
Technical Debt bezeichnet jede Code-, Architektur- oder Tooling-Entscheidung, die langfristige Wartbarkeit gegen kurzfristige Geschwindigkeit eintauscht. Wer ein Startup baut, häuft sie bereits an. Die Frage ist nicht, ob man Schulden aufnimmt, sondern ob man Schulden aufnimmt, die man bewusst gewählt hat - oder Schulden, die einem einfach passiert sind. Diese Unterscheidung - bewusste Schulden vs. unbewusste Schulden - ist der Unterschied zwischen einem Werkzeug und einer Falle. Alles, was folgt, dreht sich darum, zu erkennen, was man gerade in der Hand hält.
Die Kosten kommen in Stufen, und die dritte Stufe ist die, vor der niemand warnt. Features verlangsamen sich. Ingenieure verbringen mehr Zeit mit Brandbekämpfung als mit Bauen. Dann setzt die Vermeidung ein: Teile des Systems werden nicht mehr angefasst, weil die unausgesprochene Kalkulation besagt, dass das Risiko, etwas kaputt zu machen, den Nutzen einer Reparatur überwiegt. Die unangetastete Datei wird nicht adressiert. Sie wird umgangen, Sprint für Sprint, bis die Workarounds ihre eigenen Workarounds haben. Die Rechnung dafür kommt später - wenn das Team größer ist, der Einsatz höher und die Datei strukturell geworden ist.
Die MVP-Falle: Schnell gelauncht, langsam skaliert
Ein Gründer baut ein MVP, gewinnt Traktion und versucht dann, dieselbe Codebasis zu skalieren, die nie für Skalierung gedacht war. Es ist eines der häufigsten Fehlermuster in Early-Stage-Startups - und im Nachhinein fast immer vorhersehbar.
So läuft es ab: Ein Zwei-Wochen-Feature wird zum Sechs-Wochen-Feature, weil es das Authentifizierungssystem berührt, das seit dem Launch niemand refactored hat. Das Auth-System ist nicht kaputt. Es wurde nur nicht dafür gebaut, erweitert zu werden. Jeder Ingenieur, der es versucht hat, hat wieder einen Rückzieher gemacht. Also wird das Feature drum herum gebaut - ein weiterer Workaround auf den bereits vorhandenen.
Die Lösung ist nicht, langsamer zu bauen. Sondern so zu bauen, dass die Grenzen halten. Ein MVP braucht nicht jedes Feature, aber es braucht eine Architektur, die keinen Abriss erfordert, sobald der Markt validiert ist. Der Unterschied zwischen einem Wegwerf-Prototyp und einem skalierbaren MVP liegt nicht in den Features - sondern darin, ob die Kernlogik isoliert ist, das Datenmodell erweiterbar und das System weiterentwickelt werden kann, ohne es von Grund auf neu zu schreiben.
In der Praxis: Kein Caching für 50 Nutzer implementieren. Keine Microservices bauen, bevor man die Domäne gut genug versteht, um die richtigen Grenzen zu ziehen. Aber Code schreiben, den ein zweiter Ingenieur ohne zweistündige Einführung lesen kann. Die Datenschicht sauber von der Geschäftslogik trennen. Das ist kein Perfektionismus - es sind die Mindestvoraussetzungen, um auch später noch schnell sein zu können.
Warum eure Datenbank langweilig sein sollte
Eine der zuverlässigsten Quellen technischer Schulden in Early-Stage-Startups ist die Versuchung, neue oder trendige Technologie einzusetzen: eine neuartige Datenbank, ein experimentelles Framework, ein Tool, das ein Entwickler gut kennt, aber sonst niemand.
Die Kosten sind anfangs nicht offensichtlich. Das Tool funktioniert. Der Entwickler liefert schnell. Dann verlässt dieser Entwickler das Unternehmen, und man wartet ein System, das auf etwas aufgebaut ist, das eine kleine Community hat, spärliche Dokumentation und einen begrenzten Talentpool. Ein Startup, das seine Datenpipeline auf einem hochmodernen Streaming-Tool aufbaute, sparte am Anfang zwei Wochen - und verbrachte vier Monate damit, einen Nachfolger einzuarbeiten, der das Tool noch nie gesehen hatte.
Wenn um zwei Uhr nachts etwas kaputtgeht, will man eine Stack-Overflow-Antwort - kein GitHub-Issue von 2019 ohne Antworten.
Das ist das eigentliche Argument für langweilige Technologie. Postgres, etablierte Web-Frameworks, weit verbreitete Cloud-Dienste: Diese haben nicht nur bessere Dokumentation. Sie haben größere Talentpools, vorhersehbarere Fehlermodi und Ökosysteme, die auch in drei Jahren noch gepflegt werden. Die richtige Frage bei der Stack-Auswahl ist nicht, was theoretisch das Beste ist. Sondern: Womit kann das aktuelle Team liefern, was wird der nächste Neuzugang wahrscheinlich kennen, und was wird noch aktiven Support haben, wenn skaliert werden muss?
Wer diese Antworten richtig trifft, eliminiert eine ganze Kategorie von Schulden, bevor sie überhaupt entsteht.
Wie man das Schulden-Gespräch führt, ohne es zu verlieren
Es gibt einen Moment in den meisten Startups, in dem das Engineering-Team weiß, dass die Schulden eine kritische Masse erreicht haben - aber niemanden dazu bringen kann, die Behebung zu priorisieren. Der Grund ist fast immer, dass das vorgebrachte Argument technisch ist, während die Entscheider in Roadmap und Umsatz denken.
Das Gespräch, das nicht funktioniert: „Wir müssen langsamer machen, um die Codebasis zu reparieren.” Das, welches funktioniert: „Unsere aktuellen Schulden kosten uns X Tage pro Sprint an verlorener Velocity, und eine fokussierte sechswöchige Maßnahme holt das dauerhaft zurück.” Noch weiter übersetzt: Jedes Feature auf eurer Roadmap dauert länger als nötig, und der Abstand wächst mit jedem Quartal, in dem wir es nicht adressieren. Das ist kein technisches Argument. Es ist ein Wachstumsargument, und es gehört in dasselbe Gespräch wie Kundenakquisitionskosten und Churn.
Die meisten Engineering-Teams verlieren dieses Gespräch, weil sie das Symptom beschreiben, nicht die Kosten. Quantifiziert den Bremseffekt, verknüpft ihn mit etwas, das einem nicht-technischen Stakeholder bereits wichtig ist - und das Gespräch verändert sich.
Bewusste Schulden vs. unbewusste Schulden
Es gibt eine Form von Technical Debt, die die richtige Entscheidung ist. Man verzichtet auf robuste Fehlerbehandlung, weil man erst validieren muss, ob überhaupt jemand dieses Feature nutzt. Man nutzt einen manuellen Prozess statt Automatisierung, weil die Automatisierung eine Woche dauert und man drei Nutzer hat. Man akzeptiert, dass der Code unordentlich ist, weil die Priorität Lernen ist, nicht Bauen für die Ewigkeit. Das sind bewusste Schulden: ein bewusster Trade-off mit bekannten Kosten und der Absicht, ihn zurückzuzahlen.
Unbewusste Schulden sind anders. Sie entstehen nicht, weil man eine Entscheidung getroffen hat, sondern weil man keine getroffen hat. Niemand hat sich dafür entschieden, das Auth-System unangreifbar zu machen. Es wurde so, weil jeder Sprint neue Prioritäten brachte und das Refactoring immer wieder verschoben wurde. Dann fragt eines Tages ein neuer Ingenieur, warum diese Datei seit acht Monaten nicht angefasst wurde, und die ehrliche Antwort ist, dass es niemand mehr weiß. Es wurde einfach die Datei, die niemand öffnet.
Die Startups, die mit Schulden gut umgehen, sind nicht diejenigen, die weniger davon aufnehmen. Es sind diejenigen, die jederzeit wissen, in welcher Kategorie sie sich befinden. Bewusste Schulden sind ein Werkzeug. Unbewusste Schulden entstehen, wenn man aufhört hinzuschauen - und bis man es bemerkt, haben sich die Zinsen seit Monaten aufgetürmt.
Technische Schulden ernst zu nehmen beginnt vor der ersten Zeile Code. Bei Camsol setzen wir auf Frameworks mit großen, etablierten Talent-Pools - das bedeutet, die Systeme, die wir ausliefern, können gewartet, erweitert und übergeben werden, ohne die unangreifbaren Dateien zu erzeugen, die dieser Beitrag beschreibt. Bewusste Entscheidungen auf Stack-Ebene sind der Weg, wie wir verhindern, dass aus Schulden ein Selbstläufer wird.
