GitHub- und Hosting-Zugriff wiederherstellen, wenn ein Freelancer die Konten besitzt

Worum es hier geht, in einfachen Worten

Wenn ein Freelancer Ihren Code und Ihr Hosting unter seiner eigenen E‑Mail eingerichtet hat, kontrollieren Sie nicht wirklich die Systeme, die Ihr Produkt betreiben. Möglicherweise haben Sie die App‑Dateien auf Ihrem Laptop, aber die eigentlichen Kontrollpunkte sind die Accounts: Ihr Repository‑Host (wie GitHub), der Domain‑Registrar, der Hosting‑ oder Cloud‑Provider, E‑Mail und alle Drittanbieter‑Tools.

Das passiert aus normalen Gründen. Ein Auftragnehmer arbeitet schnell, verwendet die E‑Mail, bei der er bereits in seinem Computer angemeldet ist, und erstellt alles als ersten Admin. Wenn niemand anhält, um Sie als Inhaber hinzuzufügen, hängt Ihr Produkt von der Mailbox, dem Passwortmanager und der Zwei‑Faktor‑Authentifizierung (2FA) einer einzelnen Person ab. Meistens ist das nicht böse Absicht – es ist einfach so gelaufen.

Die Risiken sind unmittelbar und praktisch. Ohne Kontrolle über diese Konten können Sie daran gehindert werden, Fixes zu deployen, die Domain zu verlängern, Hosting‑Rechnungen zu bezahlen, geleakte Schlüssel zu rotieren, alten Zugriff zu entfernen oder Support zu bekommen, weil Sie die Eigentümerschaft nicht beweisen können.

Wenn Gründer sagen, sie müssten GitHub‑ und Hosting‑Zugriff wiederherstellen, meinen sie meistens den Wechsel von „Ich kann die App sehen“ zu „Ich kann sie ändern, ausliefern und absichern, ohne irgendjemanden fragen zu müssen.“ Das ist das Ziel.

Einige Teile lassen sich mit den richtigen Schritten meist wiederherstellen. Repositories können oft übertragen werden, wenn der aktuelle Besitzer mitarbeitet, oder exportiert und neu importiert werden, wenn nicht. Hosting lässt sich oft in einem neuen Konto nachbauen, wenn Sie den Code, die Umgebungs‑Einstellungen und eine Möglichkeit haben, die Domain auf den neuen Server zu zeigen.

Andere Dinge dauern länger. Domains sind der große Punkt. Wenn das Registrar‑Konto und die Registrant‑E‑Mail nicht Ihnen gehören, benötigen Sie möglicherweise Support‑Tickets, Nachweise und Zeit. E‑Mail kann ein weiterer Blocker sein: Wenn Ihre „Admin“-E‑Mail eigentlich das Postfach des Freelancers ist, wird das Zurücksetzen schmerzhaft.

Setzen Sie früh Erwartungen: Das ist Teil Verhandlung (eine saubere Übertragung erreichen), Teil Support‑Tickets (nachweisen, dass Sie der Geschäftsinhaber sind) und Teil Aufräumen (Secrets rotieren, Deploys reparieren, riskante Abkürzungen entfernen). Wenn das Projekt schnell mit KI‑Tools erzeugt und dann von Hand überarbeitet wurde, entdecken Sie bei der Übergabe möglicherweise brüchigen Code und exponierte Zugangsdaten.

Erste 60 Minuten: Risiko reduzieren, bevor Sie an die Eigentümerschaft gehen

Ihr Ziel in der ersten Stunde ist, Überraschungen zu stoppen. Bevor Sie um Übertragungen bitten oder Support‑Tickets eröffnen, verringern Sie die Chance, dass etwas verändert, gelöscht oder verrechnet wird, ohne dass Sie es bemerken.

Pausieren Sie Deployments und laufende Arbeiten. Wenn ein Freelancer noch Zugriff hat, kann schon ein „schneller Fix“ Einstellungen überschreiben, Secrets rotieren oder die Audit‑Spur verwischen. Bitten Sie Ihr Team, keine Merges oder Releases mehr durchzuführen, bis Sie wissen, wer was kontrolliert.

Rotieren Sie dann, was Sie jetzt erreichen können. Das ist oft der schnellste Weg, Schaden zu begrenzen, noch bevor die Eigentümerschaft geklärt ist. Priorisieren Sie Konten, die Geld, Kundendaten und Authentifizierung berühren.

Machen Sie die Basics zuerst:

• Ändern Sie Admin‑Passwörter der App und entfernen Sie unbekannte Admin‑Nutzer.
• Rotieren Sie Datenbankpasswörter/Nutzer und widerrufen Sie alte Zugänge, wo möglich.
• Stellen Sie API‑Schlüssel neu aus (Zahlungen, E‑Mail, Karten, Analytics) und deaktivieren Sie alte Keys.
• Aktualisieren Sie erreichbare Environment‑Variablen.
• Schalten Sie 2FA für Konten ein, die Sie bereits kontrollieren.

Danach erfassen Sie den aktuellen Zustand. Das ist keine Zeitverschwendung. Wenn später etwas verändert wird, brauchen Sie Beweise dafür, was existierte und wer dafür zahlte. Machen Sie Screenshots oder Exporte von Dashboards, auf die Sie noch Zugriff haben, vor allem von Rechnungsseiten, Repository‑Berechtigungen, DNS‑Einträgen, Hosting‑Einstellungen und CI/CD‑Konfiguration.

Beginnen Sie sofort ein Incident‑Log. Halten Sie es einfach und konsistent, denn Support‑Teams fragen nach Daten und Belegen.

Schreiben Sie auf:

• Datum und Uhrzeit (mit Zeitzone)
• Wen Sie kontaktiert haben (Freelancer, Agentur, Support)
• Wo Sie sie kontaktiert haben (E‑Mail, Chat)
• Was Sie angefragt haben (Transfer, Admin‑Zugang, Rechnungsänderung)
• Ticketnummern und Ergebnisse

Beispiel: Sie können sich noch bei Stripe und im App‑Dashboard einloggen, aber GitHub und Hosting liegen unter der E‑Mail des Freelancers. In der ersten Stunde pausieren Sie Releases, rotieren Stripe‑Webhook‑Secrets und App‑Admin‑Passwörter, fotografieren DNS‑Records und protokollieren die genaue Nachricht, mit der Sie den Transfer angefordert haben. Das bringt Sie in eine stärkere Position, ohne zu raten, was sich geändert hat.

Inventar erstellen: Konten, Inhaber und Nachweise

Bevor Sie versuchen, etwas zurückzuholen, schreiben Sie auf, was existiert und wer es heute kontrolliert. So übersehen Sie nicht das eine Konto, das Sie später aussperrt (oft der Domain‑Registrar, ein geteiltes E‑Mail‑Postfach oder ein CI‑System).

Listen Sie jeden Dienst auf, der Ihre App berührt. Für viele Startups gehören dazu ein Repo‑Host, Hosting‑Provider, Domain‑Registrar, E‑Mail‑Provider, Datenbank und ein paar "stille" Tools wie Analytics und Error‑Tracking.

Verwenden Sie für jeden Dienst ein einfaches Format:

• Was er kontrolliert (Code, DNS, Server, E‑Mail, Zahlungen)
• Konten‑E‑Mail und Anzeigename
• Wer zahlt und wessen Name auf Rechnungen steht
• 2FA‑Methode und wer sie hält
• Wiederherstellungsoptionen, die Sie kennen (Backup‑Codes, Recovery‑E‑Mail/Telefon)
• Status: voller Zugriff, teilweiser Zugriff oder kein Zugriff

Teilweiser Zugriff ist wichtig. Sie sehen vielleicht ein Repo, können aber Org‑Einstellungen nicht verwalten; oder Sie haben Hosting‑Logs, aber nicht die Abrechnung; oder Sie können DNS bearbeiten, aber die Domain nicht transferieren.

Markieren Sie anschließend, was Sie bereits kontrollieren. Das sind Ihre Anker:

• Ein Firmen‑E‑Mail‑Postfach, in das Sie sich anmelden können
• Die Zahlungsmethode, die belastet wird
• Jeder Admin‑Login, den Sie noch haben (auch wenn es nicht der Top‑Level‑Owner ist)
• Domain‑Zugriff (Domains entscheiden oft alles andere)

Sammeln Sie schließlich die Nachweise, die Support brauchen könnte. Legen Sie sie in einen Ordner, damit Sie später nicht suchen müssen: Rechnungen, Kontoauszüge, Ihren Vertrag oder SOW und Nachrichtenverläufe, in denen Eigentum und Admin‑Zugänge besprochen wurden. Haben Sie Firmen‑Gründungsunterlagen, halten Sie diese ebenfalls bereit.

Wie Sie den Freelancer um eine saubere Übertragung bitten

Behandeln Sie das wie eine Übergabe, nicht wie eine Trennung. Sie wollen eine saubere Übertragung mit möglichst wenig Drama und Risiko. Eine ruhige, konkrete Anfrage bringt meist das schnellste Ergebnis, besonders wenn sich der Freelancer nicht angegriffen fühlt.

Machen Sie das Befolgen einfach. Statt „Gib mir alles“ senden Sie eine kurze Liste von Aktionen in Reihenfolge und mit Zeitfenster. Sagen Sie auch, dass Sie bestätigen werden, sobald Sie sich einloggen und die Einstellungen sehen, damit klar ist, dass der Prozess sauber endet.

Was Sie in welcher Reihenfolge anfragen sollten:

1. Fügen Sie Ihre E‑Mail zuerst als Admin/Owner bei GitHub, dem Hosting‑Provider und dem Domain‑Registrar hinzu.
2. Bestätigen Sie, dass Sie sich einloggen, Abrechnung und Berechtigungen sehen und 2FA/Wiederherstellung verwalten können.
3. Übertragen Sie danach die Eigentümerschaft (Repo/Org, Hosting‑Projekt, Domain) auf Ihre Firmen‑E‑Mail.
4. Teilen Sie Übergabeunterlagen: Repo‑Clone, Datenbank‑Dump, Liste der aktuellen Environment‑Variablen (keine Secrets in Chat einfügen), Deployment‑Schritte und wo Logs/Alerts liegen.
5. Entfernen Sie den Zugriff des Freelancers erst, nachdem Sie bestätigt haben, dass alles funktioniert.

Ein Satz, der die Sache glatt hält: „Bitte fügen Sie mich zuerst als Admin hinzu, damit ich verifizieren kann, dass nichts kaputtgeht; danach übertragen wir die Eigentümerschaft.“

Eine Nachricht, die Sie kopieren können

"Hi [Name], wir brauchen eine saubere Übergabe der Projektkonten, die unter deiner E‑Mail erstellt wurden. Kannst du heute [Ihre E‑Mail] als Admin für GitHub, Hosting und das Domainkonto hinzufügen? Sobald ich den Zugriff überprüft habe, überträgst du bitte die Eigentümerschaft an [Firmen‑E‑Mail]. Teile außerdem ein Backup (Repo‑Clone, letzter DB‑Export) und kurze Deployment‑Hinweise. Frist: [Datum/Uhrzeit]. Wenn du beschäftigt bist, sag mir, wann es passt, ich richte mich ein. Wenn wir das bis dahin nicht abschließen können, werde ich Support‑Tickets bei den Plattformen eröffnen und unseren Vertrag prüfen, damit das Business nicht blockiert wird."

Halten Sie alles schriftlich. Wenn der Freelancer widerspricht, fragen Sie, welcher Teil schwierig ist (Zeit, fehlender Zugriff, Unklarheit darüber, was übergeben werden soll) und passen Sie den Plan an, ohne das Ziel zu ändern.

Schritt für Schritt: GitHub, Hosting, Domain und 2FA übertragen

Das Ziel ist klar: Sie werden überall Inhaber, und alle versteckten Keys für Deploys und Logins werden ersetzt.

Führen Sie Transfers in einer Reihenfolge durch, die Produktionsausfälle vermeidet.

GitHub: Eigentümerschaft verschieben, ohne Deploys zu brechen

Beginnen Sie damit, die GitHub‑Organisation zu kontrollieren, in der der Code liegen sollte. Wenn Sie noch keine Org haben, erstellen Sie eine unter einer firmenverwalteten E‑Mail.

Wesentliche Schritte:

• Lassen Sie den Freelancer Ihr Unternehmens‑GitHub‑Konto als Owner hinzufügen (nicht nur als Collaborator).
• Übertragen Sie jedes Repository in die Org.
• Rotieren Sie sensible Elemente (vor allem GitHub Actions und Repository‑Secrets). Gehen Sie davon aus, dass alles, was der Freelancer sehen konnte, kompromittiert sein könnte.
• Prüfen Sie Deploy‑Keys und OAuth/GitHub‑Apps, die mit dem Repo verbunden sind. Entfernen Sie Unbekanntes und erstellen Sie Schlüssel neu unter Ihrer Kontrolle.
• Prüfen Sie Branch‑Protection‑Regeln, damit ehemalige Mitarbeiter nicht direkt auf main pushen können.

Bevor Sie Secrets rotieren, schreiben Sie auf, wie Deploys heute funktionieren (CI‑Provider, Hosting‑Ziel, Umgebungsnamen). Das verhindert vermeidbare Ausfälle.

Hosting, Domain und 2FA: die Schlüssel zum Königreich übernehmen

Code‑Ownership hilft, aber wer Hosting und DNS kontrolliert, kann immer noch ändern, was Nutzer sehen.

• Hosting/Cloud: Lassen Sie sich zuerst als Top‑Level‑Admin/Owner hinzufügen, bewegen Sie die Abrechnung auf eine Firmenzahlungsmethode und entfernen Sie dann den Freelancer.
• Team/Workspace: Wo die Plattform es erlaubt, verschieben Sie Projekte in ein Firmen‑Team/Org, damit der Zugriff nicht an eine einzelne Person gebunden ist.
• Domain/Registrar: Übertragen Sie die Domain in ein Konto, das Sie kontrollieren, und bestätigen Sie, dass Sie DNS‑Einträge bearbeiten können. Prüfen Sie auch, wer SSL/TLS‑Einstellungen und Verlängerungen kontrolliert.
• Firmen‑E‑Mail: Wechseln Sie Plattform‑Logins weg von der E‑Mail des Freelancers hin zu einem firmenkontrollierten Postfach.
• 2FA: Binden Sie 2FA an Ihre Geräte oder an eine firmenverwaltete Methode. Generieren Sie Backup‑Codes neu und speichern Sie sie sicher.

Sinncheck nach Transfers: Öffnen Sie ein Inkognitofenster und prüfen Sie, ob Ihr Admin‑Konto (1) DNS ändern, (2) Abrechnung ändern und (3) eine Teständerung deployen kann. Wenn davon noch etwas vom Freelancer abhängt, sind Sie noch nicht fertig.

Wenn der Freelancer nicht reagiert: mit dem Support der Plattformen arbeiten

Wenn der Freelancer nicht antwortet, ist Support Ihr nächster Hebel. Ziel ist es, zu beweisen, dass Sie der rechtmäßige Geschäftsinhaber sind und das Asset in ein Konto zu bekommen, das Sie kontrollieren.

Formulieren Sie eine kurze, konsistente Darstellung, die Sie in jedem Ticket wiederverwenden. Bleiben Sie sachlich: was das Projekt ist, welche Konten blockiert sind, wer sie erstellt hat, wann Sie bezahlt haben und welche Änderung Sie wollen.

Was Support üblicherweise von Ihnen benötigt

Die meisten Plattformen fragen nach ähnlichen Nachweisen:

• Zahlungsnachweis (Rechnungen, Quittungen, Kontoauszüge)
• Geschäfts‑Nachweis (Firmenregistrierung, Nachweis, dass Sie das Unternehmen vertreten)
• Domain‑Kontrollnachweis (Fähigkeit, einen DNS‑Record hinzuzufügen, Zugriff auf die Rechnungs‑E‑Mail, Registrar‑Zahlungshistorie)
• Account‑Hinweise (Benutzernamen, Org‑Namen, Repo‑Namen, Domainnamen, ungefähre Erstellungsdaten)
• Sicherheitschecks (Rechnungsadresse, letzte 4 Ziffern der Karte, Support‑PIN falls vorhanden)

Wenn Support mit Folgefragen antwortet, liefern Sie eine klare Nachricht mit bezeichneten Anhängen (z. B. "Anhang A - Rechnung").

Was Sie anfragen sollten (und was zu vermeiden ist)

Bitten Sie um die kleinste Änderung, die Ihnen Kontrolle gibt. Viele Support‑Teams übergeben nicht einfach "ein ganzes Konto" ohne starke Nachweise.

Realistische Anfragen sind zum Beispiel:

• Fügen Sie meine E‑Mail als Owner/Admin zur Org, zum Repo oder Projekt hinzu
• Ändern Sie die Account‑E‑Mail zu einer firmenkontrollierten Adresse
• Helfen Sie, Repos, Projekte oder Abonnements in ein neues Konto zu migrieren, das ich erstelle
• Setzen oder entfernen Sie 2FA nur im Rahmen eines verifizierten Eigentumsprozesses zurück

Vermeiden Sie vage Forderungen wie "Geben Sie mir das Konto". Besser: "Bitte fügen Sie meine E‑Mail als Admin hinzu, damit ich die Eigentümerschaft übertragen und Credentials rotieren kann."

Die Reaktionszeit variiert. Manche Hosts antworten binnen Stunden. Domain‑Registrare und Identitätsteams können Tage und mehrere Nachfragen brauchen. Planen Sie 2–5 Werktage ein, halten Sie ein Ticket pro Plattform und aktualisieren Sie Ihr Incident‑Log.

Häufige Fehler, die die Wiederherstellung erschweren

Die größte Falle ist zu denken: „Die Seite läuft, also ist alles gut.“ Ein Prototyp kann funktionieren und trotzdem unsicher sein. Schnell erstellte Builds enthalten oft exponierte API‑Keys, schwache Login‑Regeln oder Admin‑Routen, die nie gesichert wurden. Wenn Sie die Eigentümerschaft erst nach einem Vorfall herstellen, wird aus dem Zugriffsproblem ein Sicherheitsvorfall.

Ein weiterer Fehler ist, das nur als Passwortproblem zu sehen. Wenn der Freelancer alles unter seiner E‑Mail angelegt hat, bringt Ihnen das richtige Passwort alleine keine echte Kontrolle. Sie brauchen eine Eigentumsübertragung: Admin‑Rolle, Rechnungsinhaber, Registrant‑Kontrolle der Domain und 2FA, die Sie verwalten.

Teams stolpern außerdem über Secrets. Leute ändern das Hosting‑Passwort, vergessen aber Tokens, die an drei anderen Orten liegen. Bevor Sie etwas bewegen, identifizieren Sie, wo Anmeldeinformationen existieren:

• CI/CD‑Einstellungen (Build‑Pipelines, Deploy‑Keys, Service‑Tokens)
• Hosting‑Environment‑Variablen (Produktiv und Preview)
• Das Repository selbst (Konfigurationsdateien, alte Commits, Beispiel‑.env‑Dateien)
• Client‑seitiger Code (alles, was im Browser landet, ist effektiv öffentlich)
• Drittanbieter‑Dashboards (Zahlungen, E‑Mail, Analytics, Error‑Tracking)

Backups werden oft übersprungen, weil alle „einfach übertragen“ wollen. Dann werden DNS‑Einträge überschrieben, eine Datenbank ersetzt oder Repository‑History geht bei einem hastigen Export verloren. Machen Sie zuerst einen sauberen Snapshot: Repo, Datenbank, Storage‑Buckets und aktuelle DNS‑Einstellungen.

Und schließlich: Treffen Sie keine Maßnahmen, die Sperren auslösen, ohne Plan. Zugänge zu widerrufen oder E‑Mails zu ändern, bevor alles bereit ist, kann zu fehlgeschlagenen Deploys oder zu defensivem Verhalten führen. Gehen Sie in kontrollierter Reihenfolge vor: Bestätigen, dass Sie deployen und zurückrollen können, dann Eigentümerschaft übertragen, dann Keys rotieren.

Kurze Checkliste: Sind Sie jetzt sicher?

"Sicher" heißt: Das Business kann weiterlaufen, selbst wenn der Freelancer heute verschwindet.

Beginnen Sie mit dem größten Single Point of Failure: Ihrer Domain. Wenn Sie sich nicht beim Registrar einloggen können, kontrollieren Sie Ihr Produkt nicht wirklich. DNS‑Änderungen können Website und E‑Mail schnell offline nehmen.

Praktische Prüfliste:

• Domain‑Kontrolle: Sie können sich beim Registrar einloggen, DNS bearbeiten und Transfers benötigen Ihre Zustimmung.
• Admin‑Abdeckung: Jede kritische Plattform hat mindestens zwei vertrauenswürdige Admins (keine geteilten Logins).
• Firmen‑Identität: Rechnungs‑E‑Mail, Wiederherstellungs‑E‑Mail und 2FA sind an firmenkontrollierte Postfächer und Geräte gebunden.
• Datensicherheit: Sie haben einen aktuellen Repo‑Clone, einen Datenbank‑Export und eine sichere Kopie erforderlicher Environment‑Werte.
• Deploy‑Sicherheit: Sie können aus Ihrem eigenen Konto neu deployen und wissen genau, wo die Live‑App läuft und wer Zugriff hat.

Wenn ein Punkt mit "nicht sicher" beantwortet ist, behandeln Sie ihn wie "nein".

Ein einfacher Realitäts‑Test: Schreiben Sie die eine Anmeldung auf, deren Verlust das Unternehmen zum Stillstand bringen würde. Für viele Teams ist das der Registrar, der primäre E‑Mail‑Admin und der Code‑Host‑Owner. Beheben Sie diese zuerst.

Beispiel: Eine Gründerin versucht, in 2 Tagen die Kontrolle zurückzubekommen

Maya ist Solo‑Founder. Ein Freelancer baute ihr MVP und startete schnell: ein GitHub‑Repo (Backend und Frontend in einem Repo), eine verwaltete Datenbank beim Hosting‑Provider und eine Domain, die auf ein simples Frontend zeigt. Es läuft, aber der Freelancer hat alles unter seiner eigenen E‑Mail erstellt, und Maya hat nirgendwo Admin‑Rechte.

Stunde 0–2 (stabilisieren): Maya reduziert zuerst das Risiko. Sie macht Screenshots von allem, was sie findet (Rechnungs‑E‑Mails, Belege, alte Zugangsdaten, Domain‑Erinnerungen). Sie ändert Passwörter der Konten, die sie kontrolliert (Firmen‑E‑Mail, Zahlungsportal) und pausiert automatische Zahlungen für Dienste, auf die sie keinen Zugriff hat.

Ende Tag 1 (Beweise sammeln & Transfer anfragen): Maya sammelt Nachweise, dass das Projekt ihr gehört: unterschriebener Vertrag, Zahlungsbelege, die öffentliche Website mit ihrer Marke und Nachrichten des Freelancers über die Einrichtung. Sie schickt eine klare Anfrage: Repo in ihre GitHub‑Org übertragen, sie als Rechnungsinhaber beim Hosting hinzufügen und die Domain in ihr Registrar‑Konto verschieben.

Was sie sofort tun kann vs. was von anderen abhängt:

• Sofort: Beweise sammeln, Firmen‑E‑Mail sichern, Dienste auflisten, neue Inhaberkonten vorbereiten (GitHub‑Org, Hosting, Registrar).
• Benötigt den Auftragnehmer: Transfers einleiten, Maya als Owner/Admin hinzufügen, 2FA‑Recovery‑Codes bereitstellen oder alte Geräte entfernen.
• Benötigt Plattform‑Support: erzwungene Domain‑Wiederherstellung, Repo‑Streitigkeiten oder Identitätsprüfungen, wenn der Freelancer verschwindet.

Tag 2 (Secrets rotieren & sauberen Pfad schaffen): Sobald Maya irgendeinen Zugriff hat, rotiert sie alles, was kopiert worden sein könnte: DB‑Passwörter, API‑Keys, Auth‑Secrets, Deployment‑Tokens. Wenn sie keinen Zugriff bekommt, führt sie einen Fallback aus: neue Konten erstellen, vom Live‑System exportieren/backupen und in Infrastruktur redeployen, die sie besitzt. Danach schreibt sie eine einfache Ownership‑Karte: wer GitHub, Hosting, Domain, Datenbank und 2FA besitzt.

Nächste Schritte: Eigentum sichern und das künftig verhindern

Sobald Sie die Kontrolle zurückerlangt haben, hören Sie nicht bei „es läuft“ auf. Machen Sie es schwer, dass Ihr Produkt wieder hinter einer einzelnen E‑Mail landet.

Erstellen Sie eine firmenträgerische Root‑Identität, die das Wesentliche besitzt. Verwenden Sie ein firmenkontrolliertes Postfach (häufig ein gemeinsames Admin‑Postfach auf Ihrer Domain) als Rechnungs‑ und Wiederherstellungs‑E‑Mail für Registrar, GitHub‑Org und Hosting‑Konten. Halten Sie es langweilig und stabil. Es sollte keinem Freelancer gehören und nicht von der persönlichen Inbox eines Mitarbeiters abhängen.

Setzen Sie einfache Regeln, die zum echten Team‑Betrieb passen:

• Halten Sie mindestens zwei verifizierte Owner/Admins auf jedem kritischen Konto.
• Bewahren Sie Recovery‑Codes und Lizenzschlüssel im Team‑Passwortmanager auf.
• Fordern Sie Auftragnehmer auf, ihre eigenen Accounts als Mitglieder zu nutzen, nie als Owner.
• Verwenden Sie eine kurze Vertrags‑Ende‑Handover‑Checkliste (was gebaut wurde, wo es läuft, wie zu deployen ist, wo Secrets liegen).
• Führen Sie vierteljährliche Zugriffs‑Drills durch: bestätigen Sie, dass Sie sich einloggen und einen Token rotieren können, ohne den ursprünglichen Ersteller.

Wenn Ihre App schnell mit KI‑Tools gebaut oder aus Prototypen zusammengesetzt wurde, planen Sie Zeit fürs Aufräumen ein, bevor Sie sie als Produktion behandeln. Eigentumsreparaturen sind nur die halbe Miete. Unordentlicher Code und hastige Deploys verbergen oft Probleme wie hartkodierte Secrets, kaputte Auth‑Flows oder unsichere Datenbankabfragen.

Ein praktischer Ansatz: Frieren Sie Änderungen für einen Tag ein, verschieben Sie Secrets in richtige Environment‑Variablen oder einen Secret‑Store und schreiben Sie eine Quelle der Wahrheit für Deployments (wo gehostet wird, wie deployed wird, wie "healthy" aussieht). Schon eine Seite Notizen spart später Wochen.

Wenn Sie externe Hilfe wollen: FixMyMess (fixmymess.ai) spezialisiert sich darauf, zerfledderte KI‑Prototypen in produktionsreife Apps zu verwandeln. Ein schneller Audit kann gängige Übergabe‑Fallen aufdecken, wie offene Secrets, fehlerhafte Authentifizierung und Deploy‑Setups, die nur auf der Maschine des ursprünglichen Erstellers funktionieren.

Behandeln Sie Konten‑Eigentum als Teil des Produkts, nicht als Papierkram. Verfolgen Sie Zugriff, Inhaber und Wiederherstellungsschritte genauso wie Bugs und Features, damit in Zukunft keine Einzelperson das Business blockieren kann.