Wie Sie ein gescheitertes Softwareprojekt retten (und wann ein Neustart besser ist)

Projekte scheitern selten an einem Tag. Sie driften ab, und jedes Signal lässt sich für sich genommen leicht erklären. Zusammen sind sie schwer zu übersehen:

• Termine verschieben sich immer wieder, jedes Mal aus einem neuen Grund.
• Jede Fehlerbehebung macht etwas anderes kaputt, und dieselben Fehler kommen zurück.
• Niemand kann klar sagen, wann das Produkt startet.
• Der Entwickler oder die Agentur antwortet langsam oder gar nicht mehr.
• Sie haben keinen Zugang zum Code, zu den Servern oder zu den Accounts.
• Neue Entwickler sagen, sie könnten mit dem Code nicht arbeiten, „ohne ihn erst neu zu schreiben“.

Eines dieser Signale ist eine Warnung. Drei oder mehr bedeuten meist, dass das Projekt eine Rettung braucht und keine weitere Deadline.

Ein Beispiel: Ein Start-up, dessen Freelancer nicht mehr antwortet und als Einziger das Server-Passwort hat, braucht eine Rettung, selbst wenn der Code an sich in Ordnung ist.

Die erste Woche legt die Grundlage für alles Weitere. Vor jeder technischen Arbeit stehen vier Schritte:

• Neue Funktionen pausieren. Wer auf einer instabilen Basis weiterbaut, verteuert jede spätere Fehlerbehebung.
• Zugänge sichern. Stellen Sie sicher, dass Sie Code, Server, Domain und jeden Dienst kontrollieren, von dem das Produkt abhängt.
• Festhalten, was versprochen wurde und was existiert. Sammeln Sie Angebot, Vertrag, Designs und eine Liste dessen, was heute tatsächlich funktioniert.
• Zahlungen zurückhalten, die nicht an gelieferte Arbeit gebunden sind. Laufen Zahlungen nach Meilensteinen, pausieren Sie die nächste, bis ein klarer Plan steht.

Beginnen Sie nicht mit der Suche nach Schuldigen. Wer das Projekt in diesen Zustand gebracht hat und warum, zählt viel weniger als die Fragen, was sich jetzt tun lässt, was es kostet und wann das Produkt funktioniert.

Zugänge sind das, was Gründern am häufigsten fehlt, wenn es darauf ankommt. Prüfen Sie jeden Punkt dieser Liste und notieren Sie, wer ihn heute kontrolliert:

• Das Code-Repository mit vollständiger Historie, kein Zip-Archiv der letzten Version.
• Hosting- und Server-Accounts, einschließlich Datenbanken und Backups.
• Den Domain-Registrar und die DNS-Einstellungen.
• Entwickler-Accounts in den App Stores, falls es eine mobile App gibt.
• Externe Dienste: Zahlungen, E-Mail, Analytics, Karten, KI-APIs.
• Designdateien und jede vorhandene Dokumentation.

Liegt das Repository im Account einer anderen Person, bitten Sie um die Übertragung. Die Dokumentation von GitHub erklärt, wie bei einer Übertragung Historie, Issues und Pull Requests erhalten bleiben.

Wenn jemand nicht kooperiert, holen Sie zurück, was Sie von Ihrer Seite aus können: Domains und Hosting laufen oft über Ihre Karte oder Ihre E-Mail-Adresse, und das ist ein Weg zurück.

Ein Audit ist ein strukturierter Blick auf das Produkt, wie es tatsächlich ist, nicht wie der letzte Dienstleister es beschrieben hat. Ein nützliches Audit deckt diese Bereiche ab:

• Architektur. Wie die Teile zusammenhängen und ob die Struktur die Funktionen tragen kann, die Sie brauchen.
• Codequalität. Lesbarkeit, Duplikate und wie riskant Änderungen sind.
• Sicherheit. Typische Risiken wie die aus den OWASP Top 10, dazu die Frage, wie Geheimnisse und personenbezogene Daten gespeichert werden.
• Infrastruktur. Hosting, Deployment, Backups und Monitoring.
• Tests und Dokumentation. Was vorhanden ist, was fehlt und was es kosten würde, es zu ergänzen.

Das Ergebnis sollte für jeden Teil des Produkts ein klares Urteil sein: behalten, reparieren oder neu schreiben, jeweils mit Begründung. Erst dann kann jemand einen Preis nennen, der den Code so abbildet, wie er ist.

Bei Sakura arbeiten wir genau in dieser Reihenfolge: erst das Audit, dann das Angebot. Nur so wird eine Rettung nicht auf Versprechen kalkuliert, die der Code nicht hält.

Steckt Ihr Projekt gerade fest? Erzählen Sie uns, was passiert ist. Wir beginnen mit Zugängen und Audit und sagen Ihnen ehrlich, was sich retten lässt.

Meistens reparieren. Alter Code, der in Produktion läuft, enthält Jahre kleiner Korrekturen für reale Probleme, und ein Neubau wirft sie zusammen mit den schlechten Teilen weg.

Joel Spolsky hat das in seinem bekannten Essay Things You Should Never Do beschrieben. Er nannte das Neuschreiben von Code von Grund auf „den schlimmsten strategischen Fehler, den ein Softwareunternehmen machen kann“, mit Netscape als Beispiel: Der Neubau dauerte fast drei Jahre, während die Konkurrenz davonzog.

Es gibt Fälle, in denen ein Neubau die ehrliche Antwort ist. Diese Tabelle zeigt, wie wir abwägen:

Selbst wenn ein Neubau gewinnt, muss er selten auf einmal passieren. Das Strangler-Fig-Muster von Martin Fowler beschreibt, wie man ein System Stück für Stück ersetzt: Neue Teile entstehen neben den alten, bis sich der alte Code abschalten lässt.

Ist der bisherige Entwickler oder die Agentur noch erreichbar, spart eine ruhige, kurze Übergabe Zeit und Geld. Bitten Sie um drei Dinge: Zugang zu allem, eine Liste bekannter Probleme und eine einstündige Einführung, wie das Produkt deployt wird.

Halten Sie das Gespräch sachlich. Menschen erzählen mehr, wenn sie nicht beschuldigt werden, und die Details, an die sie sich beim Code erinnern, sind mehr wert als jeder Streit darüber, wer schuld ist.

Kooperiert das bisherige Team nicht, warten Sie nicht darauf. Holen Sie die Accounts zurück, die Sie kontrollieren, beginnen Sie das Audit mit dem, was vorhanden ist, und dokumentieren Sie schriftlich, was Sie wann angefordert haben.

Sobald das Urteil steht, arbeiten Sie in einer strikten Reihenfolge. Erst der Launch, dann die Verbesserungen:

• Stabilisieren. Beheben Sie die kritischen Fehler, die das Produkt abstürzen lassen, Daten verlieren oder Zahlungen blockieren.
• Launch-Abläufe fertigstellen. Vollenden Sie nur, was das Produkt für den Start braucht; alles andere wartet.
• Deployment und Monitoring einrichten. Damit Releases zur Routine werden und Probleme sichtbar sind, bevor Nutzer sie melden.
• Launchen. Echte Nutzer zeigen Ihnen, welche der verbliebenen Probleme wirklich zählen.
• Verbessern. Arbeiten Sie den Rest der Liste nach Auswirkung auf das Geschäft ab.

Wöchentliche Builds, die Sie durchklicken können, halten die Rettung ehrlich. Nachdem ein Projekt einmal schiefgelaufen ist, sollten Sie den Fortschritt jede Woche sehen, nicht nur davon hören.

Ein Beispiel: Ein Start-up, dessen Agentur mehrere Termine verpasst hat, stellt vielleicht fest, dass der Großteil des Produkts funktioniert und drei defekte Abläufe den Launch blockieren. Werden diese drei zuerst repariert, geht das Produkt live, und der restliche Backlog lässt sich mit echten Nutzungsdaten planen.

Das hängt davon ab, was das Audit findet, deshalb kommt ein ehrliches Angebot nach dem Audit und nicht davor. Wer eine Rettung kalkuliert, ohne in den Code zu schauen, rät.

Nach dem Audit lässt sich die Arbeit bis zum Launch meist als fester Umfang kalkulieren. So bekommen Sie eine klare Zahl für den Weg zum Livegang, getrennt von den Verbesserungen danach.

Vergleichen Sie Angebote für die Rettung selbst, gelten dieselben Regeln wie bei jedem Projekt. Unser Leitfaden Festpreis oder Stundenabrechnung erklärt, wann welches Modell passt.

Ein gerettetes Projekt ist die Chance, die Schutzmaßnahmen einzuführen, die beim ersten Mal gefehlt haben:

• Eigentum. Repository, Hosting, Domain und App-Store-Accounts bleiben auf Ihr Unternehmen eingetragen.
• Dokumentation. Sie entsteht während der Arbeit, damit das Produkt nie wieder von einer einzelnen Person abhängt.
• Meilensteine. Zahlungen folgen auf prüfbare Ergebnisse, etwa einen funktionierenden Build unter einem Testlink.
• Ein Änderungsprozess. Neue Anforderungen werden geschätzt und freigegeben, bevor jemand daran arbeitet.
• Support nach dem Launch. Ein klarer Plan für Fehlerbehebungen und Updates, etwa ein monatlicher Supportplan.

Wählen Sie für die nächste Phase ein neues Team, nennt unser Leitfaden dazu, wie Sie eine Entwicklungsagentur auswählen, die Fragen, die schwache Partner vor der Unterschrift entlarven.

Wenn Sie Ihr Produkt wieder in Bewegung bringen möchten, schicken Sie uns ein kurzes Briefing. Wir beginnen mit Zugängen und Audit, damit Sie vor jeder größeren Verpflichtung wissen, wo Sie stehen.