Your freelancer disappeared. How to take back your codebase and keep shipping

It usually starts small. A reply takes three days instead of one. Then a week. Then a vague message about a family thing, and then nothing.

Your developer has gone quiet, the product is half-built, and you realize you are not sure where some of the pieces live.

This is more common than most founders admit, especially with marketplace hires. It is also recoverable. The key is to do things in the right order: secure access first, understand what you have second, and only then start building again.

First 24 hours: secure your accounts

Before anything else, make a list of every account the product depends on and who owns each one. Usually that includes:

• Domain registrar and DNS (the most painful one to lose)
• Hosting and cloud (AWS, Google Cloud, Vercel, Heroku, a VPS)
• Code hosting (GitHub, GitLab, Bitbucket)
• Database and its backups
• App store accounts (Apple Developer, Google Play Console)
• Payments (Stripe, PayPal)
• Email sending (SendGrid, Mailgun, Postmark, Mailjet)
• Third-party APIs (maps, AI models, SMS) and their billing
• Analytics and error tracking

For each one, answer: Is the account in my company’s name? Do I have admin access?

Then act:

1. Remove or downgrade the departed developer’s access where you have admin rights.
2. Rotate every secret they could have seen: API keys, database passwords, deploy tokens. Do this even if you trust them. Keys leak from old laptops too.
3. Request transfer of anything registered in their name. Be polite and specific. Many developers set things up under their own account out of convenience, not bad intent.

Recover the code

Check where the source actually lives.

• Repo in your organization? Good. Check that the default branch is recent, and look for unmerged branches that might hold the latest work.
• Repo on their personal account? Ask for a transfer of ownership. GitHub and GitLab both support this in a few clicks.
• No repo at all, or it is months old? The running server may have newer code than anything in version control. Have a developer take a copy of what is deployed before anything restarts or expires.

Then read your contract. Look for IP assignment language. If it is missing or unclear and the product matters, get a lawyer’s view before you build on it further.

Figure out what is actually running

A new developer’s first job is not features. It is answering four questions:

1. Can I run it locally? If not, what is missing: environment variables, seed data, a service nobody mentioned?
2. Does the repo match production? Differences between the two are where surprises hide.
3. How does code get deployed? Manually over SSH? A CI pipeline? A button in a dashboard someone else controls?
4. What breaks if I change something? Are there tests? Error monitoring? Backups that have actually been restored once?

The output should be a short document: how to run it, how to deploy it, where the risks are. That document is the handover you did not get.

Then audit before you build

Once it runs, a senior developer should spend a few days reading the code and sorting what they find into blockers, risks, and things that can wait. Resist the urge to “just finish the feature he was working on.” You do not yet know whether that half-finished branch is close or wrong.

If the product was nearly launch-ready when your developer vanished, the next steps look a lot like getting a stalled app across the finish line.

The first week with a new developer

A good first week for whoever takes over looks like this:

• Day 1–2: get the app running locally and in a staging environment.
• Day 3: ship one trivial change all the way to production, to prove the deploy path works.
• Day 4–5: write the README and deployment notes, and list the top risks.

It feels slow. It is the fastest way to stop being dependent on one person again.

Make sure it never happens again

Most of the pain above comes from a handful of avoidable setup choices:

• Every account in your company’s name, with you as owner and developers as members.
• Code in your repository, never the only copy on someone’s machine.
• IP assignment in every contract, signed before work starts.
• A handover clause: what gets transferred, and how fast, when the engagement ends.
• Someone accountable besides the developer, so a quiet week gets noticed in days, not months.

This is a big part of why we run engagements the way we do. At Hiring.co, you hire through us, not a bid list. An NDA is signed before anyone gets access. Work happens in your repo and your tools. Chloe Reynolds stays on the account and checks in on whether the hire is shipping, so problems surface early. When an engagement ends, documentation, the knowledge base, and deployment details transfer within one working day, confirmed in writing.

If a developer does not perform, we replace them at no extra cost, and the new person picks up from the same repo and notes. There is more on how that compares to freelance marketplaces on our Hiring.co vs Upwork page.

If you are dealing with a silent developer right now, book a call. We can usually tell you on that call what it will take to get moving again.