Wenn ein Build endet

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

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

Dreißig-Minuten-Call buchen

Kurze Antwort

Eine saubere Übergabe gibt dir 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 du nie warten willst
  • Builds, bei denen du bewusst denselben Anbieter auf Dauer behalten hast
  • 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 deiner Organisation, mit voller Git-Historie.

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

Zugangsdaten

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

Keys und Logins bleiben beim Anbieter.

Infrastruktur

Du hältst 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 du selbst betreibst.

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

Du solltest uns feuern und deine Software am Laufen halten können. Wenn du das nicht kannst, war die Übergabe nicht sauber.

Wir übergeben den Code in deinen 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 dir 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 deines eigenen, die Arbeit ohne uns weiterführen kann. Das ist es, was es tatsächlich bedeutet, deine 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 dich vom ursprünglichen Erbauer abhängig.
Zeitrahmen Bei Lieferung verifiziertFühre die Checkliste durch, bevor du abnimmst, nicht Wochen später.
// 04

Wo das meistens schiefgeht

  • Ein Zip mit Code ohne Git-Historie erhalten, sodass du das Warum hinter jeder Entscheidung verlierst.
  • 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ätige jeden dieser Punkte, bevor du die Übergabe akzeptierst.

  • Quellcode in Repositories, die dir gehören, mit intakter voller Git-Historie.
  • Schriftliche Dokumentation: Architekturüberblick, lokales Setup und Deployment-Schritte.
  • Eine automatisierte Test-Suite, die du ausführen kannst, mit dokumentierten aktuellen Ergebnissen.
  • Eine funktionierende CI/CD-Pipeline, die du selbst auslösen kannst, nicht nur der Anbieter.
  • Alle Secrets und Zugangsdaten an dich ü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

Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 75+ Produkte ausgeliefert.

// 07

Wann das passt, und wann nicht

// 01

Wann Wavect die richtige Wahl ist

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

Wann wir nicht die richtige Wahl sind

  • Du willst einen Anbieter, von dem du nie wegkommen kannst.
  • Du siehst Dokumentation und Tests als optionale Extras.
  • Du baust einen Wegwerf-Prototyp ohne Zukunft.
  • Du übernimmst nicht das Eigentum an deinen eigenen Zugangsdaten und deiner Infrastruktur.

Wenn du deine Software nicht ohne die Leute betreiben kannst, die sie gebaut haben, besitzt du sie noch nicht.

// 08

Passende Leistungen & Lektüre

// 09

Häufige Fragen

Der Code in Repositories, die dir 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 deine Software weiterläuft. Zugangsdaten sollten an dich ü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 du selbst betreiben kannst, ist jede künftige Änderung riskant und langsam. Sie sind das, was ein neues Team sicher arbeiten lässt, nachdem du übernommen hast.
Bevor du den Build abnimmst, nicht Wochen später. Führe 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