Projekt hängt. Agentur weg. Keiner will den Code anfassen.

Ich übernehme euer Setup, stabilisiere den Betrieb – und bringe euch zurück in einen sauberen Release‑Rhythmus.

Du musst nicht „alles neu“ machen. Du brauchst Klarheit, eine sichere Übergabe und jemanden, der das Ding hands-on wieder lieferfähig macht: Code, Infrastruktur, Deployments, Datenflüsse – pragmatisch, ohne PowerPoint.

Was du nach der Übernahme spürst

  • Transparenz in 48–72 Stunden
    Ist‑Stand, Risiken, Abhängigkeiten: Du weißt, was läuft, was brennt – und was als Nächstes passiert.
  • Hands-on statt Delegation
    Ich übernehme selbst: Repos, Hosting, CI/CD, Zugänge, Dokumentation – ohne Ticket-Pingpong.
  • Risiko runter, Betrieb stabil
    Backups, Monitoring, saubere Deployments und Quick Fixes, damit Ausfälle und „Angst vor Updates“ aufhören.
  • Wieder lieferfähige Iterationen
    Ein realistischer Plan in kleinen Schritten: priorisiert, testbar, releasbar – damit wieder Fortschritt sichtbar wird.
Übernahme-Check anfragen

Kurz schildern, wo’s klemmt – du bekommst eine klare Einschätzung und die nächsten Schritte.

Projekt hängt? Agentur weg? Zugänge fehlen?

Du willst einfach wieder sauber liefern können.

Release geplant, aber irgendwas ist immer: Build bricht, Deployment hängt, und am Ende wird’s doch wieder ein „nur noch schnell“-Fix direkt auf live.
Bugs häufen sich, Tickets drehen im Kreis — und niemand kann dir gerade klar sagen, was eigentlich wo läuft, was kritisch ist und was nur laut wirkt.
Doku? Veraltet. Wissen? In Köpfen, die nicht mehr da sind. Und du merkst: Ohne Überblick traust du dich kaum noch, etwas anzufassen.
Dann kommen die Klassiker: fehlende Zugänge, abgelaufene Tokens, seltsame Automationen, die „schon immer so“ liefen — bis sie es plötzlich nicht mehr tun.
Das frisst Zeit, Nerven und Vertrauen im Team. Aber es heißt nicht, dass das Projekt verloren ist — nur, dass ihr gerade einen klaren Schnitt und Ordnung braucht.

Woran du merkst, dass es nicht nur ein Bug ist

Ein Bug kann passieren. Aber manchmal ist der Bug nur das Symptom – und darunter knirscht das System. Wenn du bei mehreren Punkten nickst, lohnt sich ein genauer Blick.

  • Niemand kann dir sicher sagen, was gerade live ist.
    „Müsste eigentlich…“ ersetzt echte Versionen, Deploy-Infos und einen klaren Release-Stand.
  • Releases fühlen sich jedes Mal wie ein Risiko an.
    Kleine Änderungen dauern ewig, weil du vorher nicht weißt, was dabei umkippt – und danach nicht, ob es wirklich stabil ist.
  • Zugänge, Rechte und Wissen hängen an einzelnen Personen.
    Repo, Hosting, DNS, CI, Monitoring, Accounts: Ein Teil fehlt, ein Teil ist „bei der Agentur“, ein Teil ist irgendwo im Postfach.
  • Es gibt keine saubere Deploy-Pipeline (oder sie wird umgangen).
    Hotfix per Hand, FTP-Uploads, „kurz auf dem Server ändern“ – und plötzlich ist der Code-Stand nicht mehr reproduzierbar.
  • Monitoring/Logs sind zu dünn, um schnell zu handeln.
    Du merkst Probleme erst, wenn Kunden sich melden. Und dann beginnt die Suche im Dunkeln: Was ist passiert? Wann? Warum?
  • Die Architektur ist „gewachsen“ – aber nicht mehr erklärbar.
    Abhängigkeiten, Integrationen und Workarounds sind da, aber niemand kann sie sauber skizzieren. Jede Änderung zieht Nebenwirkungen nach sich.
  • „Fertig“ ist nicht definiert.
    Keine klare Definition of Done, keine Tests/Checks, keine Abnahme-Kriterien – dafür endlose Schleifen aus „geht bei mir“ und „bei uns nicht“.

Wenn das dein Alltag ist: Du brauchst nicht sofort ein komplettes Rebuild. Oft macht eine strukturierte Übernahme Sinn – erst Stabilität und Klarheit, dann wieder verlässlich in Iterationen liefern.

Übernahme-Plan

Was ich bei einer Übernahme zuerst geradeziehe

Damit du wieder sicher deployen kannst, ohne Bauchschmerzen. Erst Klarheit schaffen, dann stabilisieren – und erst dann schneller werden.

2
R
Risiko
Code- & Architektur-Check
Wo brennt’s wirklich?
Ich finde die Stellen, die Releases ausbremsen oder Ausfälle provozieren: Abhängigkeiten, Quick-Fixes, fehlende Tests, „magische“ Konfiguration. Ergebnis ist eine klare Risikoliste mit den nächsten sinnvollen Eingriffen – ohne Komplett-Neubau.
3
D
Deploy
Betrieb & Deployments stabilisieren
Reproduzierbar statt „hoffentlich klappt’s“
Ich bringe Ordnung in Build/Deploy, Umgebungen und Secrets – inklusive sauberem Rollback. Du bekommst wieder einen Release-Prozess, den man verantworten kann (auch wenn’s mal schnell gehen muss).
4
M
Monitoring
Fehler früh sehen
Bevor Kunden es merken
Logs, Metriken und Alerts so, dass sie wirklich helfen: klare Signale statt Alarm-Müdigkeit. Du weißt schneller, was kaputt ist, wie groß der Impact ist – und was als Erstes zu tun ist.
6
D
Daten
Schnittstellen entknoten
Wo Daten verloren gehen
Ich prüfe Datenflüsse und Integrationen (CRM/ERP/Automationen) auf Bruchstellen und doppelte Wahrheiten. Ergebnis: weniger manuelle Nacharbeit – und wieder Vertrauen in Zahlen und Prozesse.

Woran du merkst, dass es nicht nur ein Bug ist

Manchmal ist es nicht „ein Ticket zu viel“, sondern ein System, das niemand mehr wirklich im Griff hat. Wenn du dich in den Punkten hier wiedererkennst: Das ist nicht peinlich — das ist reparierbar. Und genau dafür lohnt sich eine saubere Übernahme, ohne alles neu zu bauen.

Symptom 01
Niemand kann dir sicher sagen, was gerade live ist
„Ist das schon deployed?“ wird zur Tagesfrage. Es gibt mehrere Umgebungen, Hotfixes per Hand und am Ende entscheidet Bauchgefühl statt Versionen, Tags und Releases. Das macht jede Änderung riskant — selbst die kleinen.
Wenn Releases nicht reproduzierbar sind, wird jeder Bug zur Lotterie.
Symptom 02
Zugänge fehlen, Ownership ist unklar
Repo, Hosting, Domain, CI, Monitoring, SaaS-Accounts: irgendwas liegt bei der alten Agentur, bei Ex-Mitarbeitern oder in einem privaten Login. Du kannst nicht sauber warten, nicht sicher deployen und im Ernstfall nicht schnell reagieren.
Ohne klare Ownership gibt’s keine Kontrolle — nur Abhängigkeiten.
Symptom 03
Fehler tauchen erst auf, wenn Kunden sich melden
Kein verlässliches Monitoring, keine Alerts, Logs sind schwer auffindbar oder unbrauchbar. Statt „wir sehen das früh“ gibt’s Feuerwehrmodus — und du bezahlst mit Vertrauen, Zeit und Nerven.
Wenn du blind fliegst, ist Stabilität nur Zufall.
Symptom 04
„Nur schnell fixen“ ist zur Standard-Strategie geworden
Tickets werden „irgendwie“ geschlossen, aber nichts fühlt sich wirklich fertig an. Es gibt keine klare Definition of Done, keine verlässlichen Tests, keine sauberen PRs — dafür wachsende technische Schulden und immer längere Durchlaufzeiten.
Wenn alles dringend ist, wird nichts mehr lieferfähig.

Pragmatisch, ohne Drama

Der Ablauf: von Chaos zu lieferfähig

Kickoff & Kontext klären
Phase 1

Wir sammeln Ziele, Stakeholder und die echten Schmerzen im Alltag: Was blockiert Releases, wo brennt’s operativ, was darf auf keinen Fall ausfallen. Ergebnis: ein gemeinsames Bild, wer was braucht — und was „wieder lieferfähig“ konkret heißt.

Timeboxed Audit (48–72h Fokus)
Phase 2

Ich verschaffe mir Zugriff auf Repo/Hosting/Domains/Accounts und gehe Code, Architektur, Deployments und Datenflüsse durch. Ergebnis: Top‑Risiken + Quick Wins + eine klare Reihenfolge nach Nutzen/Risiko/Aufwand (statt Bauchgefühl).

Stabilisieren, bevor wir „verbessern“
Phase 3

Wir stoppen das Chaos: reproduzierbare Builds, saubere Deployments mit Rollback, Backups, Monitoring/Logs und die schlimmsten Bugs/Performance‑Bremsen. Ergebnis: weniger Feuerwehreinsätze — und wieder Vertrauen in den Betrieb.

Liefer‑Takt etablieren (kleine Iterationen)
Phase 4

Wir schneiden Arbeit in lieferbare Pakete, definieren „Done“ (Tests/Review/Deploy) und bringen einen verlässlichen Rhythmus rein. Ergebnis: jede Woche sichtbarer Fortschritt — statt monatelangem „fast fertig“.

Übergabe & Partner‑Modus
Phase 5

Dokumentation, Roadmap, Verantwortlichkeiten und ein Setup, das nicht an einer Person hängt. Ergebnis: du kannst intern übernehmen, weiter mit mir iterieren — oder später wieder sauber an ein Team/Agency übergeben.

Typische Rettungs‑Szenarien (und was dann passiert)

Du bist nicht der Erste, bei dem ein Projekt plötzlich „ohne Fahrer“ ist. Entscheidend ist nur: kurz Ordnung reinbringen, Risiken runterfahren und dann wieder in kleine, sichere Releases kommen.

Szenario A
Agentur ist weg – niemand kann deployen
Du hast ein laufendes System – aber die Leute, die „den Knopf drücken“, sind nicht mehr erreichbar. Zugänge fehlen, das Repo ist unklar, die Domain hängt irgendwo, und jede Änderung fühlt sich an wie russisches Roulette.

Bei einer Übernahme räume ich zuerst die Ownership auf: Repos, Hosting, Accounts, Secrets, Rechte. Dann setze ich einen reproduzierbaren Deploy‑Weg auf (inkl. Rollback), damit ihr wieder ohne Bauchschmerzen live gehen könnt. Ergebnis: ihr gewinnt Kontrolle zurück – und Releases werden wieder normal statt Drama.
Nächster sinnvoller Schritt: Zugänge & Deploy‑Pfad in einer kurzen Audit‑Timebox klären.
Szenario B
Projekt steckt fest – jede Änderung macht’s schlimmer
Eigentlich sollte „nur noch schnell“ ein Feature rein. Stattdessen: neue Bugs, kaputte Tests (falls es welche gibt), Performance-Probleme – und niemand traut sich mehr, etwas anzufassen. Das Team arbeitet, aber es fühlt sich nicht nach Fortschritt an.

Ich stabilisiere zuerst die Basis: Fehlerquellen sichtbar machen (Logs/Monitoring), kritische Stellen absichern, und einen klaren „Definition of Done“-Pfad etablieren. Danach schneiden wir das Projekt in kleine, lieferfähige Iterationen, damit wieder regelmäßig etwas fertig wird – und nicht nur „fast fertig“.
Nächster sinnvoller Schritt: Risiko‑Hotspots identifizieren + 3 Quick Wins sauber shippen.
Szenario C
Tool-/Integrations‑Spaghetti – Daten stimmen nie
CRM sagt A, ERP sagt B, irgendwo läuft noch ein Google Sheet als „Wahrheit“, und Automationen feuern doppelt oder gar nicht. Im Alltag heißt das: Rückfragen, manuelle Korrekturen, Misstrauen in Zahlen – und Entscheidungen werden zur Bauchfrage.

Bei der Rettung geht’s selten um „noch ein Tool“, sondern um klare Datenflüsse: Welche Quelle ist führend? Wo entstehen Dubletten? Welche Schnittstellen brechen still? Ich konsolidiere die wichtigsten Datenpfade, baue Checks ein und mache die Integrationen wieder nachvollziehbar. Ergebnis: weniger Nacharbeit, mehr Verlässlichkeit im Tagesgeschäft.
Nächster sinnvoller Schritt: Single Source of Truth definieren + 1–2 kritische Flows stabilisieren.
Szenario D
KI‑Druck – aber keine Datenbasis
„Wir müssen was mit KI machen“ steht im Raum – aber die Daten liegen verteilt, sind nicht sauber gepflegt oder niemand weiß, was überhaupt verfügbar ist. Dann wird aus dem KI‑Projekt schnell ein teures Experiment ohne Wirkung.

Ich drehe das pragmatisch: erst Datenlage und Prozesse verstehen, dann einen konkreten Use Case wählen, der wirklich Zeit spart oder Qualität hebt. Oft ist der größte Hebel: Datenmodell und Schnittstellen so zu ordnen, dass KI überhaupt sinnvoll arbeiten kann. Ergebnis: ein belastbarer Startpunkt statt KI‑Theater – und ein Plan, der zum Betrieb passt.
Nächster sinnvoller Schritt: Daten‑Reality‑Check + Use‑Case‑Scoring (Nutzen/Risiko/Aufwand).

Nach der Übernahme

So sieht „wieder im Griff“ aus

Keine Magie, kein Rebuild um jeden Preis. Du siehst klare Zuständigkeiten, nachvollziehbare Entscheidungen und einen Betrieb, der nicht bei jedem Deploy schwitzt.

O
Ownership
Zugänge sind geklärt
Nicht mehr „wer hat das Passwort?“
Repos, Hosting, Domains und Accounts sind sauber zugeordnet. Damit bist du wieder handlungsfähig — auch wenn jemand ausfällt oder wechselt.
S
Ergebnis
Weniger Stress im Alltag
Du bekommst wieder Kontrolle zurück.
Wenn Status, Ownership und Betrieb stehen, entsteht wieder Ruhe: Entscheidungen werden einfacher, Prioritäten klarer — und ihr könnt euch auf das konzentrieren, was Umsatz und Kunden wirklich bewegt.

Lass uns dein Projekt wieder lieferfähig machen.

Wenn gerade niemand so richtig „Owner“ ist, Releases Angst machen und du nicht mal sicher bist, was live ist: Das ist kein persönliches Versagen — das ist ein Setup-Problem. Im Übernahme‑Check (30–45 Min) schauen wir gemeinsam drauf. Du bringst Links/Zugänge/Fragen mit, ich gebe dir eine klare Einschätzung: wo die größten Risiken liegen und was die ersten 3 sinnvollen Schritte wären — auch wenn wir danach nicht zusammenarbeiten.

Du bekommst: klare Next Steps statt Bauchgefühl • Fokus auf Risiko runter & Stabilität hoch • pragmatisch, ohne Tool‑Show