Before you do anything else: check what you can still access
The first job is not to panic and not to make changes. It is to 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. This list is your starting point for recovery. The items you can access are safe. The items you cannot access are where the recovery work starts.
Attempt to recover access through official channels first
Before assuming access is permanently lost, work through the official recovery paths. Most credential losses are recoverable without the developer's involvement:
- 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.
- 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.
- 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 favour.
- 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.
- 5For GitHub or GitLab: if the repository is under an organisation 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, not all at once. Going straight to legal threats before trying a polite written request usually makes the situation worse, not better.
- 1Send a written message (email, not just 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.
- 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.
- 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.
- 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 any dispute later arises, you need a clean record of the system state at the time you lost access. Do not threaten legal action before attempting normal recovery steps — it often makes developers defensive and slower to cooperate. And do not assume the developer has 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, the next step is a damage assessment before any new work starts. You need to know: 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?
This assessment does not need to be done by you personally — it should be done by a developer, but it should be documented in a form you can read and understand. The output is a one-page summary: what works, what is fragile, what is missing, and what the risks are of the current state. That summary determines your next steps.
Stabilise before you improve
The instinct after recovering from a developer crisis is to immediately start building the features that were promised and not delivered. Resist it. Stabilise first: make sure the system is secure (change all credentials 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 of the system 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 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 of the developer disappearance problem is almost always a structural one: the business depended on a single person for access, knowledge, and continuity. Fixing the structural problem requires putting ownership practices in place from the start of any new engagement.
- 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.