Die wahren Kosten technischer Schulden: Wie sie drei finanzierte Startups zu Fall brachten
Drei gut finanzierte Start-ups mit hervorragenden Produkten mussten schließen – nicht wegen schlechter Ideen, sondern weil sie aufgrund technischer Schulden nicht in der Lage waren, Produkte auf den Markt zu bringen, Mitarbeiter einzustellen oder zu expandieren. Hier erfahren Sie, was schiefgelaufen ist und wie Sie dies vermeiden können.
Technische Schulden sind kein Problem der Entwickler. Sie sind ein geschäftliches Problem.
Als Gründer oder CTO haben Sie sicher schon erlebt, wie sich Entwickler über „Tech Debt“ beschweren. Das klingt abstrakt – wie etwas, das Entwickler ausbremst, aber eigentlich keinen Einfluss auf das Geschäft hat. Bis es doch einen Einfluss hat.
Technische Schulden sind die Lücke zwischen dem Code, den man hat, und dem Code, den man braucht. Genau wie finanzielle Schulden summieren sie sich. Eine Abkürzung, die heute zwei Wochen spart, kostet nächstes Jahr zwei Monate. Hier sind drei echte Unternehmen, die diese Lektion zu spät gelernt haben.
Fall 1: Das Startup in der Serie-B-Finanzierungsrunde, das eine Funktion in sechs Monaten nicht bereitstellen konnte
Ein B2B-SaaS-Unternehmen hat in einer Serie-B-Finanzierungsrunde 18 Millionen Dollar eingesammelt. Das Produkt wies eine starke Produkt-Markt-Passung auf. Doch nach zwei Jahren, in denen nach dem Motto „Move fast and break things“ gearbeitet wurde, erforderte jede neue Funktion Änderungen an mehr als 15 Dateien, jede Änderung führte zu neuen Fehlern, und die Bereitstellung dauerte einschließlich manueller Tests drei Stunden.
Die Zahlen: Vor der Kreditaufnahme lieferten sie 4 Funktionen pro Monat. Nach der Kreditaufnahme waren es 0,5 Funktionen pro Monat. Ihr Konkurrent (der frühzeitig in die Architektur investiert hatte) lieferte 6 Funktionen pro Monat. Innerhalb von 18 Monaten hatte der Konkurrent den Markt erobert.
Wir sind nicht wegen eines schlechten Produkts in Konkurs gegangen. Wir sind in Konkurs gegangen, weil wir das Produkt nicht schnell genug weiterentwickeln konnten. Die Entwicklung jeder einzelnen Funktion dauerte viermal so lange wie bei unserem Konkurrenten.
— Anonymer CTO, Nachbetrachtung
Fall 2: Die E-Commerce-Plattform, die den Black Friday verpasste
Ein E-Commerce-Startup verfügte über ein monolithisches Backend ohne Caching und Lasttests, dessen Datenbankabfragen bei 1.000 Nutzern noch einwandfrei funktionierten, bei 50.000 jedoch zusammenbrachen. Das Problem war ihnen bereits seit einem Jahr bekannt. „Wir beheben es, sobald wir die nächste Funktion eingeführt haben“, lautete die immer wiederkehrende Entscheidung.
Der Black Friday schlug zu. Die Website war neun Stunden lang nicht erreichbar. Das Unternehmen verlor schätzungsweise 2,3 Millionen Dollar an Umsatz und das Vertrauen von 40.000 Kunden, die nie wieder zurückkehrten. Die Einstellung „Das regeln wir später“ kostete mehr als der komplette Neuaufbau des Systems.
Fall 3: Das Fintech-Unternehmen, das die Sicherheitsprüfung nicht bestanden hat
Ein Fintech-Startup benötigte die SOC-2-Konformität, um Unternehmenskunden zu gewinnen. Die Prüfung ergab: im Quellcode fest codierte API-Schlüssel, keine Verschlüsselung im Ruhezustand, mit MD5 gehashtete Benutzerkennwörter und keine Protokollierung von Prüfvorgängen. Die Behebung dieser Probleme erforderte eine Neuprogrammierung von 60 % des Backends. Die sechsmonatige Nachbesserung zehrte die verbleibenden finanziellen Reserven des Unternehmens vollständig auf.
Die Geschäftsabschlüsse, auf die sie gesetzt hatten, kamen nie zustande, weil die Prüfung nicht rechtzeitig abgeschlossen werden konnte.
Wie man technische Schulden misst (für Nicht-Ingenieure)
Man muss keinen Code lesen können, um technische Schulden zu erkennen. Stellen Sie Ihrem Entwicklerteam folgende Fragen:
| Frage | Gesunde Antwort | Rote Flagge |
|---|---|---|
| Wie lange dauert es, eine Änderung von einer Zeile zu implementieren? | Weniger als 30 Minuten | Über 2 Stunden |
| Wie viel Prozent des Sprints entfallen auf Fehlerbehebung im Vergleich zu neuen Funktionen? | unter 20 % | Über 40 % |
| Kann ein neuer Entwickler schon am ersten Tag loslegen? | Ja, mit Anleitung | Die Einarbeitung dauert 2 bis 4 Wochen |
| Wie viele Dinge gehen kaputt, wenn man eine Sache ändert? | In seltenen Fällen führen wir Tests durch | Wir führen ständig manuelle Tests durch |
| Wann haben Sie das letzte Mal eine Abhängigkeit aktualisiert? | Monatlich | Wir haben Angst, es anzufassen |
Die 20-Prozent-Regel: Schulden vermeiden, bevor sie dich ruinieren
Die erfolgreichsten Entwicklerteams, mit denen wir zusammengearbeitet haben, befolgen die 20-Prozent-Regel: Sie widmen 20 Prozent jedes Sprints dem Abbau technischer Schulden. Nicht 100 Prozent (das würde das Geschäft zum Erliegen bringen). Nicht 0 Prozent (das würde zukünftige Probleme garantieren). Zwanzig Prozent.
Bei einem zweiwöchigen Sprint mit fünf Entwicklern sind das zwei Entwicklertage, die folgenden Aufgaben gewidmet sind: Aktualisierung von Abhängigkeiten, Schreiben von Tests für noch nicht getesteten Code, Refactoring des chaotischsten Moduls, Verkürzung der Bereitstellungszeiten oder Dokumentation von implizitem Wissen.
Das sind keine Kosten. Das ist eine Absicherung. Die Unternehmen, die die Serie-B-Finanzierungsrunde überstehen, sind diejenigen, die die Codequalität als geschäftlichen Kennwert betrachten und nicht als technische Präferenz.
Die Frage ist nicht, ob Sie es sich leisten können, in die Codequalität zu investieren. Die Frage ist, ob Sie es sich leisten können, darauf zu verzichten. Technische Schulden wachsen mit 100 % Zinsen.
— alokknight Engineering