Warum Rewrites Startups töten (und wie du sie vermeidest)

Fast jedes Startup führt irgendwann dasselbe Gespräch: „Wir müssen das neu schreiben. Der Code ist ein Chaos. Es wurde zu schnell gebaut. So skalieren wir nie." Der Rewrite klingt nach Erleichterung — ein Reset, die Chance, es diesmal richtig zu machen. In Wirklichkeit töten Rewrites mehr Startups, als schlechte Ideen es je tun. Nicht sofort, sondern langsam, leise und teuer. Es ist eine so bekannte Falle, dass einer der meistzitierten Essays der Softwarewelt, Joel Spolskys „Things You Should Never Do", den kompletten Rewrite „den schlimmsten strategischen Fehler" nennt, den ein Softwareunternehmen machen kann. Dieser Leitfaden erklärt, warum sich der Instinkt so richtig anfühlt, was ein Rewrite tatsächlich kostet, wann einer wirklich gerechtfertigt ist, und welchen inkrementellen Weg du stattdessen gehst.

Die wichtigsten Punkte

Die Rewrite-Illusion: warum sie sich so richtig anfühlt

Rewrites sind attraktiv, weil sie sauberen Code, bessere Performance, einen modernen Stack, weniger Bugs und — irgendwann — schnellere Entwicklung versprechen. Psychologisch fühlt sich der Neuanfang wie Fortschritt an. Für Startups ist es aber meist Vermeidung, keine Lösung. Du reparierst das System nicht; du fliehst davor. Und das, wovor du fliehst — unklare Struktur — folgt dir in den neuen Code, weil Struktur eine Design-Entscheidung ist, kein Sprach- oder Framework-Feature. Das ist dieselbe Fehldiagnose wie beim Beschuldigen des Frameworks, obwohl die Architektur das echte Problem ist.

Was ein Rewrite wirklich kostet (jenseits von Code)

Die meisten Teams unterschätzen die wahren Kosten, weil die teuren Teile nie auf einem Ticket auftauchen.

1. Verlorenes Time-to-Market

Ein Rewrite pausiert den Markt nicht. Während du neu baust, liefern Wettbewerber, Nutzer erwarten Verbesserungen, Investoren wollen Traktion und Sales-Pipelines stocken. Ein 3–6-monatiger Rewrite bedeutet oft, ein ganzes Marktfenster zu verpassen — ein Verlust, der selten in Jira auftaucht, aber regelmäßig Unternehmen tötet.

2. Neu bauen, was du vergessen hattest zu haben

Rewrites starten fast nie aus einer vollständigen, korrekten Spezifikation. Teams vergessen Edge Cases, die „temporären" Fixes, die leise zu Business-Regeln wurden, Compliance-Logik, Analytics-Eigenheiten und Integrationen, die nur existieren, weil die Realität sie verlangt hat. Das neue System startet „sauber", aber funktional unvollständig — und Nutzer merken sofort, was fehlt. Also baust du wieder, diesmal unter Druck.

3. Kontextverlust ist dauerhaft

Dein ursprüngliches System kodiert Jahre an eingebautem Wissen: warum die Dinge so sind, wie sie sind, was zuvor scheiterte, was Kunden wirklich brauchen statt was geplant war. Während eines Rewrites gehen die Original-Autoren, die Doku ist unvollständig, und Annahmen ersetzen Wissen. Das neue System sieht vielleicht besser aus und versteht das Geschäft gleichzeitig schlechter — und dieser verlorene Kontext ist extrem schwer wiederherzustellen.

4. Du frierst die Produktentwicklung ein

Viele Rewrites verlangen einen Feature-Freeze: keine Experimente, kein schnelles Feedback, keine Iteration Richtung Product-Market-Fit. Ironischerweise schreiben Teams oft deshalb neu, weil sie PMF nicht gefunden haben — und stoppen dann genau den Prozess, der ihnen helfen könnte, ihn zu finden.

5. Rewrites vervielfachen Risiko, sie reduzieren es nicht

Über einen langen Zeitraum läufst du zwei Systeme gleichzeitig: das alte, das noch Nutzer bedient, und das neue, das noch unvollständig ist. Zwei Codebasen, zwei Bug-Oberflächen, zwei operative Risiken. Startups sind selten so besetzt, dass sie diese Doppellast überstehen — und diese Schuld als Business-Problem statt als Dev-Problem zu behandeln hält die Entscheidung ehrlich.

Der echte Grund, warum Teams neu schreiben (und er ist nicht technisch)

Rewrites starten selten wegen Traffic. Sie starten wegen unklarer Architektur, vermischter Verantwortlichkeiten, frontend-getriebener Logik, fehlender Domänengrenzen und keinem Ownership-Modell. Mit anderen Worten: das System hat keine Struktur. Ein Framework-Wechsel behebt das nicht. Neue Syntax behebt das nicht. Ein „moderner Stack" behebt das nicht. Architektur tut es — und Architektur lässt sich fast immer im Bestand verbessern.

Das gefährlichste Rewrite-Muster

Dieses tötet Unternehmen leise: MVP schnell gebaut → Traktion erscheint → System fühlt sich fragil an → Rewrite genehmigt → sechs Monate vergehen → Traktion stockt → Moral sinkt → Funding-Druck steigt → Rewrite immer noch nicht fertig. An diesem Punkt ist das Startup technisch „am Leben", aber strategisch tot. Der Niedergang ist graduell genug, dass keine einzelne Woche wie der Fehler aussieht.

Warum Rewrites unausweichlich wirken (es aber nicht sind)

Ein Rewrite wirkt unausweichlich, wenn alles mit allem gekoppelt ist, Änderungen unzusammenhängende Features brechen, Deployments angstmachend sind, Performance-Probleme mysteriös sind und kaum jemand dem System traut. Aber nichts davon sind Rewrite-Signale — es sind Architektur-Rescue-Signale. Jedes davon lässt sich angehen, ohne das System wegzuwerfen, und das ist dramatisch billiger als ein Neuanfang.

Pro-Tipp: Bevor du einen Rewrite genehmigst, mach den „ein riskantes Modul"-Test. Nimm den einzelnen angstmachendsten Teil des Codes und versuch, eine saubere Schnittstelle darum zu legen und nur dieses Stück zu ersetzen, während alles andere weiterläuft. Wenn du es kannst — brauchst du keinen Rewrite, sondern diese Übung ein paar Mal wiederholt. Wenn du wirklich nicht einmal ein Modul isolieren kannst, ist das der seltene Beleg, dass ein Rewrite gerechtfertigt sein könnte.

Die Alternative, die funktioniert: inkrementelle Architektur-Reparatur

High-performende Teams machen selten große Rewrites. Sie machen kontrollierte Evolution, und in der Praxis sind das vier Schritte:

• Kern stabilisieren — kritische Domänen identifizieren, Schnittstellen festklopfen und unkontrollierte Änderungen an den wichtigsten Teilen stoppen.
• Grenzen ziehen ohne Rewrite — APIs extrahieren, Logik isolieren und Modularität innerhalb des bestehenden Systems einführen.
• Teile ersetzen, nicht alles — das Strangler-Fig-Pattern nutzen: das alte System umhüllen, neue Funktionalität durch den neuen Code routen und Legacy-Teile mit paralleler Validierung schrittweise abschalten.
• Weiter liefern — kein Feature-Freeze, keine Marktpause, kein Reset des Lernens.

Das ist langsamer in Woche eins und massiv schneller über die nächsten zwei Jahre. Es ist dieselbe Philosophie wie hinter mitwachsenden Architekturen, die SaaS ohne Relaunch skalieren und den Übergängen, die ein Produkt auf dem Weg vom MVP zu 100k Usern durchläuft.

Wann ein Rewrite wirklich gerechtfertigt ist

Rewrites sind selten, nicht verboten. Einer ergibt nur Sinn, wenn das System grundlegend nicht zu retten ist, wenn rechtliche oder Security-Zwänge einen Austausch erzwingen, wenn sich die Produktrichtung komplett geändert hat oder wenn das alte System das Geschäft aktiv blockiert und sich keine Grenze um den Blocker ziehen lässt. Der Test ist einfach: Wenn du nicht präzise artikulieren kannst, warum inkrementelle Änderung unmöglich ist, brauchst du wahrscheinlich keinen Rewrite — sondern architektonische Klarheit.

Meine Sicht: Rewrites sind Angst im Clean-Code-Kostüm

Über die Jahre saß ich in vielen dieser Meetings, und das Muster ist bemerkenswert konstant. Der Rewrite wird als Mut gerahmt — die mutige Entscheidung, mit dem Flicken aufzuhören und es richtig zu machen. In Startups ist es fast immer das Gegenteil: die Angst vor einem System, das niemand mehr ganz versteht, verkleidet als Engineering-Ehrgeiz. Die Teams, die vorne landen, sind selten die, die neu angefangen haben. Es sind die, die die zwei, drei Grenzen fanden, die zählten, sie sauber zogen und die ganze Zeit weiterlieferten.

Momentum ist das Asset, um das Startups tatsächlich konkurrieren — sie gewinnen, indem sie schneller lernen, liefern und sich anpassen, und ein Rewrite verlangsamt alle drei auf einmal. Das macht ihn so gefährlich: Er tauscht das Eine, das du nicht zurückkaufen kannst, gegen das Versprechen von Code, über den du dich besser fühlst. Repariere, was zählt, im Bestand, ohne das Produkt anzuhalten.

— Anna

Hol dir ein Architektur-Review, bevor du neu schreibst

Wenn du über einen Rewrite nachdenkst, starte stattdessen mit einem Architektur-Review. Bei H-Studio helfen wir Teams, zu trennen, was wirklich kaputt ist — Architektur oder Implementierung — und inkrementelle Reparaturwege zu designen, die die Rewrite-Falle vermeiden. Für Backend-Architektur ziehen wir modulare Grenzen und Domänentrennung, ohne das Produkt anzuhalten; für DevOps und Release-Sicherheit machen wir Deployments langweilig, was den Rewrite-Impuls oft komplett auflöst. Wenn du noch in der MVP-Phase bist, bauen wir Architektur, die sich weiterentwickeln kann von Tag 1, sodass Rewrites selten nötig werden.

Sieh dir an, wie wir EventStripe ohne Rewrites skaliert haben, oder wie Forschungsmittel migrierte und dabei das Momentum bewahrte. Ein Architecture Sprint ist ein schneller, strukturierter Weg, „sollen wir neu schreiben?" in einen konkreten, risikoärmeren Plan zu verwandeln.

FAQ

Sind Software-Rewrites immer eine schlechte Idee?

Nein — aber sie sind viel seltener nötig, als der Instinkt nahelegt. Ein Rewrite ist gerechtfertigt, wenn das System wirklich nicht zu retten ist, wenn rechtliche oder Security-Zwänge ihn erzwingen oder wenn sich die Produktrichtung grundlegend geändert hat. Für die meisten Startups ist das echte Problem fehlende Struktur, die inkrementelle Architektur-Reparatur mit einem Bruchteil des Risikos behebt.

Was ist das Strangler-Fig-Pattern?

Es ist eine inkrementelle Migrationsstrategie, bei der neue Funktionalität um das bestehende System gebaut und Legacy-Komponenten Stück für Stück abgeschaltet werden, sodass neues und altes System parallel laufen und Ergebnisse laufend validiert werden. Es vermeidet den „Big Bang"-Cutover, bei dem bis zum Schluss nichts funktioniert.

Wie lange dauert ein Startup-Rewrite tatsächlich?

Fast immer länger als geschätzt, weil Rewrites selten aus einer vollständigen Spezifikation starten — vergessene Edge Cases, „temporäre" Business-Regeln und undokumentierte Integrationen tauchen mitten im Bau wieder auf. Ein geplanter 3–6-Monats-Rewrite überschreitet häufig ein Marktfenster, und genau dort entsteht der strategische Schaden.

Wie weiß ich, ob ich einen Rewrite oder nur Refactoring brauche?

Mach den Isolations-Test: Kannst du eine saubere Schnittstelle um dein angstmachendstes Modul legen und nur dieses Stück ersetzen, während alles andere weiterläuft? Wenn ja, brauchst du inkrementelle Reparatur, keinen Rewrite. Wenn du wirklich kein einziges Modul isolieren kannst, ist das das seltene Signal, dass ein Rewrite gerechtfertigt sein könnte.

Warum schaden Rewrites dem Momentum so sehr?

Weil sie die Produktentwicklung einfrieren (oft ein wörtlicher Feature-Freeze), dich zwingen, bereits vorhandene Funktionalität neu zu bauen, und dich zwei Systeme gleichzeitig betreiben lassen. Startups gewinnen über die Geschwindigkeit des Lernens und Lieferns — ein Rewrite verlangsamt all das und tauscht dein knappstes Asset gegen Code, der sich nur sauberer anfühlt.

Weiterführende Artikel

• Next.js ist nicht das Problem — deine Architektur ist es — warum ein Framework-Wechsel denselben Schmerz reproduziert
• Warum Technical Debt ein Business-Problem ist — wie Schuld zur strategischen statt Dev-Entscheidung wird
• Mitwachsende Architekturen: SaaS skalieren ohne Relaunch — die inkrementelle Alternative im Detail
• Warum Geschwindigkeit ohne Architektur eine Falle ist — wie „schnelle" MVPs die Fragilität erzeugen, die Rewrites auslöst

Lektoriert und faktengeprüft von Anna Hartung