Wenn ein Build endet

Checkliste für die Software-Übergabe: was Sie erhalten sollten, wenn ein Build endet

Eine saubere Übergabe bedeutet, dass Sie die Software betreiben, ändern und an jeden weitergeben können, ohne den ursprünglichen Erbauer anzurufen. Das erfordert den Code und seine vollständige Historie, Dokumentation, Tests, funktionierendes CI/CD, Ihre eigenen Secrets und Zugangsdaten sowie Admin-Zugriff auf jedes Stück Infrastruktur. Wenn auch nur etwas davon beim Anbieter bleibt, besitzen Sie Ihre Software nicht, Sie mieten sie. Nutzen Sie die Checkliste unten, um zu bestätigen, dass Sie tatsächlich alles haben, bevor Sie den Build für erledigt erklären.

Dreißig-Minuten-Call buchen

Kurze Antwort

Eine saubere Übergabe gibt Ihnen den Code, die Historie, Doku, Tests, CI/CD, Secrets und vollen Infrastruktur-Zugriff, sodass jedes kompetente Team ohne den ursprünglichen Erbauer übernehmen kann.

Passt für

  • Gründer, die ein Engagement mit einer Agentur oder einem Freelancer beenden
  • Teams, die ein Projekt intern holen
  • Käufer, die Vendor-Lock-in vermeiden wollen
  • Alle, die sich auf Due Diligence oder ein Audit vorbereiten
  • Produkte, die ihr erstes Build-Team überdauern müssen

Passt nicht für

  • Wegwerf-Prototypen, die Sie nie warten wollen
  • Builds, bei denen Sie bewusst denselben Anbieter auf Dauer behalten haben
  • Interne Skripte ohne Produktions-Footprint
  • Arbeit, die noch keinen lieferbaren Zustand erreicht hat
// 01

Die Optionen im Vergleich

Wie man eine saubere Übergabe von einer Lock-in-Falle unterscheidet.

Dimension Saubere Übergabe Warnsignale für Vendor-Lock-in
Code-Eigentum

Repos in Ihrer Organisation, mit voller Git-Historie.

Code liegt im Konto des Anbieters, oder ein Zip ohne Historie.

Zugangsdaten

Alle Secrets und Konten gehören Ihnen und sind rotiert.

Keys und Logins bleiben beim Anbieter.

Infrastruktur

Sie halten Admin über Hosting, DNS und Observability.

Der Anbieter ist der einzige Admin in der Produktion.

Dokumentation

Architektur, Setup und Runbooks sind aufgeschrieben.

Wissen steckt im Kopf des ursprünglichen Entwicklers.

Tests und CI/CD

Automatisierte Tests und eine Pipeline, die Sie selbst betreiben.

Keine Tests, oder Deploys, die nur der Anbieter auslösen kann.

Lock-in

Jedes kompetente Team kann übernehmen.

Nur der ursprüngliche Erbauer kann etwas ändern.

// 02

Wo Wavect hier steht

Sie sollten uns feuern und Ihre Software am Laufen halten können. Wenn Sie das nicht können, war die Übergabe nicht sauber.

Wir übergeben den Code in Ihren eigenen Repositories mit voller Historie, die Dokumentation und Runbooks, um ihn zu betreiben, die Tests und die Pipeline, um ihn auszuliefern, und Admin-Zugriff auf jedes Konto und jeden Server, auf dem er läuft. Die Secrets gehören Ihnen und sind rotiert, nicht uns.

Kein Vendor-Lock-in ist Standard, kein Premium-Add-on. Das Ziel einer Übergabe ist, dass jedes kompetente Team, einschließlich Ihres eigenen, die Arbeit ohne uns weiterführen kann. Das ist es, was es tatsächlich bedeutet, Ihre Software zu besitzen.

// 03

Kosten, Risiko und Zeitrahmen

Kosten Teil des BuildsEine saubere Übergabe ist inkludiert, kein Upsell am Ende.
Risiko Lock-in, wenn übersprungenEin fehlender Punkt lässt Sie vom ursprünglichen Erbauer abhängig.
Zeitrahmen Bei Lieferung verifiziertFühren Sie die Checkliste durch, bevor Sie abnehmen, nicht Wochen später.
// 04

Wo das meistens schiefgeht

  • Ein Zip mit Code ohne Git-Historie erhalten, sodass Sie das Warum hinter jeder Entscheidung verlieren.
  • Entdecken, dass Produktions-Secrets und Konten noch dem Anbieter gehören.
  • Feststellen, dass der Anbieter der einzige Admin über Hosting, DNS oder die Datenbank ist.
  • Eine Codebasis ohne Tests und ohne lauffähige Pipeline erben.
  • Sich auf Wissen verlassen, das nur im Kopf des ursprünglichen Entwicklers steckt.
  • Den Build für erledigt erklären, bevor jemand die Übergabepunkte verifiziert hat.
// 05

Die Checkliste

Bestätigen Sie jeden dieser Punkte, bevor Sie die Übergabe akzeptieren.

  • Quellcode in Repositories, die Ihnen gehören, mit intakter voller Git-Historie.
  • Schriftliche Dokumentation: Architekturüberblick, lokales Setup und Deployment-Schritte.
  • Eine automatisierte Test-Suite, die Sie ausführen können, mit dokumentierten aktuellen Ergebnissen.
  • Eine funktionierende CI/CD-Pipeline, die Sie selbst auslösen können, nicht nur der Anbieter.
  • Alle Secrets und Zugangsdaten an Sie übertragen und weg von den Konten des Anbieters rotiert.
  • Admin-Zugriff auf jedes Stück Infrastruktur: Hosting, DNS, Datenbank und Observability.
  • Runbooks für gängige Operationen: Deploy, Rollback, Restore und Reaktion auf Incidents.
  • Bestätigung, dass kein Vendor-Lock-in besteht, sodass jedes kompetente Team ohne den ursprünglichen Erbauer übernehmen kann.
// 06

Wie das in unserer Arbeit aussieht

Builds, die in die Produktion ausgeliefert und vom Kunden besessen werden.

LivLive

Live
+1.000 Gleichzeitige Nutzer

AR-RWA-Plattform: 2 Mio. $+ über das Produkt eingenommen, 1.000+ gleichzeitige Nutzer, sechs Wochen flat.

Solidity Typescript React
BLOCKCHAIN 2025

PromptID

Live
6 Wochen Von 0 zu Produktion

AI-native Assessment-Plattform, von 0 auf Produktion in 6 Wochen unter komprimiertem Marktdruck.

NestJS NextJS LangChain
AI 2026
// 07

Wann das passt, und wann nicht

// 01

Wann Wavect die richtige Wahl ist

  • Sie wollen Ihre Software vollständig besitzen, nicht von einem Anbieter mieten.
  • Sie holen das Projekt vielleicht später intern oder zu einem anderen Team.
  • Sie erwarten Dokumentation, Tests und Zugriff als Standard.
  • Sie wollen einen Erbauer, der die Übergabe von Tag eins an plant.
// 02

Wann wir nicht die richtige Wahl sind

  • Sie wollen einen Anbieter, von dem Sie nie wegkommen können.
  • Sie sehen Dokumentation und Tests als optionale Extras.
  • Sie bauen einen Wegwerf-Prototyp ohne Zukunft.
  • Sie übernehmen nicht das Eigentum an Ihren eigenen Zugangsdaten und Ihrer Infrastruktur.

Wenn Sie Ihre Software nicht ohne die Leute betreiben können, die sie gebaut haben, besitzen Sie sie noch nicht.

// 08

Passende Leistungen & Lektüre

// 09

Häufige Fragen

Der Code in Repositories, die Ihnen gehören, mit der vollen Git-Historie. Die Historie trägt die Begründung hinter jeder Änderung, und eine Zip-Datei ohne sie wirft das weg. Alles andere baut darauf auf.
Wenn Produktions-Secrets und Konten beim Anbieter bleiben, kontrolliert er, ob Ihre Software weiterläuft. Zugangsdaten sollten an Sie übertragen und rotiert werden, sodass nichts von den Logins des ursprünglichen Erbauers abhängt.
Alles, was bedeutet, dass nur der ursprüngliche Erbauer die Software ändern, deployen oder betreiben kann. Code in seinem Konto, undokumentierte Systeme oder Admin-Zugriff, den er nicht übergeben will, sind alles Lock-in.
Ja. Ohne eine automatisierte Test-Suite und eine Pipeline, die Sie selbst betreiben können, ist jede künftige Änderung riskant und langsam. Sie sind das, was ein neues Team sicher arbeiten lässt, nachdem Sie übernommen haben.
Bevor Sie den Build abnehmen, nicht Wochen später. Führen Sie die Checkliste durch, solange das ursprüngliche Team noch engagiert ist, damit jede Lücke sofort geschlossen werden kann.
Nein. Kein Vendor-Lock-in ist Standard. Die Übergabepunkte sind Teil des Builds, kein Upsell am Ende.
Zuletzt geprüft: vonKevin Riedl wiki ↗
Dreißig-Minuten-Call buchen