Your developer stopped replying. Messages go unanswered, the next delivery never comes, and you’re not even sure where your code lives. It’s more common than people think, and in the vast majority of cases it’s recoverable. Here’s what to do, in order, to take back control.
I take over stalled projects regularly. This is the checklist I run every time.
1. Secure your access before anything else
This is the urgent part. As long as one person holds the keys, you’re exposed. Recover or confirm, right now:
- The code: the Git repository (GitHub, GitLab, Bitbucket). Make sure you’re the owner, not just an invited collaborator.
- The domain names: the account at the registrar (OVH, Gandi, Namecheap). This is often the most fragile point.
- Hosting and infrastructure: server, database, cloud services (AWS, Vercel, Scaleway).
- Third-party accounts: payments (Stripe), transactional email, storage, analytics.
- The credentials: ideally transferred to an email address you control.
If you have no access at all, note precisely what’s missing. That’s the first thing whoever takes over will ask for.
2. Gather everything you have
Before calling anyone, pull together: the contract or quote, the latest invoices, the message history, and the last working version you saw (a link, a demo, a screenshot). Even incomplete, it speeds up the handover enormously.
3. Get an honest read on the project’s real state
Once you have the code, the real question is: what holds up, and what doesn’t? That’s what an audit is for. In a few hours you usually know:
- what works and can be kept,
- what’s half-finished,
- the technical debt and hidden risks,
- how much is genuinely left to do.
Without this assessment, any estimate is a guess.
4. Weigh your options
Realistically, you have three:
- Wait for the provider to come back. Rare, and rarely a good idea past a certain point. The trust is already broken.
- Take it over in-house, if you have the skill. Possible, as long as you accept the time it takes to understand the existing code.
- Hand the rescue to someone. The fastest, provided you pick someone who audits first rather than rewriting everything.
5. The contractual side, briefly
I’m not a lawyer, but two useful reflexes: send a written formal notice demanding delivery of the access and the code (often that alone unblocks things), and check your contract’s intellectual-property clause. The code you paid for should be yours.
6. How to take over cleanly
The classic mistake is handing the rest to someone who offers to “rebuild it all.” It’s more expensive, slower, and starts from zero when part of the work is usually salvageable. Instead, look for someone who:
- audits first, then quotes,
- states a fixed price before starting,
- stabilises what’s breaking first, then moves forward,
- hands you back every access at the end.
That’s exactly how I work on a project rescue: I recover what exists, take it to the finish line, and you keep the code.
In short
A provider who vanishes isn’t the end of your project. Secure your access, get an honest read on where things stand, and hand the rest to someone who takes over rather than starts again. Most of the projects I recover are moving again within days.
Project stuck? Get an audit. I’ll tell you where you stand and what’s left, no sugar-coating.
Frequently asked questions
Can a project be recovered if I don’t have the code? Often yes. A formal notice frequently gets the access released. Failing that, we start from the last available version and rebuild what’s missing.
Does everything need to be rebuilt? Almost never. A good part of the work is usually salvageable. That’s the whole point of the audit: keep what holds, only redo what’s necessary.
How long to take back control? Once access is recovered, a project is usually moving again within days of the audit.
