Skip to content
AnitoANITO
Resources

Rescue

When Your Developer Disappears: What to Do Right Now

Your developer has stopped responding. The person who holds the knowledge — and possibly the credentials — is not there. This is more recoverable than it feels in the first 48 hours, and most of the recovery is work you can do yourself, today, without hiring anyone. Here is the exact sequence, from immediate stabilization to long-term prevention.

9 min read · Updated June 2026 · By Anthony Garces — 17+ yrs in IT, principal-level architect

A wall panel of four lever switches in sequence beside a separate handle, lit by one caged lamp.
Four levers, in order. Panic is not one of them.

Before you do anything else: check what you can still access

The first job is inventory, not action — and it is entirely yours to do. Take stock of what you still have access to. Work through this list systematically and write down the result for each one: accessible, accessible with known credentials, accessible but credentials unknown, or inaccessible.

  • Domain registrar: the service where your domain name is registered (GoDaddy, Namecheap, Google Domains, etc.). Can you log in with an email and password you know?
  • Hosting account: where the website or application files live (Cloudflare, AWS, WP Engine, Kinsta, Heroku, DigitalOcean, etc.).
  • CMS admin: if you have a WordPress or similar site, can you log into the admin area at yoursite.com/wp-admin?
  • Code repository: is there a GitHub, GitLab, or Bitbucket account where the code lives? Who owns it?
  • Database access: can you reach the database that the application runs on?
  • Third-party services: email marketing, payment processor, analytics, form tools — can you log into each independently?
  • DNS records: do you know where the DNS is managed and can you access it? (DNS is separate from hosting and controls where your domain points.)

Write down every item and its status. That list is your starting point, and it is more than most people have in this situation. The items you can access are safe. The items you cannot access are where the work goes next.

Attempt to recover access through official channels first

Before treating any access as permanently lost, work through the official recovery paths. Most credential losses are recoverable without the developer's involvement at all:

  1. 1Check your email for registration confirmations. Most hosting and domain accounts send a welcome email with the account email address. Search your inbox for the hosting provider's name.
  2. 2Try the 'forgot password' flow on every platform, using the email address the account is likely registered to. Try your business email and any previous business emails.
  3. 3For domain registrars: contact their support team. If you can prove domain ownership (control over the registrant email, business registration documents), most registrars will help you recover access. This is a documented process, not a favor.
  4. 4For WordPress sites: if you have database access through your hosting control panel (cPanel, Plesk, or a hosting dashboard), you can reset the admin password directly in the database without needing the developer. Ask your hosting provider how to access phpMyAdmin.
  5. 5For GitHub or GitLab: if the repository is under an organization account and you are an owner, you can add yourself as a member and remove the developer. If it is under the developer's personal account, you may need to fork the code or contact GitHub support with proof of ownership.

Escalate methodically when self-recovery does not work

If informal contact and official password recovery do not get you back in, escalate in this order, one step at a time. Going straight to legal threats before a polite written request usually makes the situation worse, not better. Every step below keeps the door open for the one after it.

  1. 1Send a written message (email, not only Slack) to the developer clearly stating what access you need, the deadline by which you need it, and the business impact of not having it. Tone: professional, factual, not hostile. Keep a copy.
  2. 2If you have a signed contract, review it for provisions about code ownership, credential handover, and dispute resolution. Most well-written contracts give you clear grounds to demand access.
  3. 3Contact the hosting or service provider directly with proof of business ownership. Many providers have a domain/business verification process that lets the legitimate business owner recover access without the developer's cooperation.
  4. 4If access involves a significant financial interest and the developer is unresponsive to written requests, consult a lawyer about your options. In most jurisdictions, a developer who retains access to a client's systems after the engagement has ended is in a legally precarious position.

What not to do when access is disputed

Do not make changes to the system while it is in a contested state — if a dispute follows, you want a clean record of the system as it stood when you lost access. Do not threaten legal action before the normal recovery steps; it often makes developers defensive and slower to cooperate. And hold off on assuming malicious intent: the most common cause of a developer going quiet is personal circumstances, not deliberate obstruction.

Assess the damage once you are back in

Once you have recovered access to the core accounts, a damage assessment comes before any new work. Four questions, and you are entitled to plain answers to all of them: what is the current state of the code — is there version history, and how recent is it? What documentation exists, if any? What are the known issues or in-progress fixes that were never completed? What third-party services does the system depend on, and are their credentials current?

You do not have to do this assessment personally — a developer should — but it should arrive in a form you can read and judge without one. The output is a one-page summary: what works, what is fragile, what is missing, and what the risks are of the current state. If it comes back in language you cannot follow, ask again. That summary is what your next decisions rest on.

Stabilize before you improve

After recovering from a developer crisis, the instinct is to start building the features that were promised and never delivered. That instinct is right about what you are owed and wrong about the order. Stabilize first: make the system secure (change every credential the previous developer had access to, immediately), confirm that backups are running, add uptime monitoring if it does not already exist, and document the current state in enough detail that a new developer could take it over without another crisis.

  • Rotate every credential the developer had access to: hosting, CMS, database, third-party API keys, payment processor, analytics.
  • Enable two-factor authentication — the code sent to your phone on login — on every account that supports it.
  • Confirm that automated backups are running and that you can restore from them. Test the restore process.
  • Set up uptime monitoring (UptimeRobot's free tier is sufficient for most SMBs) so you know immediately when something goes down.
  • Document the system: what it runs on, what each service does, where the credentials are stored, and what the deployment process is.

Prevent the next single point of failure

The root cause here is almost always structural rather than personal: the business depended on a single person for access, knowledge, and continuity — which is the arrangement that forms on its own unless someone deliberately prevents it. Preventing it is a handful of choices made at the start of the next engagement, and every one of them is yours to ask for.

  • Every domain, hosting account, repository, and third-party service should be registered to a business email address you control — not the developer's.
  • The developer should be added as a collaborator to accounts you own, not the other way around.
  • Credentials and documentation should be handed over incrementally throughout the project, not promised at handoff.
  • A system that is live in production should have a minimum of written documentation describing what it does, how it is deployed, and what to do if it breaks.
  • Any developer who insists on owning the accounts or withholding credentials until final payment is a risk — negotiate ownership transfer upfront, not after.

The ownership question to ask before any new engagement

Ask any developer you are considering working with: 'Where will the code repository live, and who owns the hosting accounts?' The answer should be: your accounts, from day one. If the answer is anything other than that — 'we host our clients on our servers,' 'we'll transfer at the end,' 'that's easier for us to manage' — that is a structural risk, not a preference. At Anito, ownership transfers to the client at the first line of code, not at the final invoice.

What to remember

  • Inventory what you can still access before doing anything else. Write it down — that list is yours, and it is the whole starting position.
  • Use official recovery channels first — most access can be recovered without the developer's cooperation.
  • Once back in, rotate every credential the developer had access to before anything else.
  • Stabilize before improving: confirm backups, add monitoring, document the current state.
  • The long-term fix is structural: all accounts owned by the business, developer added as collaborator, from day one.

Common questions

  • You are in a stronger position than it feels. In most jurisdictions, the party who paid for software to be created owns the copyright, regardless of whether a formal contract was signed — though 'most jurisdictions' is not a legal opinion, and the specifics of your situation matter. If the amount involved is significant, consult a lawyer. In practice, most developer access disputes get resolved through the official account recovery processes of the hosting and service providers, without anyone litigating copyright ownership.

  • That depends on the security state, and it is a fair question to ask rather than assume. If the site is running an outdated CMS or unpatched plugins and you have discovered you don't have access, the site is a security liability right now. The priority is to secure the accounts you do have and assess what the previous developer last touched. A live site that is working is not necessarily safe — it may only be un-attacked so far.

  • A technical audit — documenting the current state, identifying risks, and producing a recovery plan — typically costs $800–$2,500 depending on the complexity of the system. Emergency access recovery and stabilization work varies considerably based on what is missing and how many systems are involved. Ask for a quote that includes the audit before you commit to any recovery work, so you are the one deciding what is worth fixing.

  • Finding it was the right instinct. File backups are necessary and not sufficient on their own. A complete site backup needs four things: the site files, the database, the configuration files (which often contain sensitive credentials that should be rotated after a developer exit), and documentation of the hosting environment. A file backup without the database will not restore the site to a working state for anything database-driven. Test your restore in a staging environment before you need it in an emergency — a backup nobody has restored is an assumption, not a safety net.

If you want a hand with this

Broken checkout. Developer unreachable. Every day down is revenue gone.

Want a second opinion on your own situation?

Start with a free project diagnosis. You leave with a clear, honest read on what is worth doing — and an honest no if it is not the right time. No obligation to build.

See your engine map