Jeder VP of Engineering kennt dieses Meeting. Das Roadmap-Review läuft gut, bis jemand fragt, warum das einfache Feature drei Sprints gebraucht hat und nicht einen. Der Entwickler sagt etwas über Legacy-Code, enge Kopplung und ein Datenbankschema, das niemand anfassen will. Der CFO nickt also, geht zum nächsten Punkt über, und der Moment ist vorbei. An keiner dieser Antworten hing eine Zahl, und Finanzabteilungen genehmigen kein Budget für ein Gefühl, so stark es auch empfunden wird.
Das ist der zentrale Fehler jedes Gesprächs über technische Schulden, das in der Sprache der Entwicklung statt in der Sprache der Finanzen geführt wird. Entwickler beschreiben Schulden als Qualitätsproblem. Finanzabteilungen finanzieren Qualitätsprobleme nur zögerlich, wenn überhaupt. Bremswirkung auf das Wachstum, Margenerosion und Bilanzrisiken finanzieren sie dagegen ohne zu zögern, denn genau diese Kategorien soll ein CFO steuern.
Dieser Artikel liefert Ihnen deshalb die Zahl: ein zweistufiges Modell zur Berechnung der Kosten technischer Schulden in Dollar. Zuerst die Entwicklungsstunden, die Ihr Team in jedem Sprint verliert. Dann vier Kostenarten, die die Finanzabteilung längst versteht, nämlich verzögerte Umsätze, verlorene Kunden, höhere Rekrutierungskosten und ein niedrigerer Preis beim Exit. Sie brauchen dafür keine neuen Tools, denn die Eingangsdaten stammen aus Ihren Sprint-Retros, Ihrem Incident-Log und Ihrem letzten Code-Review.
Was unabhängige Studien zu den Kosten technischer Schulden sagen
Bevor Sie Ihre eigene Zahl modellieren, hilft es zu wissen, was andere bereits gemessen haben. Drei Studien lohnt es sich, in einem Finanzmeeting zu zitieren.
Die Analyse von Deloitte aus dem Jahr 2026 bemisst technische Schulden mit 21% bis 40% der IT-Ausgaben eines Unternehmens und arbeitet mit 30% als Mittelwert. Bei einem jährlichen IT-Budget von 10 Millionen US-Dollar sind das 2,1 Millionen bis 4 Millionen US-Dollar pro Jahr, die in Schuldenarbeit statt in neue Leistungsfähigkeit fließen.
McKinsey befragte 50 CIOs von Finanzdienstleistern und Technologieunternehmen mit einem Umsatz von mehr als 1 Milliarde US-Dollar. Diese CIOs bezifferten die technischen Schulden auf 20 bis 40 Prozent des Werts ihrer gesamten Technologielandschaft vor Abschreibungen. Im Klartext: Addiert man den Wert aller Systeme, so ist ein Fünftel bis zwei Fünftel dieser Summe noch offene Arbeit, also die Korrekturen und Upgrades, die nötig sind, bevor diese Systeme den Zustand haben, den das Geschäft tatsächlich braucht. Dieselben CIOs berichteten, dass 10 bis 20 Prozent des für neue Produkte vorgesehenen Budgets in Schuldenarbeit umgeleitet werden, bevor ein einziges Feature ausgeliefert ist, und 60 Prozent gaben an, das Problem sei in den drei Jahren davor deutlich gewachsen.
Auf nationaler Ebene schätzte das Consortium for Information and Software Quality die aufgelaufenen technischen Schulden der US-Softwarewirtschaft auf rund 1,52 Billionen US-Dollar, als Teil von Gesamtkosten mangelhafter Softwarequalität in Höhe von 2,41 Billionen US-Dollar.
Nutzen Sie diese Zahlen als Plausibilitätsprüfung für Ihr eigenes Modell, nicht als Ersatz dafür. Liegt Ihre Zahl deutlich unter 20 Prozent der Entwicklungsausgaben, sind Ihre Eingangswerte wahrscheinlich zu optimistisch, und Ihr CFO wird das vor Ihnen bemerken. Die Metriken, die in diese Eingangswerte einfließen, behandelt unser Leitfaden zum Messen technischer Schulden.
Das CFO-taugliche Kostenmodell
Das Modell hat zwei Stufen. Die erste sind direkte Kosten, die Sie aus Daten berechnen können, die Ihnen bereits vorliegen. Die zweite ist ein Satz indirekter Kosten, der einige plausible Schätzungen erfordert. Das ist unproblematisch, denn CFOs sind mit geschätzten Bandbreiten vertraut, solange die Methodik transparent ist. Genau so behandeln sie ohnehin Abschreibungen, Wertberichtigungen auf Forderungen und den größten Teil der übrigen Bilanz.
Stufe 1: Die direkten Kosten, die Sie heute berechnen können
Direkte Kosten = pro Sprint an Schulden verlorene Stunden × Vollkosten pro Entwicklerstunde × Sprints pro Jahr
- Pro Sprint verlorene Stunden. Ziehen Sie diesen Wert aus Sprint-Retros, der Zeiterfassung oder einer zweiwöchigen Umfrage dazu, welcher Anteil der Story Points in schuldengetriebene Nacharbeit statt in echte Neuentwicklung ging. Wenn Sie noch keine internen Daten haben, starten Sie am konservativen Ende der Forschungsbandbreite, bei 20 Prozent, und ersetzen Sie den Wert innerhalb von ein bis zwei Sprints durch Ihre eigene Zahl. Eine Zahl aus Ihren eigenen Retros hält einer Prüfung immer besser stand als ein Branchendurchschnitt.
- Vollkosten pro Entwicklerstunde. Vollkosten sind alles, was ein Entwickler das Unternehmen in einem Jahr kostet, nicht nur das, was auf seinem Konto landet: Grundgehalt plus Sozialleistungen, Lohnnebenkosten, Ausstattung, Softwarelizenzen, Rekrutierung und ein Anteil an Büro- und Verwaltungsgemeinkosten. Die Finanzabteilung berechnet das für jede Rolle bereits, fragen Sie also nach deren Wert, statt selbst zu schätzen.
- Sprints pro Jahr. Bei einem Zwei-Wochen-Takt typischerweise 24 bis 26.
Hier die Rechnung Schritt für Schritt, für ein Team aus zehn Entwicklern:
- Teamkapazität pro Sprint. Zehn Entwickler in einem zweiwöchigen Sprint ergeben insgesamt 800 Stunden, also 10 Personen × je 80 Stunden.
- Kosten pro Stunde. Nehmen wir Vollkosten von 145.000 US-Dollar pro Entwickler und Jahr. Geteilt durch 2.080 Arbeitsstunden, das Standardjahr einer Vollzeitstelle mit 40 Stunden pro Woche × 52 Wochen, ergibt das rund 70 US-Dollar pro Stunde.
- An Schulden verlorene Stunden. Bei 35 Prozent gehen 280 dieser 800 Stunden in jedem Sprint in Schuldenarbeit.
- Kosten eines Sprints. 280 Stunden × 70 US-Dollar = 19.600 US-Dollar.
- Kosten des Jahres. 19.600 US-Dollar × 26 Sprints = rund 510.000 US-Dollar.
Diese 510.000 US-Dollar sind Entwicklungszeit, die in die Bedienung von Schulden statt in den Produktaufbau fließt, und sie ist nie in einer einzigen Budgetposition aufgetaucht. Meist bringt das einen skeptischen CFO dazu, sich nach vorne zu lehnen, denn es sind echte Betriebsausgaben, die niemand erfasst hat. Damit der Stundenwert vor dem Meeting schwerer anzugreifen ist, schärfen Sie, wie Ihr Team Codequalität definiert und verfolgt.
Stufe 2: Die indirekten Kosten, die das Finanzteam aufhorchen lassen
Indirekte Kosten sind das, was technische Schulden mit dem übrigen Geschäft anrichten: Umsatz, der zu spät kommt, Kunden, die nach einem Ausfall zu viel abwandern, Gehälter, die Sie überzahlen, um ein alterndes System zu besetzen.
Verzögerte Features
Feature-Wert pro Woche × Wochen Verzögerung durch technische Schulden
Roadmap-Prognosen, Lieferhistorie
Kundenabwanderung durch Incidents
Verlorene Kunden pro großem Incident × durchschnittlicher Customer Lifetime Value
Support-Tickets, Incident-Log, Abwanderungsberichte
Recruiting-Aufschlag
Zusätzliche Time-to-Hire und Ablehnungsquote bei Legacy-Rollen gegenüber modernen Rollen
Daten aus dem Recruiting-Funnel
Bewertungsabschlag
Voraussichtliches Sanierungsangebot des Due-Diligence-Teams eines Käufers
Frühere Due-Diligence-Ergebnisse, Audit-Berichte
Verzögerte Features. Nehmen Sie den prognostizierten Umsatz oder die Kostenersparnis des Features, teilen Sie sie durch den geplanten Zeitraum, um einen Wert pro Woche zu erhalten, und multiplizieren Sie diesen mit der Verzögerung, die auf schuldengetriebene Nacharbeit zurückgeht. Ein Feature im Wert von 40.000 US-Dollar pro Monat, das wegen Legacy-Zwängen acht Wochen zu spät erscheint, bedeutet rund 80.000 US-Dollar aufgeschobenen Wert, vollständig getrennt von den Entwicklungsstunden, die dabei verbrannt wurden.
Kundenabwanderung durch Incidents. Nutzen Sie Ihre Change Failure Rate, also den Anteil der Deployments, die einen Incident, ein Rollback oder einen Hotfix auslösen, zusammen mit Support- und Abwanderungsdaten, um zu schätzen, wie viele Kunden Sie pro großem Incident verlieren, und multiplizieren Sie das mit dem Lifetime Value. Die meisten Teams finden diese Zahl größer als erwartet, denn Incidents werden selten auf die Schulden zurückverfolgt, die sie verursacht haben.
Recruiting-Aufschlag. Wenn Ihr System eine alte Framework-Version, ein eigenentwickeltes internes Werkzeug oder eine abgekündigte Sprache erfordert, vergleichen Sie Time-to-Hire und Angebotsannahme bei diesen Rollen mit Ihrem modernen Stack. Der Aufschlag ist aus zwei Gründen real: Der Pool an Entwicklern, die eine veraltete Technologie noch beherrschen, wird jedes Jahr kleiner, und wer sie beherrscht, lehnt die Stelle oft ab, weil sie den nächsten Karriereschritt einengt. Sie zahlen dafür doppelt, mit einer längeren Vakanz und mit einem höheren Angebot.
Bewertungsabschlag. Wenn ein Exit, eine Übernahme oder eine Finanzierungsrunde überhaupt in Sicht ist, modellieren Sie einen konservativen Abschlag auf Basis der Sanierungskosten, die das technische Due-Diligence-Team eines Käufers ansetzen würde. Das ist von den vier Posten der am schwersten fassbare, doch selbst eine grobe Bandbreite macht aus Schulden statt einer Beschwerde der Entwicklung ein Thema des Shareholder Value. Unsere Checkliste für die technische Due Diligence bei M&A zeigt, worauf diese Teams tatsächlich achten, was die Schätzung deutlich weniger spekulativ macht.
Addieren Sie die vier indirekten Schätzungen zu den direkten Kosten, und Sie haben eine annualisierte Zahl: die Kosten technischer Schulden für Ihr Unternehmen, in Dollar statt in Story Points. Was Sie damit tun, ist die nächste Entscheidung, und die Zahl zu haben ist es, was diese Entscheidung erst möglich macht. Routinepflege wie Abhängigkeits-Updates, Regressionsabdeckung und Security-Patching in einen Vertrag für Software-Wartung zu verlagern, ist ein gängiger Weg, denn er verwandelt einen unvorhersehbaren Kostenblock in eine feste Position, die die Finanzabteilung planen kann.
Wo AI-gestützter Code die Rechnung verändert
Wenn Ihr Team dieses Jahr mit gleicher Personalstärke deutlich mehr Code ausgeliefert hat, ist Ihr Schuldenstundenwert aus dem Vorjahr bereits veraltet. AI-gestützte Entwicklung verschiebt den Engpass vom Schreiben des Codes zu dessen Prüfung, und Code, der das Review zu leicht passiert, kommt gern ein Quartal später als Nacharbeit zurück. Wie sich diese Schulden aufbauen, haben wir in unserem Beitrag zu technischen Schulden bei AI-Coding behandelt.
Zwei Änderungen halten Ihr Kostenmodell genau. Messen Sie den Schuldenstundenwert aus Stufe 1 quartalsweise statt jährlich, und verfolgen Sie ihn gemeinsam mit dem Anteil des gemergten Codes, der AI-gestützt entstanden ist. Steigen diese beiden Zahlen gemeinsam, haben Sie Ihre am schnellsten wachsende Schuldenquelle gefunden, solange sie noch günstig zu beheben ist. Teams, die schon AI-Review-Tools einsetzen, sollten zusätzlich prüfen, was diese Werkzeuge wirklich finden, und genau das haben wir in unserem Test von Claude Code für Code-Reviews untersucht.
Wo eine Codebasis schon einen Bestand an AI-generiertem Code angesammelt hat, den niemand vollständig verantwortet, ist ein gezieltes Projekt zum Vibe-Code-Cleanup meist günstiger, als diese Arbeit in die normale Sprint-Kapazität aufzunehmen, denn der Umfang ist begrenzt und lässt sich gegen die Zahl bepreisen, die Sie gerade berechnet haben.
Warum Teams Redwerk in dieses Gespräch holen
Redwerk entwickelt seit 2005 Software, wir haben also viele Schulden entstehen sehen und sind beauftragt worden, einen guten Teil davon aufzuräumen. Wir bauen komplexe Produkte von Grund auf, auditieren Systeme, die seit Jahren niemand dokumentiert hat, und refaktorieren Legacy-Projekte, von denen andere Teams sich abgewandt haben. In jüngerer Zeit haben wir AI-basierte Lösungen sowie AI-gestützte Entwicklung und Tests hinzugenommen. Die technischen Grundlagen und Sicherheitspraktiken dahinter sind dieselben, die wir seit Jahren für Kunden in Nordamerika und Europa anwenden, darunter Fortune-500-Unternehmen wie Siemens, J.B. Hunt und Universal Music Group. Sie decken nun auch die neuesten Schuldenquellen ab.
Die Einsparungen beginnen oft kleiner und früher, als Leute erwarten. Als Adoorabelle, ein Immobilienmarktplatz aus Atlanta, uns hinzuzog, war der Gründer nicht technisch, an einen früheren Dienstleister gebunden und hatte keine Dokumentation, die er einem Investor zeigen konnte. Unser Audit ihrer Immobilien-App brachte 80 Probleme zutage, von hartkodierten Secrets bis zu kritischen Strukturfehlern, senkte unnötige API-Abokosten um 300 US-Dollar pro Monat, was allein 3.600 US-Dollar pro Jahr aus dem Betriebsbudget zurückholt, brachte ihre AWS-Infrastruktur näher an ihre Nutzer und ergänzte eine Rund-um-die-Uhr-Observability mit Sentry, Prometheus und Grafana. Am Ende hatten sie eine vollständige Funktionsspezifikation, volle Unabhängigkeit vom Dienstleister und etwas, das sie Investoren zeigen konnten.
Das ist das Muster, das sich zu kopieren lohnt: Finden Sie heraus, was die Schulden tatsächlich kosten, in Dollar, bevor Sie entscheiden, wie viel Sie dafür ausgeben. Wenn Sie diese Zahl von Leuten wollen, die Ihnen auch klar sagen, welche Teile sich nicht zu beheben lohnen, beginnen Sie mit einem Software-Entwicklungsaudit.
FAQ
Was kosten technische Schulden?
Es gibt keine einzelne Branchenzahl, denn es hängt von der Teamgröße, den Entwicklungskosten und davon ab, wie schuldenlastig die Codebasis ist. Unabhängige Studien liefern nützliche Anhaltspunkte: Deloitte bemisst technische Schulden mit 21% bis 40% der IT-Ausgaben, und McKinsey stellte fest, dass CIOs sie auf 20 bis 40 Prozent des Gesamtwerts ihrer Technologielandschaft schätzen. Ihre eigenen Vollkosten pro Entwickler auf die Schuldenstunden pro Sprint Ihres Teams anzuwenden, ist der einzige Weg zu einer unternehmensspezifischen Zahl statt zu einem Branchendurchschnitt.
Wie schätzt man die langfristigen Kosten technischer Schulden?
Kombinieren Sie direkte Kosten, also pro Sprint an Schulden verlorene Stunden multipliziert mit den Vollkosten pro Entwicklerstunde und den Sprints pro Jahr, mit vier indirekten Kosten: Opportunitätskosten verzögerter Features, Kundenabwanderung im Zusammenhang mit der Incident-Häufigkeit, Recruiting-Aufschläge für Talente mit Legacy-Stack und jeder Bewertungsabschlag, der in einer technischen Due Diligence auftauchen würde. Da Schulden sich aufzinsen, modellieren Sie die Summe jährlich und prüfen Sie die Eingangswerte quartalsweise, statt die Rechnung als Einmalvorgang zu behandeln.
Wie berechnen Unternehmen die Kosten technischer Schulden?
Die meisten reifen Entwicklungsorganisationen verfolgen einen Wert für Schuldenstunden pro Sprint aus Retros oder Zeiterfassungsdaten, wenden die Vollkosten pro Entwickler ihres Finanzteams an und ergänzen Delivery-Metriken wie Change Failure Rate und Wiederherstellungszeit, um Schulden mit Incident- und Abwanderungskosten zu verknüpfen. Das Ergebnis wird meist als annualisierter Dollarbetrag neben einem Prozentsatz der gesamten Entwicklungskapazität ausgedrückt.
Warum lehnen CFOs Budgetanträge für technische Schulden ab?
Die meisten Anträge sind in technischen Begriffen formuliert, etwa Codequalität, Refactoring und Architektur, statt in finanziellen wie Dollar, Opportunitätskosten und Risikoexposition. Ein Antrag, der als “510.000 US-Dollar jährliche Entwicklungszeit plus 600.000 US-Dollar prognostizierte Kundenabwanderung und verzögerter Umsatz” formuliert ist, konkurriert um Budget genauso wie jede andere Entscheidung über Kapitalverwendung. Ein Antrag, der als “der Code braucht eine Aufräumung” formuliert ist, in der Regel nicht.
Erfahren Sie, wie Redwerk eine strauchelnde Fitness-App von einem anderen Anbieter übernahm, die geerbten technischen Schulden beseitigte und Pridefit half, die Abonnements um 45% zu steigern
