Abhängigkeit vom Softwareentwickler: So sicherst du dein Projekt bei einem Ausfall ab
Fällt dein Entwickler aus, reicht eine Kopie des Quellcodes selten aus. So sicherst du Zugänge und Betriebswissen, damit ein anderes Team übernehmen kann.

Die Abhängigkeit vom Softwareentwickler sinkt, wenn dein Unternehmen die technischen Konten kontrolliert und das Betriebswissen dokumentiert ist. Dazu gehören aktueller Quellcode und Tests der wichtigsten Abläufe. Ob diese Absicherung reicht, zeigt ein einfacher Praxistest: Kann ein anderer Entwickler deine Software ohne mündliche Hilfe starten und ändern?
Kurz gesagt: Die Konten laufen auf dein Unternehmen, der Entwickler erhält entziehbare Zugriffe. Quellcode, Dokumentation und Tests müssen laufend verfügbar sein. Eine Probeübernahme zeigt, welche Lücken noch bestehen.
Stand: Oktober 2026. Dieser Artikel erklärt die technische Absicherung und ersetzt keine Rechtsberatung. Fragen zu Nutzungsrechten und vertraglichen Ansprüchen klärst du mit einem Anwalt.
Wann wird die Abhängigkeit vom Softwareentwickler zum Problem?
Die Abhängigkeit vom Softwareentwickler wird kritisch, sobald nur eine Person den Betrieb sichern oder Änderungen veröffentlichen kann. Das kann bei einem Einzelentwickler genauso passieren wie innerhalb einer Agentur.
Ein typisches Beispiel ist eine interne Anwendung für Angebote. Dein Team erfasst Positionen, erzeugt ein PDF und verschickt es an Kunden. Nur der Entwickler weiß, wie eine neue Version auf den Server kommt.
Fällt er aus, läuft die Anwendung möglicherweise zunächst weiter. Beim nächsten Fehler fehlt aber jemand, der eingreifen kann. Hängt auch das Serverkonto an seiner privaten E-Mail-Adresse, kannst du nicht einmal einem Ersatzteam Zugang geben.
Frag deshalb konkret: Wer kann eine neue Version veröffentlichen, wenn dein Ansprechpartner nicht erreichbar ist? Hat diese Person das mit deinem Projekt schon gemacht? Eine Vertretung auf dem Papier hilft wenig, wenn sie weder Zugänge noch Projektkenntnisse besitzt.
Auch ein gut vorbereitetes Ersatzteam braucht Einarbeitung. Du kannst aber verhindern, dass es zuerst nach Passwörtern suchen und den Aufbau erraten muss.
Welche Konten müssen unter deiner Kontrolle stehen?
Die Konten für Code und Betrieb sollten von Anfang an auf dein Unternehmen laufen. Der Entwickler bekommt einen eigenen Zugang mit den erforderlichen Berechtigungen, den du wieder entziehen kannst.
Das betrifft mehr als den Server. Auch die Domain, also deine Internetadresse, und externe Dienste können den Betrieb blockieren. Läuft etwa der E-Mail-Versand über ein fremdes Konto, bist du bei einer Sperrung auf dessen Inhaber angewiesen.
| Bereich | Was dein Unternehmen kontrollieren sollte | So prüfst du den Zugriff |
|---|---|---|
| Domain und Hosting | Hauptkonto, Abrechnung und Kontowiederherstellung. Hosting ist der Betrieb deiner Anwendung auf einem Server. | Melde dich selbst an und öffne die Verwaltung. |
| Quellcode | Das Repository, also die zentrale Codeablage mit Änderungshistorie | Prüfe, ob du den aktuellen Stand sehen und herunterladen kannst. |
| Datenbank und Sicherungen | Datenverwaltung, Export und Sicherungskopien | Lass eine Sicherung in einer getrennten Umgebung wiederherstellen. |
| App-Veröffentlichung | Unternehmenskonten in den App-Stores und benötigte Freigaben | Lass einen weiteren berechtigten Entwickler eine Testveröffentlichung vorbereiten. |
| Externe Dienste | Konten etwa für E-Mail-Versand oder Terminbuchung | Prüfe Abrechnung und Benutzerverwaltung. |
Du musst diese Systeme nicht selbst bedienen können. Du musst aber einem neuen Team Zugang geben können. Ein Bildschirmfoto der Kontoverwaltung ist dafür kein Nachweis.
Sichere auch den Weg zurück ins Konto
Die E-Mail-Adresse zur Kontowiederherstellung muss in deinem Unternehmen erreichbar sein. Bei einer Zwei-Faktor-Anmeldung brauchst du neben dem Passwort einen weiteren Nachweis, etwa eine Bestätigung per App. Dessen Wiederherstellung darf nicht allein am privaten Handy des Entwicklers hängen.
Nutze einen Passwortmanager des Unternehmens für zentrale Zugangsdaten und Wiederherstellungscodes. Vergib nach Möglichkeit persönliche Benutzerkonten. So kannst du einzelne Zugriffe entziehen, ohne ein gemeinsam verwendetes Passwort überall ersetzen zu müssen.
Bei mawu laufen Repository, Hosting, Domains und Store-Konten von Beginn an auf den Konten des Kunden. Wir arbeiten mit Zugriff statt Besitz; der Zugriff ist jederzeit entziehbar.
Reicht eine Kopie des Quellcodes für die Übergabe?
Eine Kopie des Quellcodes reicht meist nicht für die Übergabe. Das Ersatzteam braucht zusätzlich die Einstellungen und Anleitungen, mit denen daraus eine laufende Anwendung wird.
Quellcode ist der lesbare Programmtext. Er enthält beispielsweise die Regeln, nach denen dein Angebotsprogramm Rabatte berechnet. Für den E-Mail-Versand braucht die Anwendung zusätzlich einen Zugangsschlüssel zum Versanddienst.
Solche Schlüssel gehören nicht ungeschützt in die Codeablage. Dokumentiert sein muss aber, welche Schlüssel gebraucht werden und wo berechtigte Personen sie erhalten.
Für eine technische Übergabe brauchst du:
- Den aktuellen Quellcode mit Änderungshistorie und einer Kennzeichnung der derzeit eingesetzten Version.
- Eine Anleitung zum Einrichten und Starten der Entwicklungsumgebung.
- Eine Liste der benötigten Softwarebausteine und ihrer Versionen.
- Die Schritte zur Veröffentlichung auf dem Server oder im App-Store.
- Anweisungen für Datenbankänderungen sowie einen beschriebenen Rückweg bei Fehlern.
Eine Codekopie vom Projektbeginn reicht nicht, wenn seitdem Funktionen hinzugekommen sind. Vereinbare deshalb laufenden Zugriff auf die tatsächliche Entwicklungsablage. Der Zugriff sollte nicht erst am Tag einer Kündigung organisiert werden.
Technischer Zugriff und Nutzungsrechte sind getrennte Fragen. Ob ein anderes Team den Code bearbeiten darf, muss rechtlich geklärt sein. Mehr dazu findest du im Ratgeber Wem gehört der Code? Nutzungsrechte bei der Auftragsentwicklung.
Was muss in der Dokumentation stehen?
Die Dokumentation muss erklären, wie deine Anwendung betrieben und geändert wird. Sie sollte außerdem Geschäftsregeln festhalten, die ein neuer Entwickler nicht aus eigener Erfahrung kennen kann.
Beim Angebotsprogramm könnte eine solche Regel lauten: Ein verschicktes Angebot darf nicht mehr überschrieben werden. Eine Korrektur erzeugt eine neue Fassung. Fehlt diese Information, kann ein Ersatzteam die Regel bei einer Änderung versehentlich aufheben.
Anforderungen beschreiben, was die Software können soll. Betriebsunterlagen erklären, wie die fertige Anwendung läuft. Für die fachliche Grundlage hilft dir der Ratgeber Lastenheft App: Was vor der Entwicklung hinein muss.
Beschreibe auch Fehlerfälle und Sonderwege
Eine Anleitung muss nicht jede Schaltfläche erklären. Sie muss beantworten, wie eine neue Version veröffentlicht wird und woran ein Fehler erkennbar ist. Dazu gehört, wo Fehlermeldungen gespeichert werden und wer sie erhält.
Auch manuelle Schritte gehören hinein. Muss jemand nach einem Datenimport eine Freigabe erteilen, darf das nicht nur im Kopf des bisherigen Entwicklers stehen. Dasselbe gilt für bekannte Fehler und vorläufige Lösungen.
Lass die Unterlagen bei technischen Änderungen mitpflegen. Eine ausführliche Anleitung für einen längst ersetzten Server hilft beim Ausfall genauso wenig wie gar keine.
Wie helfen verbreitete Technologien und automatisierte Tests?
Verbreitete Technologien erleichtern die Suche nach einem Ersatzteam. Automatisierte Tests helfen diesem Team zu erkennen, ob eine Änderung bestehende Abläufe beschädigt.
Ein automatisierter Test führt einen festgelegten Prüfschritt aus und vergleicht das Ergebnis mit einer Erwartung. Beim Angebotsprogramm kann er nachrechnen, ob ein Rabatt korrekt angewendet wird. Ein anderer Test prüft, ob ein Mitarbeiter Angebote eines fremden Unternehmens öffnen kann.
Teste zuerst die Abläufe, deren Ausfall deinen Betrieb trifft. Wenn Aufträge aus dem Kundenportal in die Auftragsverwaltung übertragen werden, muss diese Übertragung geprüft werden. Dazu gehört der Fehlerfall: Was passiert, wenn die Auftragsverwaltung gerade nicht erreichbar ist?
Die Testdateien müssen dem Ersatzteam vorliegen und ausführbar sein. „Wir haben alles getestet“ sagt wenig darüber aus, ob ein neuer Entwickler diese Prüfung wiederholen kann.
Bekannte Werkzeuge ersetzen keinen verständlichen Aufbau
Auch mit einer verbreiteten Programmiersprache lässt sich schwer übernehmbare Software bauen. Frag deshalb nach selbst entwickelten Grundbausteinen. Welchen konkreten Vorteil bringen sie, und wer außer ihrem Autor kann sie warten?
Meist sind etablierte Werkzeuge die bessere Wahl, wenn sie die Anforderungen erfüllen. Eine eigene technische Grundlage kann sinnvoll sein. Sie sollte aber einen nachvollziehbaren Nutzen haben und dokumentiert sein.
Wie prüfst du, ob ein anderes Team übernehmen kann?
Eine Probeübernahme zeigt, ob Zugänge und Unterlagen tatsächlich ausreichen. Dafür richtet ein anderer Entwickler die Anwendung in einer getrennten Testumgebung ein, ohne mündliche Anleitung des bisherigen Teams.
Eine Testumgebung ist eine separate Installation außerhalb des laufenden Betriebs. Sie sollte geeignete Testdaten verwenden und keine echten Kunden anschreiben. Automatische E-Mails müssen dort beispielsweise an ein Testpostfach gehen oder deaktiviert sein.
Der Prüfer lädt den Code, richtet die Anwendung ein und führt die vorhandenen Tests aus. Anschließend veröffentlicht er einen Teststand. Jede notwendige Rückfrage zeigt eine Lücke in den Unterlagen oder Zugängen.
Prüfe dabei auch die Datensicherung. Eine vorhandene Sicherungsdatei beweist noch nicht, dass sich die Anwendung damit wiederherstellen lässt. Entscheidend ist, ob das Wiederherstellen funktioniert und die Daten anschließend nutzbar sind.
Plane diese Prüfung vor dem ersten produktiven Einsatz ein. Nach größeren technischen Umbauten sollte sie wiederholt werden. Die Übergabeunterlagen gehören deshalb bereits in die Projektplanung, etwa beim Vorgehen von der Konzeption bis zur Wartung.
Was tun, wenn der Entwickler bereits ausgefallen ist?
Ist der Entwickler bereits ausgefallen, sichere zuerst den laufenden Betrieb und erfasse die vorhandenen Zugänge. Beauftrage dann eine technische Bestandsaufnahme, bevor jemand größere Änderungen vornimmt.
Prüfe zunächst offene Rechnungen und Warnmeldungen in den erreichbaren Konten. Eine abgelaufene Zahlungskarte beim Hostinganbieter kann dringender sein als eine fehlende Funktionsbeschreibung. Kontrolliere auch, ob Benachrichtigungen nur an den bisherigen Entwickler gehen.
Gehe anschließend in dieser Reihenfolge vor:
- Erfasse die erreichbaren Systeme und die jeweiligen Kontoverantwortlichen.
- Lass verfügbaren Code, Daten und Einstellungen sichern, soweit du dazu berechtigt bist.
- Lass ein Ersatzteam die Anwendung in einer getrennten Umgebung untersuchen.
- Kläre fehlende Zugriffe mit den Anbietern. Bei strittigen Ansprüchen ziehst du einen Anwalt hinzu.
- Plane Änderungen, sobald Sicherung und Veröffentlichung nachvollziehbar funktionieren.
Wechsle Zugangsschlüssel kontrolliert, sofern kein Missbrauchsverdacht besteht. Ein unvorbereiteter Wechsel kann den E-Mail-Versand oder eine Datenübertragung unterbrechen. Bei Verdacht auf unbefugte Zugriffe hat deren Unterbindung Vorrang und sollte fachkundig begleitet werden.
Lass dir vor einer kompletten Neuentwicklung zeigen, warum die bestehende Software nicht weiterbetrieben werden kann. Fehlende Dokumentation allein rechtfertigt noch keinen Neubau.
Bitte deinen Entwickler jetzt um eine gemeinsame Bestandsaufnahme der Konten und Übergabeunterlagen. Vereinbart danach eine Probeübernahme mit einem schriftlichen Ergebnis und klar benannten Lücken.



