Eine chaotische Codebasis übernehmen: So retten Sie ein festgefahrenes Projekt

Überraschend viele meiner Projekte beginnen gleich: Ein Gründer hat ein halb fertiges Produkt, der ursprüngliche Entwickler ist weg oder reagiert nicht mehr, und niemand kann erklären, wie es funktioniert. Das Projekt steht still, das bereits ausgegebene Budget scheint in Gefahr, und die Frage ist einfach, aber belastend: Lässt sich das retten, oder fangen wir von vorn an?

Ich habe viele solcher Projekte übernommen, und die Lage ist fast nie so hoffnungslos, wie sie sich im Moment anfühlt. Aber sie muss mit Sorgfalt behandelt werden. Wer hineinstürmt und blind Dinge ändert, macht aus einer Rettung schnell ein zweites Desaster. So gehe ich vor.

Das geschäftliche Problem: Sie stecken fest, und die Uhr läuft

Ein festgefahrenes Projekt schmerzt auf eine ganz bestimmte Weise. Sie haben bereits Geld und Zeit investiert, kommen nicht voran und wissen nicht einmal genau, was Sie haben. Jede Option fühlt sich riskant an: Weitermachen heißt vielleicht, auf Sand zu bauen; neu anfangen heißt vielleicht, Arbeit wegzuwerfen, die eigentlich in Ordnung war.

Der schlechteste Schritt ist Panik, also reflexartig alles aufzugeben oder jemanden einzustellen, der sofort mit dem Neuschreiben beginnt, ohne zu verstehen, was da ist. Beides verschwendet Geld. Der richtige erste Schritt ist immer derselbe: erst verstehen, dann anfassen.

Schritt eins: bewerten, bevor irgendetwas geändert wird

Bevor ich eine einzige Zeile ändere, will ich ein klares Bild davon, was existiert. Das heißt: Code lesen, die App ausführen und herausfinden:

• Was tatsächlich funktioniert und was kaputt oder halb fertig ist.
• Wie es gebaut ist: die Struktur, das Datenmodell, die wichtigsten Entscheidungen.
• Was gefährlich ist: fehlende Backups, Sicherheitslücken, kein sicherer Weg zum Deployment.
• Was veraltet ist: Festgefahrene Projekte hängen oft an einer Runtime- oder Framework-Version, die keine Sicherheitsupdates mehr bekommt. Node.js 20 zum Beispiel, vor ein paar Jahren eine gängige Wahl, hat im April 2026 sein End of Life erreicht. Das früh zu wissen zeigt Ihnen, ob Upgrades Teil des Plans sein müssen.
• Was sich retten lässt und was wirklich nicht mehr zu retten ist.

Diese Bewertung ist der wertvollste Teil einer Rettung. Sie verwandelt „wir haben keine Ahnung, was wir haben“ in eine klare, ehrliche Landkarte, und davon hängt jede gute Entscheidung danach ab.

Reparieren oder neu bauen? So entscheide ich

Das ist die Frage, auf die Gründer am dringendsten eine Antwort wollen, und die ehrliche Antwort lautet: „Es hängt von den Fundamenten ab.“ Die grobe Logik:

Eher reparieren, wenn die Kernstruktur solide ist, das Datenmodell Sinn ergibt, die Architektur vernünftig ist und die Probleme eher Unordnung und fehlende Teile sind als grundlegende Mängel. Die meisten festgefahrenen Projekte liegen hier. Sie brauchen keinen Neubau, sondern jemanden, der sie versteht, stabilisiert und die Arbeit zu Ende bringt.

Eher neu bauen, wenn die Fundamente wirklich kaputt sind: ein Datenmodell, das das Produkt nicht tragen kann, oder eine Architektur, die jede Änderung gefährlich macht. Selbst dann heißt es selten „alles wegwerfen“. Meist wird der kaputte Kern neu gebaut, während die funktionierenden Teile erhalten bleiben.

Ein Neuschreiben von Grund auf wirkt sauber und verlockend, wirft aber jede Lektion weg, die der bestehende Code bereits gelernt hat. Ich betrachte einen kompletten Neubau als letztes Mittel, nicht als Standard, denn meistens lässt sich das Projekt für deutlich weniger retten, als ein Neuanfang kosten würde. (Genau diese Fundamente richtig zu legen, soll ein gut abgegrenztes MVP übrigens von vornherein sicherstellen.)

Warum eine sorgfältige Übernahme wichtig ist

Eine überhastete Rettung schafft beim Beheben alter Probleme oft neue. Eine sorgfältige tut das Gegenteil: Sie stabilisiert, was fragil ist, dokumentiert, was ein Rätsel war, und bringt das Projekt an einen Punkt, an dem die Arbeit sicher weitergehen kann. Diese Dokumentation ist wichtiger, als Gründer erwarten: Oft ist das Projekt gerade deshalb ins Stocken geraten, weil alles nur im Kopf einer einzigen Person existierte. Wenn es aufgeschrieben ist, sind Sie nie wieder so verwundbar. Zuverlässiges Deployment und saubere Umgebungen sind meist ebenfalls Teil der Lösung, denn festgefahrene Projekte haben oft keinen sicheren Weg, Änderungen auszuliefern.

Ein realistisches Beispiel

Ein großer Teil meiner Arbeit bestand darin, den Code anderer zu übernehmen und weiterzuführen: Features fertigstellen, Wackeliges stabilisieren und Produkte an einen Punkt bringen, an dem sie tatsächlich ausgeliefert werden und wachsen konnten. Die Arbeit folgt immer demselben Muster: zuerst verstehen, Änderungen sicher machen, die richtigen Teile auf Basis der Fundamente reparieren oder neu bauen und unterwegs dokumentieren, damit die nächste Person (oder der Gründer) nicht raten muss. Die Erleichterung auf Gründerseite kommt meist weniger von cleverem Code als davon, endlich Klarheit darüber zu haben, was man hat, und einen realistischen Weg nach vorn zu sehen.

Häufige Fehler bei der Rettung eines Projekts

• In Panik einen kompletten Neubau starten, bevor man versteht, was tatsächlich da ist.
• Dinge ändern, bevor es einen sicheren Weg für Backups und Deployment gibt.
• Annehmen, dass alles schlecht ist, nur weil manches schlecht ist.
• Jemanden einstellen, der den bestehenden Code nicht lesen will und einfach neu anfangen möchte.
• Nicht dokumentieren, was man gelernt hat, sodass das Projekt immer nur eine Person vom nächsten Stillstand entfernt bleibt.
• Symptome behandeln statt der grundlegenden Ursachen des Chaos.

Wie ich eine Rettung angehe

1. Zuerst bewerten: Code lesen, ausführen und kartieren, was funktioniert und was gefährlich ist.
2. Ein Sicherheitsnetz einziehen: Backups und ein sicherer Deployment-Weg, bevor irgendetwas geändert wird.
3. Ihnen ein ehrliches Urteil geben: reparieren, teilweise neu bauen oder komplett neu bauen, mit Begründung.
4. Die dringenden Risiken stabilisieren, bevor etwas Neues hinzukommt.
5. Unterwegs dokumentieren, damit das Projekt nie wieder eine Blackbox ist.
6. Es voranbringen, hin zum Launch oder Meilenstein, an dem Sie festhingen.

Das Ziel ist, Sie mit möglichst wenig Verschwendung wieder in Bewegung zu bringen: retten, was es wert ist, nur ersetzen, was wirklich ersetzt werden muss, und Ihnen ein Projekt zurückgeben, dem Sie vertrauen können.

Sie stecken mit einem festgefahrenen Projekt fest?

Wenn Sie ein halb fertiges Produkt und einen Entwickler haben, der verstummt ist, oder eine Codebasis, die niemand erklären kann, kann ich sie ehrlich bewerten, Ihnen sagen, ob reparieren oder neu bauen sinnvoll ist, und sie dann wieder in Gang bringen.

Lesen Sie über meine Arbeitsweise, sehen Sie sich an, was ich gebaut habe, und nehmen Sie Kontakt auf, um mir den aktuellen Stand zu schildern. Finden wir gemeinsam den realistischen Weg nach vorn.