Your developer stopped replying. What to do this week.

The messages got shorter, then slower, then stopped. Maybe there is an unanswered invoice, or a promise about "next week" that has now been three. Either way you have a product, or most of one, and the person who understands it has gone quiet.

This is more common than anyone admits, and the first week matters more than the next three months. Here is what to do, in order, starting today.

Today: get your access back

Do this before anything else, including before you send another chasing message. Access is the thing that gets harder to recover as time passes and goodwill drains.

• The code. GitHub, GitLab, Bitbucket — confirm you are an owner of the organisation, not a collaborator on a repository inside someone else’s. If the repository lives in their account, that is the most urgent item on this list.
• The servers. AWS, Google Cloud, Azure, Vercel, Heroku, Netlify. Log in yourself. If you cannot, find out whose account it is on and whose card is paying.
• The domain and DNS. Registrar login. This is the one people forget, and it is the one that can take a site down entirely.
• The database, and a backup you have downloaded and can open. Not a backup that exists in a system you do not control.
• Third-party services with keys in the product: payment provider, email sender, SMS, storage, any model provider.
• The app stores, if there is a mobile app. Apple and Google developer accounts should be in your company’s name.

If any of these are in their name, ask now, politely and in writing, while the relationship is merely cold rather than broken. A short factual message asking for a transfer works far more often than a legal-sounding one.

Also today: take a copy of everything

Clone every repository to a machine you control, including all branches. Export the database. Download whatever documentation exists, even if it is three Notion pages and a Loom video. Save the whole message history with them — Slack, WhatsApp, email — because it is the only written record of what was agreed and it is the thing you will need if this goes further.

This takes an afternoon and eliminates the worst outcome, which is not "the project is late". It is "the project is gone".

This week: find out what you actually have

Now the real question. Not "is the code good" — that is a debate. The question is: can someone else pick this up, and how expensive will that be?

Get an engineer who is not them to spend a day answering five things:

1. Does it build and run from a clean checkout on a new machine, following whatever instructions exist? This one question separates "unfinished" from "unrecoverable" more reliably than any other.
2. How much of what was demonstrated is actually implemented, versus hardcoded to look right? Demo-shaped code is extremely common in unfinished projects and is not always dishonest — but you need to know.
3. Are there tests, and do they pass? Not how many. Whether any exist at all.
4. Is anything dangerous exposed — API keys committed to the repository, an admin route with no authentication, a database reachable from the open internet? These are common in rushed work and they are urgent independent of everything else.
5. What is missing between here and something real users could use?

You want this written down, in plain language, with a number attached to the last item. It is worth paying properly for. A day of an experienced engineer’s time is the difference between negotiating from knowledge and negotiating from anxiety.

Do not: rewrite it immediately

The reflex, once the panic subsides, is to declare the code unsalvageable and start again. Sometimes that is right. It is right much less often than it feels.

Rewriting throws away every decision that was correct along with every one that was wrong, and you cannot tell them apart yet. The most common outcome is nine months later arriving roughly where you already were, having paid twice.

Stabilise first: get it building, get it deployed somewhere you control, close the security holes. Then decide what to replace, with evidence. A codebase that runs is a much better negotiating position than one nobody can start.

Do not: chase them for months

Set a limit and hold it. One clear written message stating what you need — access transfers, the current state of work, a date — and what you will do if you do not hear back by a specific day. Then act on that day.

People stop replying for many reasons, and most are ordinary: they are overwhelmed, they took on too much, they are embarrassed the work is behind. Almost none of those reasons get better with a fourth follow-up. Your project does not benefit from the explanation.

If money is owed to them

Resist the instinct to withhold everything on principle. If work was done, an unpaid invoice gives them a reason not to hand over access, and access is worth more to you than the disputed amount is worth to either of you.

Paying an amount you dispute in exchange for a clean transfer of everything is often the cheapest possible outcome. Get the transfer done first, in writing, and argue afterwards if it still matters. It usually will not.

Then: hire differently

When you do bring someone in, whether an individual or a firm, change two things about how you engage them.

First, own the infrastructure from day one. Your GitHub organisation, your cloud accounts, your domain, your app store listings, with them invited in. Not because you expect this to happen again, but because it costs nothing when things go well and it is everything when they do not.

Second, work in short increments with something demonstrable at the end of each. If you are more than a few weeks from the last thing you could see and use, you have no way of knowing whether the project is progressing. The failure you have just experienced is usually invisible for months precisely because nothing was checkable in between.

One more thing

If this has happened to you, it is worth knowing it is not a judgement on you. It happens to experienced founders and to people who did the diligence properly. Small suppliers disappear for reasons that have nothing to do with the client, and the arrangements that make it survivable — owning the accounts, working in increments — are exactly the ones that feel like unnecessary bureaucracy until the day they are not.

Taking over half-finished products someone else started is a large part of what we do. If you want an honest read on what you have and what it would take, tell us what exists and where it stopped.