Abgebrochenes Softwareprojekt retten: So geht’s

Ein abgebrochenes Softwareprojekt retten Sie in dieser Reihenfolge: zuerst den Zugriff sichern (Code-Repository, Server, Domain, App-Store-Konten), dann den Code von einem unabhängigen Team prüfen lassen und erst danach anhand des Ergebnisses entscheiden, ob weiterentwickelt oder neu geschrieben wird. Der häufigste Fehler ist, als Erstes bei einer neuen Agentur ein Angebot für „den Rest“ anzufragen. Solange niemand den Code wirklich gesehen hat, ist jeder Preis geraten. Hier beschreiben wir die Schritte, die wir selbst gehen, wenn wir ein Projekt übernehmen.

Warum bleiben Softwareprojekte liegen?

Bei den Projekten, die wir übernehmen, steckt selten böse Absicht dahinter. Meist kommen mehrere Dinge zusammen: Der Umfang wurde nie schriftlich festgehalten und wächst deshalb ständig, ein Festpreis kann dieses Wachstum nicht tragen, und der Entwickler zieht sich langsam aus einem Projekt zurück, bei dem er draufzahlt. Kennt nur eine Person das System, reicht schon ein Jobwechsel. Manchmal ist auch das technische Fundament so schwach, dass jede neue Funktion zwei alte beschädigt und das Team nicht mehr vorankommt. Die Ursache zu kennen ist wichtig, denn nur so tappen Sie mit dem nächsten Team nicht in dieselbe Falle.

Was sichern Sie in den ersten 48 Stunden?

Wenn die Zusammenarbeit noch nicht ganz zerbrochen ist, holen Sie sich vor jeder technischen Diskussion folgende Zugänge auf Ihren Namen. Ist die Lage angespannt, fordern Sie alles in einer einzigen schriftlichen Liste an:

• Code-Repository: Owner-Rechte auf GitHub, GitLab oder Bitbucket. Ein ZIP-Archiv reicht nicht, denn die Commit-Historie zeigt, wie der Code entstanden ist.
• Server und Cloud-Konten: Hosting-Panel, Cloud-Anbieter, Datenbank und Backups. Prüfen Sie auch, über wessen Karte abgerechnet wird.
• Domain und DNS: Das Konto beim Registrar sollte auf Sie laufen.
• Store-Konten: App Store Connect und Google Play Console. Liegt die App im Konto des Entwicklers, planen Sie den Transfer als eigenen Schritt.
• Drittanbieter: Schlüssel für Zahlung, SMS, E-Mail, Karten und Push-Benachrichtigungen.
• Umgebungsvariablen, Installationsnotizen und vorhandene Designdateien.

Wer den Code hat, aber nicht Server, Domain und Store-Konto, besitzt nicht das Produkt, sondern nur eine Kopie davon.

Sobald Sie Zugriff haben, ändern Sie alle Passwörter und API-Schlüssel. Das ist kein Vorwurf, sondern ein normaler Übergabeschritt. Regelt Ihr Vertrag die Übertragung des Quellcodes und der Nutzungsrechte, läuft die Anfrage deutlich reibungsloser; warum diese Klauseln von Anfang an hineingehören, erklären wir im Beitrag zum Softwareentwicklungsvertrag. Dieser Text ist keine Rechtsberatung; bei einem Streit wenden Sie sich an einen Anwalt.

Wie läuft ein Code-Audit ab?

Beim Code-Audit startet das neue Team das Projekt tatsächlich und schaut hinein. Eine Einschätzung anhand von Demo oder Screenshots ist kein Audit. Ein gutes Audit beantwortet diese Fragen schriftlich:

• Lässt sich das Projekt anhand der Dokumentation auf einem frischen Rechner aufsetzen und starten?
• Welche Funktionen arbeiten wirklich, welche existieren nur auf dem Bildschirm?
• Sind Bibliotheken und Framework aktuell, oder gibt es Komponenten ohne Support?
• Ist die Datenbankstruktur schlüssig, gibt es echte Produktivdaten und wie werden sie geschützt?
• Gibt es offensichtliche Sicherheitslücken: Passwörter im Code, ungeschützte API-Endpunkte, Ansichten ohne Rechteprüfung?
• Gibt es Tests, Fehlerprotokollierung und automatisierte Deployments?

Ergebnis des Audits ist eine klare Einstufung jedes Moduls, etwa „solide“, „reparierbar“ oder „neu schreiben“. Diese Einstufung ist im Grunde eine Landkarte der technischen Schulden des Projekts und die einzige belastbare Grundlage für die nächste Entscheidung. Wie lange es dauert, hängt von der Projektgröße ab. Entscheidend ist, dass das Audit als eigener, abgegrenzter Auftrag bepreist wird. So erfahren Sie den Stand, ohne sich an den Folgeauftrag zu binden.

Weiterentwickeln oder neu schreiben?

Jedes neue Team möchte instinktiv neu schreiben, denn fremden Code zu lesen ist mühsamer, als eigenen zu schreiben. Treffen Sie die Entscheidung deshalb auf Basis des Audits und nicht aus dem Bauch. Als Faustregel gilt: Ist das Datenmodell solide und liegen die Probleme in einzelnen Modulen, ist Weiterentwickeln fast immer schneller. Ist das Datenmodell marode, läuft das Kern-Framework auf einer Version ohne Support oder lässt sich nichts ändern, ohne anderswo etwas kaputtzumachen, ist ein Neuschreiben das geringere Risiko.

Oft liegt die richtige Antwort dazwischen: Funktionierendes bleibt, das problematischste Modul wird zuerst neu geschrieben, der Rest schrittweise verbessert. Gibt es bereits Nutzer und Daten im Livebetrieb, ist eine Migration in Etappen sicherer als ein Umschalten über Nacht; die Schritte aus unserem Beitrag zur Datenmigration aus Altsystemen gelten auch hier.

Wie gelingt die Übergabe an ein neues Team?

Halten Sie den ersten Vertrag mit dem neuen Team klein: Audit plus erste kritische Korrekturen. So sehen Sie, wie das Team arbeitet, und binden nicht wieder alles an einen einzigen Auftrag. Für die restliche Arbeit verlangen Sie einen schriftlichen Leistungsumfang, Abnahmekriterien und Zahlungen nach Meilensteinen. Das Repository bleibt vom ersten Tag an in Ihrem Konto, das neue Team arbeitet darin mit. Welche Fragen Sie bei der Auswahl stellen sollten, haben wir in unserem Leitfaden zur Wahl eines Softwaredienstleisters zusammengestellt.

Damit sich die Geschichte nicht wiederholt, führen Sie mit der Übergabe drei Gewohnheiten ein: eine kurze Installationsanleitung, die mit jedem Release aktualisiert wird, Fehlerüberwachung und Logging, damit Probleme sichtbar werden, und eine Teamstruktur, in der mindestens zwei Personen das Projekt kennen.

Fazit

Ein abgebrochenes Softwareprojekt ist meist weniger verloren, als es sich anfühlt, doch die Reihenfolge der Rettung zählt: erst Zugriff, dann Audit, zuletzt die Entscheidung. Sprechen Sie nicht vor dem Audit über den Preis, und akzeptieren Sie kein Neuschreiben, das das Audit nicht begründet. Liegt bei Ihnen ein halbfertiges Projekt, prüft unser Team für individuelle Software zuerst den Stand und liefert eine schriftliche Einschätzung; danach können Sie bei Bedarf ein Angebot anfordern.