Ihr Entwicklungsdienstleister antwortet nicht mehr. Was in den ersten 14 Tagen zu tun ist
Das Drehbuch ist immer gleich. Eine Deadline verschiebt sich. Der wöchentliche Call wird kürzer, dann fällt er aus. Ihr Ansprechpartner wird durch jemanden ersetzt, dem man alles neu erklären muss. Sie fragen nach dem Quellcode, und der Ton ändert sich. Dann nichts mehr. Hier steht, was zu tun ist, der Reihe nach - und die Reihenfolge ist wichtiger als das Tempo.
Tag 1–3: Kontrolle, nicht Code
Suchen Sie nicht als Erstes einen neuen Entwickler. Finden Sie zuerst heraus, was Ihnen tatsächlich gehört. Listen Sie jeden Account auf, von dem das Produkt abhängt, und auf wessen Namen und E-Mail er jeweils läuft:
Alles, was auf den Dienstleister registriert ist, mieten Sie, statt es zu besitzen. Kleinunternehmer haben ihren Shop gesperrt und ihre Auszahlungen pausiert vorgefunden, weil ein „Agentur“-Account der einzige Admin war. Übertragen Sie heute, was Sie können; dokumentieren Sie, was nicht geht. Ändern Sie Passwörter und aktivieren Sie Zwei-Faktor-Authentifizierung für alles, was Ihnen gehört. Exportieren Sie die Datenbank, wenn Sie herankommen - eine Kopie von heute ist mehr wert als jedes Versprechen für morgen.
Tag 3–5: die Papierspur
Schreiben Sie dem Dienstleister eine sachliche E-Mail. Halten Sie fest, was vereinbart, was bezahlt und was geliefert wurde und was Sie bis zu einem bestimmten Datum brauchen: den vollständigen Quellcode mit Historie, alle Zugangsdaten, eine Dokumentation des Deployments. Drohen Sie nicht; seien Sie einfach konkret und setzen Sie sich selbst in Kopie. Antworten sie, haben Sie, was Sie brauchen. Antworten sie nicht, haben Sie den Anfang einer Forderung - die Sie vielleicht nie geltend machen, die aber das Gespräch mit Ihrer Bank, Ihrer Versicherung und den Plattformen verändert, deren Accounts Sie zurückholen wollen.
Sammeln Sie den Vertrag, jede Rechnung, jede Zahlungsbestätigung und jede Nachricht, in der eine Deadline oder ein Umfang vereinbart wurde. Für Rückbuchungen oder Streitfälle gibt es Fristen; finden Sie heraus, welche für Sie gilt.
Tag 5–10: die Wahrheit über den Code
Holen Sie jetzt einen Engineer dazu - aber noch nicht, um etwas zu reparieren. Sie wollen eine schriftliche Ist-Bewertung, die drei Fragen in dieser Reihenfolge beantwortet: was das Vertrauen blockiert (Sicherheitslücken, offengelegte Daten, Zahlungen, die nicht übereinstimmen), was die Lieferung bremst (Architektur, Tests, Deployment) und was warten kann. Sie sollte den Zustand des Repositorys, die Testabdeckung, die Infrastruktur und offene Schwachstellen in einer Sprache festhalten, mit der Nicht-Techniker, Investoren oder Anwälte arbeiten können.
Seien Sie vorsichtig mit der ersten Meinung, die Sie hören. „Von vorn anfangen“ ist das Bequemste, was ein neuer Entwickler sagen kann, und das Teuerste, was Sie tun können. Manchmal stimmt es. Häufiger sind die Teile des Systems, auf die sich Ihre Nutzer schon verlassen, mehr wert als die saubere Architektur, die ein Rewrite verspricht. Bitten Sie jeden Engineer, der einen Rewrite empfiehlt, schriftlich festzuhalten, warum - und was er behalten würde.
Wir waren schon das zweite Team. Wir beginnen mit Kontrolle und dem schriftlichen Audit - verwendbar gegenüber Investoren oder einem Anwalt -, dann stabilisieren und liefern wir, mit denselben Seniors vom ersten Call bis zum Launch.
Softwareprojekt retten →Tag 10–14: entscheiden, wer als Nächstes kommt
Sie haben sich die Finger verbrannt, also sind Sie jetzt der vorsichtigste Käufer am Markt. Nutzen Sie das. Bevor irgendjemand den Code anfasst, sollte Ihnen ein Rettungsteam bereitwillig zeigen:
Und eine Warnung aus den Geschichten derer, die sich zweimal verbrannt haben: Ein Unternehmen, das eine „Code-Übernahme“ anbietet und sich dann als eines ohne eigene Engineers entpuppt, ist keine Rettung. Fragen Sie, wer konkret die Arbeit macht - und lernen Sie diese Leute kennen.
Wie eine Rettung tatsächlich aussieht
Kontrolle zurückgeholt oder dokumentiert. Ein schriftliches Bild des Codes, das Sie jedem geben können. Die Blutung gestoppt - Abstürze, Sicherheit, Zahlungen - und Monitoring eingerichtet, damit der nächste Ausfall gesehen wird, bevor ein Nutzer ihn meldet. Dann bleibt das Produkt live, während kaputte Teile Stück für Stück ersetzt werden, mit Rewrite nur dort, wo das Risiko es erzwingt. Der Endzustand ist etwas, das eine technische Due Diligence bestehen würde: Tests, CI/CD, lesbare Historie, Dokumentation und ein Team - Ihres oder das eines Partners -, das es betreiben kann.
Der schwierigste Teil ist nicht technisch. Es ist das Vertrauen, dass diesmal ausgeliefert wird. Das einzige Mittel dagegen ist wöchentlicher, sichtbarer, klickbarer Fortschritt - deshalb sollten Sie als Erstes darauf bestehen. Wenn Sie besprechen wollen, wo Sie stehen, sagen Sie uns, worauf Sie Zugriff haben und worauf nicht; wir sagen Ihnen, was Sie heute noch sichern sollten.