Your Developer Disappeared: The First 72 Hours

If the developer or agency behind a live product stops responding, the first 72 hours are for containment, evidence and authorized control—not for rewriting the application or changing every password. Preserve the running system, map who controls each account, start official recovery processes, and separate what is verified from what is merely assumed.

The three-day window is a planning frame, not a promise that every provider will transfer an account in three days. Some recovery paths are self-service. Others require the current account holder, provider support, business documentation or legal help. Your goal by hour 72 is to have the critical risks contained, the right cases in motion and a written decision about what is safe to do next.

Our 30-day software takeover checklist covers a cooperative transition and the later proof that a new team can restore, release and operate the system. This runbook starts earlier: when there is no reliable handover yet.

First principle: build a recovery graph, not a password list

The domain registrar and company identity provider are high-leverage control points, but they are not universal master keys. A source-control account may depend on recovery codes that no provider will override. A cloud organization may use a personal root email and phone. An App Store account may require action by its current Account Holder. A payment account may have separate ownership, representative and payout controls.

Treat the stack as a graph:

business authority → registered accounts → recovery identities → human and machine access → production dependencies

For every critical account, record:

• the exact organization, tenant, account or project—not just the provider name;
• the legal or contractual owner;
• current human administrators;
• billing owner and payment method;
• recovery email, phone, MFA method and recovery-code owner;
• machine identities, API keys, deploy keys, apps and webhooks;
• the production functions that will fail if the account changes;
• evidence state: requested, received, verified, rehearsed or accepted.

Recovery is a dependency problem. No single password proves that the company controls the product.

This distinction prevents two common mistakes: assuming that access equals ownership, and assuming that a successful password reset proves the account can safely be changed.

Before hour 0: name the authority and the incident

Before anyone touches an account, name one business decision owner and one technical recovery lead. Write down who is authorized to:

• contact providers and submit company documents;
• change DNS, billing, account roles or recovery identities;
• preserve source and configuration;
• access production data;
• pause a release or scheduled process;
• rotate or revoke credentials;
• approve a restore, rollback or customer communication.

If there is an active breach, fraud, destructive activity or customer-safety incident, use the relevant incident-response and legal process immediately. A generic 72-hour sequence must not delay containment of an active threat.

Keep evidence in an approved, access-controlled location. Capture account names, IDs, settings, timestamps and recovery status. Do not paste passwords, MFA seeds, private keys, full payment data or raw customer exports into the recovery sheet.

Hours 0–4: preserve the live system

The first expensive mistake is usually a well-intentioned production change made before anyone understands the release path.

Put discretionary change under control

Do not blindly disable every pipeline: a workflow may also renew infrastructure, publish a required configuration or run business-critical scheduled work. Instead:

1. identify every path that can change production;
2. establish who can stop or approve each path;
3. require explicit approval for discretionary releases;
4. preserve logs and current configuration;
5. pause a path only when its consequences and restart procedure are understood.

Record pushes, tags, manual workflows, GitOps reconciliation, provider auto-deploys, database migrations, cron jobs and release bots. A branch merge in one repository may deploy another repository or run a migration.

Preserve before cancelling

Do not cancel a cloud account, domain, subscription, phone number, old mailbox or payment method merely because it belongs to the outgoing developer. First establish a client-controlled replacement, test it and understand the retention or deletion consequences.

There are exceptions: an active compromise or fraudulent payout may require immediate provider action. Make that an explicit incident decision with the appropriate business, security and legal owner—not an improvised cleanup step.

Capture a non-secret baseline

Record what is currently live:

• domains, subdomains, nameservers, DNSSEC state and certificate issuers;
• public application, admin surfaces, APIs and mobile apps;
• cloud account, regions, projects and running workloads;
• source organizations and repository names;
• deployment revision or artifact identifiers;
• database providers and backup locations;
• payment, email, identity and storage integrations;
• monitoring, error tracking and alert destinations;
• upcoming renewals, certificate expiries and provider deadlines.

Take screenshots or exports only where you are authorized to do so. Prefer provider-generated account and configuration exports over screenshots when they are available. Preserve timestamps and source URLs so another person can verify the evidence later.

The 14-class ownership map

Use the table below to decide what to verify and what not to assume. The order is risk-based, but it is not universal: an active payment or security incident may move a later row to the top.

Download the Ownership Recovery Sheet and replace every blank with a fact, an evidence link or NOT VERIFIED.

Hours 4–24: domain and identity

Domain registration and company identity often unlock other recovery routes, so start them early. Do not assume they will finish first.

Find the registrar with ICANN Lookup

Use the ICANN Registration Data Lookup Tool, which now uses RDAP as the primary source for generic top-level domain registration data. It can identify the sponsoring registrar even when public contact data is redacted.

Then distinguish three different controls:

1. registration: who the registrar recognizes as the registered name holder;
2. DNS: who controls the authoritative nameservers and zone;
3. web hosting: where the site or application runs.

Changing one does not automatically change the others.

Open a recovery case with the registrar and ask what evidence it requires. Company registration documents, historical invoices, renewal records and existing account identifiers may be relevant, but the registrar decides its process. Do not promise that a card statement or matching company name will be sufficient.

Sequence a registrant change and registrar transfer

Under the current ICANN Transfer Policy, a material change to registrant name, organization or email can trigger a 60-day inter-registrar transfer lock. A registrar may offer an opt-out before the change, but it is not required to.

If the goal is also to move the domain to a different registrar, ask the current registrar about sequencing before changing registrant data. Preserve the zone, nameservers, DNSSEC records, renewal state and rollback path before any registrar or nameserver move.

Recover identity by provider, not by analogy

For Google Workspace, start with automated recovery and then the Google Admin Toolbox support-assisted recovery flow. It may ask an active user or contact to verify domain ownership. DNS control is useful evidence, but the provider still decides the recovery result.

For Microsoft 365 and Entra, first check for another Global Administrator, a partner with authorized delegated access or a documented emergency-access account. A full tenant lockout requires Microsoft support and ownership verification; publishing a DNS record is not a universal self-service promotion mechanism. Microsoft's current resilience guidance recommends two or more emergency access accounts precisely because the last normal administrator can become unreachable.

Once authorized administrative access exists, inventory before revoking:

• privileged roles and emergency accounts;
• recovery email, phone, MFA methods and passkeys;
• forwarding rules, mailbox delegation and transport rules;
• OAuth grants, app registrations and service principals;
• app passwords, API access and SMTP relays;
• SSO connections used by source control, cloud and SaaS providers;
• audit logs and recent privileged changes.

Do not suspend the outgoing identity until replacement human and machine paths are mapped and tested, unless an active security decision requires immediate containment.

Domain and identity are high-leverage roots, but provider-specific recovery and downstream testing still matter.

Hours 24–48: source, release, cloud and data

Preserve every repository you can lawfully access

GitHub's Account Recovery Policy is deliberately strict. If an account protected by two-factor authentication has lost all configured recovery methods, GitHub Support does not restore it through ID or social verification. GitHub also does not recover the contents of a locked user or organization account.

That makes existing authorized access valuable. If you can still read a repository, preserve it before access changes. GitHub documents a mirror clone as a repository backup:

git clone --mirror AUTHORIZED_REPOSITORY_URL cd REPOSITORY.git git lfs fetch --all

The last command is needed only when the repository uses Git LFS. Store the backup in an approved location with access control. A Git mirror does not include every platform object: issues, pull requests, discussions, branch-protection rules, Actions settings, environments, secrets, packages and organization roles need separate inventory or export.

Do not attempt to guess credentials, reuse a former developer's session or access private repositories through an account you are not authorized to use.

Prove source-to-production provenance

A repository is useful only when it can be connected to the live system:

repository and history → protected revision → CI run → immutable artifact → deployment revision → runtime → database migration state

Record the current commit SHA, framework/runtime versions, lockfile, build command, artifact or deployment ID and production migration state. If the running workload cannot be traced to accessible source, label the baseline NOT VERIFIED and treat the first production change as a no-go until a business owner accepts a specific containment plan.

The 30-day takeover checklist explains how to prove this chain, map indirect release triggers and make the first safe change after emergency recovery.

Start cloud recovery without inventing a shortcut

For AWS, first determine whether the account is standalone or a member of AWS Organizations and whether centralized root access is enabled. AWS's root-user troubleshooting guidance distinguishes recovery through the root email from alternate support routes. Control of a company domain may help recreate a corporate mailbox; it does not authorize access to a personal mailbox used by the former developer.

Use the equivalent official recovery route for Google Cloud, Azure or the hosting provider. Prepare account or tenant IDs, invoices, company documents, existing administrators and authorized contact details. Do not publish a universal list of documents or completion time: providers can ask for different evidence.

Prove recovery without touching production

If you have authorized data access, identify the complete recovery set:

• database backup and transaction logs;
• object storage and uploaded files;
• encryption and signing keys;
• schema and migration history;
• source, build definitions and artifacts;
• infrastructure configuration;
• queue or durable job state;
• DNS, email and webhook configuration.

Restore into an isolated environment. Block real emails, payments, webhooks, push notifications and scheduled jobs. Validate critical business flows, tenant separation, file links, decryption, row counts or other domain-appropriate reconciliation, and record the actual recovery point and restore time.

A backup job is evidence that a process ran. An isolated, reconciled restore is evidence that recovery is possible.

Hours 48–72: mobile, signing, payments and the long tail

These systems often depend on provider governance rather than technical access alone. Start their cases early and report them honestly as open until the provider confirms a result.

Apple Developer and App Store Connect

In an organization membership, the current Account Holder can transfer that role to an eligible team member with authority to bind the organization. Apple's Account Holder transfer documentation requires the existing holder to initiate the normal flow.

If the Account Holder is unreachable, contact Apple Developer Support and provide only the documentation Apple requests. Do not promise that support will override the current holder. If an app lives in an individual's separate developer account, moving it is an app transfer, not an internal role change, and the current account holder normally initiates it subject to eligibility criteria.

Apple distribution certificates can be created or rotated by authorized roles once the organization account is controlled, and cloud-managed certificates may reduce dependence on a local keychain. That does not mean every signing or push dependency is automatically recovered. Inventory Team IDs, App IDs, entitlements, APNs keys/certificates, provisioning profiles and any third-party API that trusts a certificate fingerprint.

Google Play and Android signing

Account ownership and app signing are separate. Use Google's developer account owner-transfer process for the account.

For apps enrolled in Play App Signing, Google holds the app signing key and can reset a lost upload key through the documented process. If the app is not enrolled and the only app signing key is lost, a replacement key may not allow updates to the existing installed app. Record which signing model the app uses before promising recovery.

Payments and payouts

Confirm the business identity, account owner, authorized representatives, payout bank account, recent privileged changes and webhook/API-key ownership. Stripe's account role documentation makes ownership transfer a privileged action; other processors have their own rules.

If the payout destination is unexpected or money may be moving without authorization, treat it as a financial-security incident and contact the processor and appropriate financial/legal owners. Do not make an improvised bank-account change that could freeze payouts or complicate ownership verification.

Use billing as a clue, not as the inventory

Company card and bank statements can reveal forgotten providers, but they are incomplete. Free services, annual renewals, consolidated invoices, reseller accounts and charges paid personally will be missing. Reconcile billing with DNS, source configuration, environment-variable names, network calls, mobile entitlements and production telemetry.

Provider governance is part of the system. “We pay the bill” is useful evidence, not a universal ownership transfer.

Eight things not to do

1. Do not access an account without explicit authorization. Believing that the business should own an account is not the same as being authorized to use someone else's credentials or session. Use provider recovery and qualified legal help.
2. Do not rotate every credential on the first morning. Map dependants, create client-controlled replacements, test them and rotate in dependency order. An active compromise is a separate incident decision.
3. Do not repoint nameservers without a complete zone and rollback plan. Include DNSSEC, mail, certificate validation and non-web records.
4. Do not change registrant data before asking about transfer sequencing. A 60-day inter-registrar lock may apply.
5. Do not cancel or delete old accounts as a substitute for taking control. Preserve data, configuration, billing continuity and the recovery path first.
6. Do not push a “test” commit before mapping release triggers. It may deploy, migrate or run automation outside the repository.
7. Do not restore a backup into production to see whether it works. Use an isolated environment and contain external side effects.
8. Do not turn a technical inventory into a legal ownership verdict. Preserve the documents and let qualified counsel interpret them.

Who owns the code? Preserve evidence before answering

This section is general US information, not legal advice.

Paying an independent contractor to write software does not by itself answer who owns copyright. The U.S. Copyright Office's Works Made for Hire guidance distinguishes work created by an employee within the scope of employment from specially commissioned work. Commissioned work qualifies as work made for hire only with a signed written agreement and within statutory categories; software is not automatically covered merely because a contract uses the phrase.

Separately, 17 U.S.C. Chapter 2 requires a signed writing for a transfer of copyright ownership. Contract wording, reused components, open-source obligations, employee and subcontractor contributions, and jurisdiction-specific facts all matter.

Preserve:

• master services agreement, statement of work and change orders;
• employment and contractor agreements;
• IP assignment and license clauses;
• invoices and payment records;
• complete repository history and contributor identities;
• third-party and open-source component inventory;
• design assets, data rights and vendor terms;
• termination and source-delivery obligations.

Do not publish or act on a one-paragraph ownership conclusion from an engineering article. Ask qualified US counsel to review the actual documents and facts, especially before a dispute, fundraise or acquisition.

The hour-72 evidence pack

By the end of the first 72 hours, aim to produce a concise evidence pack—not a claim that the takeover is finished.

Full operational ownership comes later. The incoming team still needs to prove that it can build the verified source, restore the critical system, observe failures, release a small change and roll it back without depending on the former developer.

If the recovered product was built mainly through AI coding tools or a hosted app builder, continue with the 12-gate AI-built application production audit. It separates a working demo from verified ownership, authorization, data, recovery and release evidence.

Hour 72 is a decision gate: verified control where possible, visible unknowns everywhere else.

If control is healthy and the product mainly needs ongoing updates, application maintenance may be the next step. If specific platform or architecture constraints block the roadmap, evaluate application modernization only after the production baseline and recovery path are understood.

Frequently asked questions

How long does full access recovery take?

There is no universal provider timeline. Self-service recovery may resolve quickly; account-owner disputes, missing recovery methods, app-store transfers and legal questions can take longer and may not have a provider override. The 72-hour objective is to contain risk, preserve authorized evidence and start every critical process—not to promise completion.

The developer still replies occasionally. Should we use this runbook?

Use the cooperative path wherever it still exists. Send one structured request for account ownership, source, deployment, data, billing and recovery information, then verify what arrives. Run evidence preservation and the ownership map in parallel because partial cooperation can stop without warning.

Should we rotate all credentials immediately?

Not by default. First identify human and machine identities, create client-controlled replacements, test them, then rotate or revoke in dependency order. If there is evidence of active compromise, the incident owner may authorize faster containment with an explicit outage and recovery plan.

The app is under the developer's individual Apple account. Can we recover it?

There is no self-service role transfer from someone else's individual account. A normal app transfer must be initiated by the current account holder and meet Apple's eligibility rules. Contact Apple Developer Support to understand available options, but do not assume it can or will override the holder.

Should we rebuild instead of recovering?

Do not use a rewrite to avoid learning what the current system does. First preserve source and data, establish the production baseline and identify the operating constraints. A rebuild can be the right later decision, but it still requires migration, coexistence, validation, cutover and rollback evidence.

What if we cannot prove control of the domain?

Use ICANN Lookup to identify the registrar, ask the registrar for its official recovery or dispute process, and assemble the evidence it requests. If the registration is held personally by the former developer or the facts are disputed, get qualified legal advice rather than attempting an account takeover.

Everything works today. Is recovery still urgent?

Yes, but urgency does not justify unsafe changes. The next renewal, certificate expiry, failed deployment, provider incident or payment problem can turn an ownership gap into downtime. Recovery is cheaper and safer while the product is stable enough to observe and preserve.

H Product Studio's software project takeover service covers scoped recovery, production-baseline verification and the transition into maintainable ownership. If the person who built your live product is unreachable, describe the accounts you control and what is currently at risk. Do not send passwords or production secrets through the contact form.

Research reviewed on 25 August 2026 against ICANN, Google Workspace, Microsoft Entra, GitHub, AWS, Apple Developer, Google Play, Stripe and U.S. Copyright Office guidance. Provider processes change; verify the linked official documentation when you act.