Übergabe ohne Lock-in: Damit ein anderes Team weitermachen kann
Gute Software endet nicht beim Go-live. Eine Codebase, die ein anderes Team in zwei Wochen übernehmen kann, ist ein Vertrauenssignal - und meist auch besseres Engineering.
"Was passiert, wenn ihr nicht mehr da seid?" Diese Frage gehört zu den ehrlichsten, die ein Auftraggeber stellen kann - und die Antwort sollte nicht "wir bleiben halt da" lauten. Eine Codebase, die ein anderes Team übernehmen kann, ist von Beginn an die robustere Codebase.
Was Lock-in im Kleinen aussieht
Lock-in ist selten ein einzelner Vertrag, der einen für zehn Jahre bindet. Lock-in im Alltag besteht aus vielen kleinen Dingen, die alle gemeinsam dazu führen, dass ein Wechsel teuer wird:
- Undokumentierte Konfiguration. Ein env-File mit 40 Variablen, von denen nur die Hälfte irgendwo erklärt ist.
- Halbautomatisierte Deployments. Ein Skript, das nur auf einem Laptop funktioniert, weil dort vor zwei Jahren ein Tool installiert wurde.
- Implizite Konventionen. "Wir nennen Branches immer so" - aber in keinem README steht, warum.
- Tools im Eigenbau für Standardprobleme. Ein eigener Logger, ein eigener HTTP-Client, eine eigene CSV-Bibliothek.
Jedes einzelne Element ist klein. In Summe machen sie Übergabe zu einem Wochen-Projekt.
Vier Bausteine einer übergabefähigen Codebase
Vier Dinge bringen den größten Effekt - und sind realistisch in jedem Projekt umsetzbar.
- Onboarding-Skript, das wirklich läuft.
./scripts/setup.shvon einem leeren Laptop - und nach zehn Minuten ist die Anwendung lokal lauffähig. Wenn das Skript nicht durchläuft, ist es Bug, nicht Komfort. - Architecture Decision Records. Eine Datei pro relevanter Entscheidung mit Kontext, betrachteten Alternativen, Begründung. Kein langes Wiki - 200 Zeilen pro ADR reichen. Sie beantworten die Fragen, die ein neues Team in den ersten Wochen stellt.
- Standardstack vor Eigenbau. Vor jeder selbst gebauten Lösung die Frage: gibt es einen verbreiteten OSS-Baustein, der reicht? Eigenbau ist oft technisch eleganter und übergabe-feindlich.
- Lesbare CI-Pipeline. Wenn die Pipeline aus drei klaren Phasen besteht (Build, Test, Deploy), kann ein neues Team sie nach dem ersten Lesen ändern. Wenn sie aus 14 Forgejo-Workflows mit Cross-Reference besteht, nicht.
Warum das kein Schmuck-Add-on ist
Diese Bausteine sind nicht "Doku-Pflege". Sie sind Engineering-Disziplin, die direkt in die laufende Arbeit zurückzahlt:
- Onboarding-Skripte verhindern, dass das aktuelle Team selbst stolpert - jeder neue Laptop, jeder Container-Rebuild profitiert.
- ADRs verhindern Diskussionen, die alle drei Monate von vorn beginnen - "warum benutzen wir nochmal X?".
- Standardstack reduziert die Menge an Code, die das Team selbst pflegen muss - jede Zeile Eigenbau ist Wartungslast.
- Lesbare Pipelines verkürzen Fehleranalyse-Zeit - kaputte Builds sind kein Mysterium.
Mit anderen Worten: das Investment lohnt sich, selbst wenn die Übergabe nie passiert.
Die zwei Wochen-Praxisprüfung
Eine ehrliche Prüfung dauert zwei Wochen und sieht so aus: eine Person, die das Projekt nicht kennt, bekommt das Repository, die README und sonst nichts. Sie soll ein nicht-triviales Feature umsetzen. Die Stellen, an denen sie nachfragen muss, sind die Lücken im Onboarding-Material.
Wir haben das selbst regelmäßig gemacht - und jedes Mal zwei oder drei nicht-offensichtliche Lücken gefunden. Genau das ist der Punkt: ohne Test gibt es keine Garantie, mit Test gibt es eine Liste.
Das Vertrauenssignal nach außen
Auftraggeber, die einmal in einem Lock-in gesteckt haben, riechen das Gegenteil schnell. "Wir liefern eine Übergabe-Dokumentation, die ein anderes Team in zwei Wochen nutzbar macht" ist ein konkretes Versprechen, das man entweder einhält oder nicht. Es ist ein deutlich glaubwürdigeres Vertrauenssignal als jede Zertifizierung.