Übergabe ohne Lock-in: Damit ein anderes Team weitermachen kann

"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.

1. Onboarding-Skript, das wirklich läuft. ./scripts/setup.sh von einem leeren Laptop - und nach zehn Minuten ist die Anwendung lokal lauffähig. Wenn das Skript nicht durchläuft, ist es Bug, nicht Komfort.
2. 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.
3. 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.
4. 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.