Euer Entwickler sagt: “Das Feature dauert drei Wochen.” Vor zwei Jahren hätte es drei Tage gedauert. Dieselbe Funktion, dasselbe Team, aber der Shop ist gewachsen. Nicht nur an Umsatz, sondern an Komplexität: 34 Plugins, ein Checkout, den niemand mehr anfassen will, drei verschiedene Datenquellen für Produktpreise und ein Deployment-Prozess, bei dem alle den Atem anhalten.
Das sind technische Schulden. Und sie betreffen nicht nur Softwareunternehmen mit tausend Entwicklern. Sie betreffen jeden mittelständischen Online-Händler, dessen Shop über Jahre gewachsen ist, ohne dass jemand regelmäßig aufgeräumt hat.
Laut Deloitte fließen 21 bis 40 Prozent des gesamten IT-Budgets in die Verwaltung technischer Schulden. Stripe beziffert den Produktivitätsverlust auf 42 Prozent der Entwicklerarbeitszeit. Und eine Pega-Studie zeigt: Global agierende Unternehmen verschwenden im Schnitt über 370 Millionen Dollar pro Jahr, weil sie veraltete Systeme nicht effizient modernisieren.
Die gute Nachricht: Technische Schulden sind kein Todesurteil. Sie sind ein Managementproblem. Und wie jedes Managementproblem lassen sie sich lösen, wenn ihr wisst, wo sie stecken, was sie kosten und wann ihr handeln müsst.
Was technische Schulden im E-Commerce wirklich bedeuten
Der Begriff technische Schulden stammt von Ward Cunningham, einem der Pioniere der agilen Softwareentwicklung. Seine Metapher: Jede Abkürzung in der Softwareentwicklung ist wie ein Kredit. Ihr gewinnt kurzfristig Zeit, aber die Zinsen laufen. Und irgendwann übersteigen die Zinszahlungen den ursprünglichen Nutzen.
Im E-Commerce ist diese Metapher besonders treffend, weil Shops unter permanentem Veränderungsdruck stehen. Neue Payment-Methoden, geänderte Marktplatz-Anforderungen, saisonale Peaks, regulatorische Anpassungen. Jede dieser Anforderungen erzeugt Druck, schnell zu liefern. Und jede schnelle Lösung kann neue Schulden aufbauen.
Technische Schulden im E-Commerce beschränken sich dabei nicht auf schlechten Code. Sie zeigen sich in mehreren Schichten:
Code-Schulden: Schlecht strukturierter, undokumentierter oder kopierter Code, der bei jeder Änderung Seiteneffekte auslöst
Architektur-Schulden: Ein monolithisches System, das vor fünf Jahren passte, aber heute jede Skalierung blockiert
Integrations-Schulden: Punkt-zu-Punkt-Verbindungen zwischen ERP, PIM, CRM und Shop, die bei jedem Update brechen können
Plugin-Schulden: 30 oder mehr Plugins, von denen die Hälfte veraltet ist, drei sich gegenseitig blockieren und keiner weiß, welches Plugin welchen Seiteneffekt verursacht
Daten-Schulden: Produktdaten in drei Excel-Dateien statt in einem sauberen PIM-System, doppelte Kundendatensätze, inkonsistente Kategoriestrukturen
Prozess-Schulden: Manuelle Deployments, fehlendes Staging, kein automatisiertes Testing
Die Unterscheidung zwischen bewussten und unbewussten Schulden hilft bei der Einordnung. Bewusste Schulden entstehen, wenn ihr wissentlich eine Abkürzung nehmt (“Wir bauen das Feature jetzt quick & dirty, weil Black Friday in vier Wochen ist”). Unbewusste Schulden entstehen, wenn ihr nicht wisst, dass die Lösung suboptimal ist, oft weil sich Best Practices weiterentwickelt haben oder weil das Team gewechselt hat.
Beide Arten kosten Geld. Aber bewusste Schulden könnt ihr planen und zurückzahlen. Unbewusste Schulden entdeckt ihr meistens erst, wenn etwas bricht.
Wie technische Schulden im E-Commerce entstehen
Technische Schulden sind selten das Ergebnis einer einzelnen schlechten Entscheidung. Sie wachsen über Jahre, in kleinen Schritten, die für sich genommen alle vernünftig waren. Fünf Muster tauchen dabei immer wieder auf:
1. “Schnell vor sauber” beim letzten Relaunch
Der häufigste Auslöser. Ein Relaunch hat ein festes Budget und einen festen Termin. Wenn beides eng wird (und das wird es fast immer), fallen Tests, Dokumentation und saubere Architektur als Erstes weg. Der Shop geht live, alles funktioniert. Aber der Code, der “später noch aufgeräumt” werden sollte, wird nie aufgeräumt. Stattdessen baut das nächste Feature auf der provisorischen Lösung auf.
2. Plugin-Wildwuchs ohne Governance
Plugins sind die schnellste Lösung für fast jedes Problem. Braucht ihr eine Wunschliste? Plugin. Cookie-Banner? Plugin. Erweiterte Filterung? Plugin. Nach drei Jahren habt ihr 35 Plugins installiert, von denen fünf nicht mehr gewartet werden, drei denselben jQuery-Slider laden und zwei sich gegenseitig die Performance ruinieren. Aber niemand traut sich, eines zu deaktivieren, weil unklar ist, was davon abhängt.
3. Checkout-Customizing über Jahre gewachsen
Der Checkout ist die empfindlichste Stelle eures Shops. Hier fließt Geld. Und genau deshalb wird hier am meisten angepasst: Rabattlogiken, Zahlungsanbieter-Integrationen, individuelle Versandregeln, steuerliche Sonderfälle. Nach drei Jahren ist der Checkout ein Geflecht aus Custom-Code, das kein neuer Entwickler ohne Einarbeitungszeit versteht. Jede Änderung birgt das Risiko, einen der 17 Sonderfälle zu brechen.
4. Keine Tests, kein Staging, Deployment als Nervensache
In vielen mittelständischen Shops gibt es kein automatisiertes Testing und kein sauberes Staging-Environment. Änderungen werden direkt auf dem Live-System getestet. Das funktioniert, bis es nicht mehr funktioniert. Und dann ist der Checkout am Freitagabend kaputt, weil jemand ein Plugin-Update eingespielt hat, ohne die Zahlungsintegration zu testen.
5. Daten-Silos statt sauberer Produktdaten
Produktdaten leben in einer Kombination aus Shop-Backend, ERP-Export, Excel-Tabellen und dem Kopf einer einzelnen Person, die seit acht Jahren im Unternehmen ist. Wenn diese Person krank wird oder das Unternehmen verlässt, bricht die Datenpipeline zusammen. Das ist keine technische Schuld im klassischen Sinne, aber die Konsequenz ist identisch: steigende Kosten, sinkende Geschwindigkeit, wachsendes Risiko.
Was technische Schulden euren Shop wirklich kosten
Technische Schulden sind abstrakt, solange man sie nicht in Euro beziffert. Genau das machen wir jetzt.
Die Zahlen aus der Forschung
Was das für einen mittelständischen Online-Händler bedeutet
Die Enterprise-Zahlen klingen weit weg. Also übersetzen wir sie auf einen typischen Mittelstands-Shop mit 5 Mio. EUR Online-Umsatz, einem 3-köpfigen Dev-Team und monatlichen IT-Kosten von 25.000 EUR:
Die Rechnung wird noch deutlicher, wenn ihr Performance einbezieht. Google und Portent haben wiederholt gezeigt: Jede zusätzliche Sekunde Ladezeit senkt die Conversion Rate um 7 bis 20 Prozent. Wenn euer Shop 10.000 Sessions pro Tag hat und die Conversion von 2,5% auf 2,0% fällt, weil technische Schulden die Ladezeit von 2 auf 4 Sekunden verdoppelt haben, verliert ihr bei einem durchschnittlichen Warenkorbwert von 80 EUR rund 146.000 EUR Umsatz pro Jahr. Nicht durch einen Crash. Nicht durch einen Hack. Sondern durch langsame Software, die niemand als dringend genug empfunden hat.
Wer die Gesamtrechnung scheut, findet einen verwandten Denkrahmen in unserem Artikel über die Kosten des Nichtstuns in der IT-Infrastruktur.
7 Warnsignale, die ihr nicht ignorieren solltet
Technische Schulden kündigen sich selten mit einem Knall an. Sie sickern ein. Diese sieben Warnsignale zeigen euch, dass der Schuldenberg wächst:
1. Deployments dauern Stunden statt Minuten. Wenn ein Update des Cookie-Banners einen halben Tag Deployment-Aufwand erzeugt, stimmt etwas mit dem Build-Prozess oder der Architektur nicht.
2. Feature-Requests werden immer teurer. “Das hätte früher drei Tage gedauert” ist ein Satz, den ihr ernst nehmen solltet. Wenn die Kosten für vergleichbare Features Jahr für Jahr steigen, sind Schulden die wahrscheinlichste Ursache.
3. Entwickler kündigen oder wollen den Code nicht anfassen. Gute Entwickler wollen an guter Software arbeiten. Wenn euer Team Fluktuation zeigt oder bestimmte Bereiche des Codes aktiv meidet, ist das ein starkes Signal.
4. Die Performance sinkt ohne erkennbaren Grund. Der Shop wird langsamer, obwohl ihr keine großen Änderungen vorgenommen habt. Oft liegt es an akkumulierten Plugin-Konflikten, ungenutztem JavaScript oder wachsenden Datenbankabfragen.
5. Sicherheitslücken häufen sich. Veraltete Dependencies, nicht gepatchte Plugins, fehlende Updates. Jede dieser Lücken ist eine technische Schuld mit direktem Risikopotenzial.
6. Niemand versteht den alten Code. Der Entwickler, der den Checkout gebaut hat, ist seit zwei Jahren nicht mehr im Unternehmen. Sein Code hat keine Dokumentation, keine Tests und eine eigenwillige Struktur. Jetzt muss jemand anderes eine Zahlungsmethode hinzufügen.
7. Neue Integrationen gelten als “nicht möglich”. Wenn euer Team auf die Frage “Können wir X anbinden?” regelmäßig mit “Nicht mit dem aktuellen System” antwortet, habt ihr ein Architektuproblem, das Wachstum blockiert.
Treffen drei oder mehr dieser Punkte auf euch zu? Dann ist es Zeit, aktiv zu werden.
Technische Schulden messen: Vom Bauchgefühl zur Entscheidungsgrundlage
Die meisten Entscheider spüren, dass technische Schulden existieren. Aber “es fühlt sich langsam an” reicht nicht als Grundlage für eine Investitionsentscheidung. Ihr braucht Zahlen, die auch euer CFO versteht.
Vier Kennzahlen, die ohne tiefe Codeanalyse funktionieren:
1. Deployment-Frequenz
Wie oft könnt ihr Änderungen live bringen? Einmal pro Woche? Einmal pro Monat? Alle drei Monate? Die Deployment-Frequenz ist ein direkter Indikator für die Gesundheit eures Systems. Gesunde Shops deployen mehrmals pro Woche. Wenn ihr auf “alle zwei Wochen am Donnerstagnachmittag” festgenagelt seid, begrenzen die Schulden eure Handlungsfähigkeit.
2. Time-to-Feature
Messt die Zeit vom genehmigten Feature-Request bis zum Go-live. Nicht in absoluten Zahlen (die schwanken je nach Komplexität), sondern im Trend: Wird es von Quartal zu Quartal langsamer? Dann wachsen die Schulden.
3. Incident-Rate
Wie oft bricht etwas in Produktion? Teams mit hohen technischen Schulden berichten 3- bis 5-mal häufiger von Produktionsvorfällen als Teams mit niedrigen Schulden. Führt ein einfaches Incident-Log: Datum, Dauer, betroffene Funktion, Ursache.
4. Developer-Zufriedenheit
Klingt weich, ist aber einer der stärksten Frühindikatoren. Fragt euer Team halbjährlich: “Auf einer Skala von 1 bis 10, wie zuversichtlich seid ihr, dass ihr in diesem Codebase schnell und sicher Änderungen vornehmen könnt?” Ein Score unter 5 ist ein Alarmsignal.
Ihr braucht kein SonarQube oder statische Code-Analyse, um den Handlungsbedarf zu erkennen. Diese vier Metriken reichen, um eine fundierte Entscheidung zu treffen und intern Budget zu argumentieren.
Technische Schulden abbauen: Drei Strategien für E-Commerce-Teams
Schulden erkennen ist der erste Schritt. Abbauen der zweite. Drei Ansätze, die in der Praxis funktionieren:
Strategie 1: Kontinuierlicher Schuldenabbau (15-20% Regel)
Reserviert 15 bis 20 Prozent eurer Entwicklerkapazität dauerhaft für technische Verbesserungen. Nicht als Lückenfüller, wenn gerade kein Feature-Request ansteht. Sondern als fester Bestandteil jeder Iteration.
In der Praxis: Ein 3-köpfiges Dev-Team arbeitet 4 Tage pro Sprint an Features und 1 Tag an Schuldenabbau. In diesem einen Tag werden Tests nachgezogen, Dependencies aktualisiert, ein Plugin durch eine native Lösung ersetzt oder ein Stück Legacy-Code refactored.
Wann passt das: Wenn die Schulden gleichmäßig verteilt sind und kein einzelner Bereich akut brennt. Gut als dauerhafte Praxis, um neue Schulden gar nicht erst entstehen zu lassen.
Strategie 2: Gezielte Modernisierungs-Sprints
Statt kontinuierlicher kleiner Verbesserungen konzentriert ihr euch auf einen spezifischen Bereich und räumt ihn in einem dedizierten Sprint komplett auf.
In der Praxis: Ihr identifiziert den Checkout als größten Schuldenherd. Für zwei Wochen arbeitet das Team ausschließlich an Checkout-Refactoring: Tests schreiben, Custom-Code vereinfachen, überflüssige Plugins entfernen, Performance optimieren. Danach ist der Checkout sauber, testbar und wartbar.
Wann passt das: Wenn ein bestimmter Bereich überproportional viele Probleme verursacht. Typische Kandidaten: Checkout, Produktdaten-Import, Sucheintegration, Post-Launch-Wartungsprozesse.
Strategie 3: Replatforming als radikaler Schnitt
Manchmal ist Flicken teurer als Neubauen. Wenn euer System so viele Schulden angehäuft hat, dass jede Verbesserung mehr kostet als der Nutzen, den sie bringt, ist ein Plattformwechsel die ehrlichere Antwort.
In der Praxis: Euer Shopware-5-Shop hat 40 Custom-Plugins, eine eigenwillige Template-Struktur und eine Datenbankstruktur, die kein aktuelles ORM mehr versteht. Statt das System Plugin für Plugin zu modernisieren, migriert ihr auf Shopware 6 oder Shopify und baut sauber auf. Ja, das kostet. Aber die Alternative, den Altbestand weitere drei Jahre mitzuschleppen, kostet mehr.
Wann passt das: Wenn die Plattform selbst End-of-Life erreicht hat (wie Shopware 5) oder wenn die Schulden so tief in der Architektur stecken, dass inkrementeller Abbau unrealistisch ist.
Wer vor der Build-vs-Buy-Entscheidung für sein Frontend steht, findet dort einen verwandten Denkrahmen.
Wann Flicken reicht und wann ihr neu bauen müsst
Die schwierigste Frage bei technischen Schulden ist nicht “Haben wir welche?” (ja, habt ihr), sondern “Lohnt sich Reparieren noch?”
Eine einfache Matrix hilft bei der Einordnung:
Konkretes Beispiel 1: Euer Shopify-Shop hat ein langsames Theme mit zu vielen Liquid-Includes und drei überflüssigen Apps. Die Architektur ist gesund, das Problem ist oberflächlich. Lösung: Theme-Audit, Apps aufräumen, Performance-Sprint. Aufwand: 2 bis 4 Wochen.
Konkretes Beispiel 2: Euer Shopware-5-Shop hat 40 Custom-Plugins, eine angepasste Datenbank und einen Checkout, den nur ein ehemaliger Freelancer versteht. Shopware 5 hat keine Sicherheitsupdates mehr. Die Schulden stecken in der Architektur, und die Plattform ist am Ende. Lösung: Migration auf Shopware 6 oder einen anderen Stack. Aufwand: 3 bis 6 Monate.
Konkretes Beispiel 3: Euer Shop ist technisch solide, aber die Produktdaten sind ein Chaos aus Excel-Exporten und manueller Pflege. Das ist keine Architektur-Schuld, sondern ein Prozess-Problem. Lösung: PIM einführen, Datenqualität systematisch aufbauen. Aufwand: abhängig vom Sortiment, aber typischerweise 2 bis 4 Monate.
Die Antwort ist nie pauschal. Aber die ehrliche Analyse lohnt sich. Denn die teuerste Option ist fast immer: nichts tun und hoffen, dass es schon irgendwie weitergeht.
Häufige Fragen zu technischen Schulden
Was sind technische Schulden einfach erklärt?
Technische Schulden entstehen, wenn in der Softwareentwicklung Abkürzungen genommen werden, die kurzfristig Zeit sparen, aber langfristig Mehraufwand verursachen. Wie bei einem Kredit: Ihr gewinnt heute Geschwindigkeit, zahlt aber morgen Zinsen in Form von höheren Wartungskosten, langsamerer Entwicklung und steigendem Fehlerrisiko.
Wie entstehen technische Schulden im E-Commerce?
Die häufigsten Ursachen: Zeitdruck beim Relaunch, unkontrollierter Plugin-Einsatz, fehlende Tests und Dokumentation, gewachsene Checkout-Anpassungen und fragmentierte Produktdaten. Jede einzelne Entscheidung ist oft nachvollziehbar. Aber in Summe entsteht über Jahre ein System, das immer schwerer zu warten und weiterzuentwickeln ist.
Was kosten technische Schulden?
Laut Deloitte fließen 21 bis 40 Prozent des IT-Budgets in technische Schulden. Für einen mittelständischen Online-Händler bedeutet das konkret: langsamere Feature-Entwicklung (bis zu 60% der Entwicklerzeit geht für Schuldenmanagement drauf), häufigere Ausfälle, sinkende Performance und steigendes Sicherheitsrisiko. Die indirekten Kosten durch entgangenen Umsatz und verpasste Marktchancen sind oft höher als die direkten IT-Kosten.
Wie kann man technische Schulden messen?
Vier pragmatische Kennzahlen für Entscheider: Deployment-Frequenz (wie oft könnt ihr Änderungen live bringen?), Time-to-Feature (wie lange dauert es vom Request bis zum Go-live?), Incident-Rate (wie oft bricht etwas in Produktion?) und Developer-Zufriedenheit (wie zuversichtlich ist euer Team?). Diese Metriken funktionieren ohne spezielle Tools und sind auch für Nicht-Techniker verständlich.
Wie baut man technische Schulden ab?
Drei bewährte Strategien: (1) 15 bis 20 Prozent der Entwicklerkapazität dauerhaft für technische Verbesserungen reservieren. (2) Gezielte Modernisierungs-Sprints für die größten Problemzonen (z.B. Checkout-Refactoring). (3) Replatforming, wenn das System so stark belastet ist, dass Flicken teurer wird als Neubauen. Welche Strategie passt, hängt von der Tiefe und Verteilung der Schulden ab.
Wann sollte man ein Legacy-System komplett ersetzen?
Wenn drei Bedingungen gleichzeitig zutreffen: Die Plattform selbst hat End-of-Life erreicht oder verliert aktiv an Ökosystem-Support. Die Schulden stecken in der Architektur, nicht nur in einzelnen Komponenten. Und euer Wachstumsziel erfordert Fähigkeiten, die das aktuelle System strukturell nicht bieten kann (z.B. Headless Commerce oder Agent-Readiness).
Nächster Schritt
Technische Schulden verschwinden nicht von allein. Aber sie lassen sich managen, wenn ihr wisst, wo sie stecken und was sie kosten.
Wenn ihr unsicher seid, wie tief die Schulden in eurem Shop wirklich stecken: Sprecht uns an. Wir analysieren euren aktuellen Stack, identifizieren die größten Schuldenherde und zeigen euch den pragmatischsten Weg nach vorn. Ehrlich, ohne Agenturtheater, mit einem klaren Plan.
.jpeg)
.jpeg)
.avif)
