Sie beauftragen eine Individualentwicklung. Das Angebot ist gut, der Entwickler kompetent, die Referenzen stimmen. Nach zwölf Wochen läuft das System, alle sind zufrieden. Zwei Jahre später brauchen Sie eine Erweiterung und erreichen niemanden mehr.
Was jetzt passiert, entscheidet sich nicht in diesem Moment. Es hat sich zu Projektbeginn entschieden, in Architekturentscheidungen, die damals niemand als Risikofrage behandelt hat.
Bus-Faktor 1 ist bei Eigenentwicklungen der Normalfall
Der Begriff stammt aus der Projektmanagement-Praxis und beschreibt eine unangenehme Frage: Wie viele Personen müssten ausfallen, damit ein Projekt handlungsunfähig wird? Bei einem Freelancer oder einem kleinen Dienstleister mit einer Eigenentwicklung lautet die Antwort in aller Regel: eine.
Das ist zunächst kein Vorwurf. Kleine Teams entstehen aus guten Gründen, und Individualentwicklung hat handfeste Vorteile gegenüber Standardsoftware. Problematisch wird es erst, wenn dieses Risiko im Beschaffungsprozess nicht auftaucht. In vielen Vergabegesprächen wird der Bus-Faktor schlicht nicht angesprochen, weil die Frage unhöflich klingt und weil auf beiden Seiten die Hoffnung mitschwingt, dass es schon gutgehen wird.
Die Frage ist aber weder unhöflich noch überzogen. Sie ist Teil einer nüchternen Risikobewertung, genauso wie die Frage nach Backups oder nach der Verfügbarkeit des Hostings. Und sie hat den Vorteil, dass ein guter Dienstleister sie beantworten kann, ohne beleidigt zu sein.
Warum "wir übergeben Ihnen den Quellcode" nicht ausreicht
Die häufigste Antwort auf die Nachfolgefrage lautet, dass der Kunde selbstverständlich den Quellcode bekommt. Das klingt beruhigend und ist in der Praxis oft wertlos.
Quellcode ist kein lauffähiges System. Zwischen einem Repository und einer funktionierenden Installation liegen Build-Schritte, Abhängigkeitsauflösung, Konfigurationswerte, Datenbankschemata, Deployment-Prozeduren und eine Reihe von Annahmen, die nirgendwo dokumentiert sind, weil der ursprüngliche Entwickler sie im Kopf hatte. Ein Nachfolger, der ein solches Archiv auspackt, verbringt die ersten Wochen mit Archäologie statt mit Entwicklung.
Dazu kommt ein zweiter Effekt, der selten offen ausgesprochen wird: Übernahmeprojekte sind bei Entwicklern unbeliebt. Wer die Wahl hat zwischen einem sauberen Neuprojekt und einer fremden, undokumentierten Codebasis, entscheidet sich meist gegen die Übernahme oder verlangt einen Aufschlag, der die Fortführung wirtschaftlich unattraktiv macht. Das Ergebnis ist dann faktisch dasselbe wie ein Totalverlust, auch wenn der Quellcode formal vorliegt.
Nachfolgefähigkeit entsteht nicht durch die Zusage, Quellcode herauszugeben, sondern dadurch, dass ein fremder Entwickler diesen Quellcode ohne Rückfragen bauen und deployen kann. Das ist eine Eigenschaft der Architektur, nicht des Vertrags. Was eine Vertretungsregelung im Ausfallfall konkret leisten muss!
Was Nachfolgefähigkeit architektonisch bedeutet
Wenn man die Frage ernst nimmt, ergeben sich daraus konkrete technische Anforderungen. Sie lassen sich in vier Punkten zusammenfassen.
1. Etablierter Stack statt Eigenkonstruktion
Ein System auf Basis eines verbreiteten Frameworks kann grundsätzlich jeder Entwickler übernehmen, der dieses Framework beherrscht. Bei Symfony, Laravel oder vergleichbaren Ökosystemen ist das ein sehr großer Personenkreis. Eine handgeschriebene Eigenkonstruktion ohne Framework-Bezug erfordert dagegen, dass sich ein Nachfolger in eine Architektur einarbeitet, die es genau einmal auf der Welt gibt.
Der Standard-Stack ist an dieser Stelle ein Sicherheitsmerkmal. Was in der Angebotsphase manchmal wie fehlende Individualität wirkt, ist in Wahrheit die Voraussetzung dafür, dass ein Projekt überhaupt übertragbar bleibt.
2. Modulare Struktur statt gewachsener Monolith
Ein Monolith, in dem Kernfunktionen und Fachlogik ineinandergreifen, zwingt jeden Nachfolger dazu, das gesamte System zu verstehen, bevor er eine einzelne Änderung wagen kann. Eine Paket-Architektur mit getrennten Repositories, sauberer Versionierung und definierten Schnittstellen erlaubt es dagegen, sich schrittweise einzuarbeiten und einzelne Bestandteile isoliert zu betrachten.
Entscheidend ist dabei, dass die Grenzen zwischen den Paketen nicht nur konzeptionell gemeint, sondern technisch erzwungen sind. Statische Analyse, die Verstöße gegen die Schichtung als Build-Fehler meldet, verhindert genau die schleichende Vermischung, die aus einer modularen Struktur über die Jahre wieder einen Monolithen macht.
3. Dokumentierte Build- und Deployment-Kette
Die Frage lautet nicht, ob eine Dokumentation existiert, sondern ob sie ausreicht, damit jemand ohne Vorwissen das System zum Laufen bringt. Das ist ein deutlich höherer Anspruch als eine README-Datei mit Installationshinweisen.
Praktisch heißt das: Abhängigkeiten sind versioniert und auflösbar, erforderliche Umgebungsvariablen sind vollständig beschrieben, Migrationen sind reproduzierbar, und der Deployment-Vorgang ist als ausführbares Skript vorhanden, nicht als Handlungsanweisung im Kopf des Entwicklers.
4. Vertraglich geregelte Herausgabe
Die technischen Vorbereitungen nützen wenig, wenn im Ernstfall unklar ist, wer unter welchen Bedingungen Zugriff auf das Archiv bekommt. Eine Escrow-Regelung mit definierten Auslösebedingungen gehört deshalb in den Vertrag, nicht in ein Nebengespräch.
Für größere Projekte gibt es dafür professionelle Treuhänder. Für kleinere Vorhaben ist eine direkte vertragliche Regelung zwischen Auftraggeber und Dienstleister der pragmatische Weg, solange sie schriftlich fixiert und in ihren Auslösebedingungen eindeutig ist.
Der Test, den fast niemand macht
Alle vier Punkte lassen sich erfüllen, ohne dass jemals bewiesen wäre, dass die Übernahme tatsächlich funktioniert. Es gibt genau einen Weg, das herauszufinden: Ein projektfremder Entwickler bekommt das Archiv, die Dokumentation und keinen Ansprechpartner, und versucht, das System zum Laufen zu bringen.
Dieser Trockenlauf ist unangenehm, weil er Lücken sichtbar macht, von deren Existenz man nichts wusste. Genau das ist sein Wert. Alles, was der externe Entwickler nachfragen muss, ist eine Stelle, an der die Dokumentation im Ernstfall versagt hätte.
In der Praxis wird dieser Test selten durchgeführt. Wenn Sie als Auftraggeber eine einzige Frage zur Nachfolgefähigkeit stellen wollen, ist es diese: Hat jemand außerhalb des Projekts jemals versucht, das System aus dem Archiv aufzubauen, und was ist dabei herausgekommen?
Wie ich das für Lotse CMS gelöst habe
Diese Frage kam in den vergangenen Monaten mehrfach von Interessenten, und sie war der Anlass für einen größeren Umbau. Lotse CMS, mein eigenes Symfony-basiertes CMS, lag ursprünglich als zusammenhängender Codeblock vor. Kern und Module waren technisch nicht getrennt, was bedeutete, dass jede Auslieferung physisch den gesamten Funktionsumfang enthielt.
Der Umbau hat das System in eigenständige Composer-Pakete zerlegt, Kern und Module in getrennte Repositories überführt und die Schichtgrenzen über statische Analyse abgesichert. Das zentrale Interface-Paket ist unter MIT-Lizenz öffentlich, sodass die Schnittstellenbeschreibung ohne Zugang zu privaten Repositories einsehbar bleibt. Parallel dazu existiert eine dokumentierte Escrow-Regelung mit beschriebenem Übergabeweg.
Was noch aussteht, ist der externe Trockenlauf. Solange der nicht stattgefunden hat, lautet die korrekte Beschreibung: strukturell vorbereitet und überprüfbar, nicht extern verifiziert. Die Details zum Aufbau habe ich auf einer eigenen Seite zusammengefasst, inklusive der offenen Punkte: Nachfolgesicherheit bei Lotse CMS.
Was Sie daraus für Ihre eigenen Projekte mitnehmen können
Wenn Sie eine Individualentwicklung beauftragen oder betreiben, lohnt sich eine nüchterne Bestandsaufnahme entlang der vier Punkte. Die meisten Projekte erfüllen zwei davon und scheitern an den beiden anderen, meist an der Dokumentationstiefe und an der fehlenden vertraglichen Regelung.
Die gute Nachricht ist, dass sich beides nachträglich herstellen lässt, ohne dass ein Systemumbau nötig wäre. Eine belastbare Build-Dokumentation entsteht in überschaubarer Zeit, wenn man sie einmal ernsthaft angeht, und eine Escrow-Klausel lässt sich auch in bestehende Verträge nachziehen.
Was sich nicht nachträglich herstellen lässt, ist eine übertragbare Architektur. Wer heute vor einer Vergabeentscheidung steht, sollte diese Frage deshalb in der Angebotsphase stellen und nicht in der Krise.
🚀 Lassen Sie uns über Ihr Projekt sprechen
In einem kostenlosen 30-Minuten-Erstgespräch analysiere ich Ihre Anforderungen und gebe konkrete Empfehlungen – unverbindlich und ehrlich.
Termin vereinbaren →Warum unklare Update-Verantwortung auch bei Shopware zum Risiko wird!