It usually happens over about three weeks.
Replies that used to come the same day start coming the next. Then a Friday goes by. Then the standup gets moved, and the following one is quietly cancelled. When you do get an answer it is warm and non-specific — a hard sprint, a family thing, nearly there on the payment integration. And then one Tuesday you realise you have not actually spoken to anyone in eleven days.
The instinct at this point is to chase. Send a firmer email, escalate, ask for a call. Do that if you like, but do it second. There is a short list of things that get materially harder the longer you wait, and none of them requires the other party’s cooperation.
Hour one: secure what you can still reach
Access disappears quietly. Cards expire, trials lapse, someone’s personal account gets closed, a domain auto-renews to the wrong inbox. Before you do anything else, go and confirm — with your own eyes, logged in yourself — that you hold:
- The repository. Not “we have access to it”, but an account you control with owner or admin rights. If the code lives in a personal GitHub or GitLab account rather than an organisation you own, this is the single most urgent item on the page.
- The cloud accounts. AWS, Google Cloud, Firebase, Vercel, whatever it runs on. Billing owner matters as much as technical access — an account that stops being paid for stops existing.
- The domain and DNS. Frequently registered on someone’s personal card during week one and never moved.
- The app store accounts. Apple and Google developer accounts should be in your company’s name. If the app is published under the agency’s account, you cannot ship an update, and moving a listing between accounts is a process measured in weeks.
- Third-party services. Payment provider, email sender, error tracker, analytics, SMS gateway, maps key. Anything with an API key in the codebase is something you may be about to lose.
Write down what you actually hold and what you only think you hold. That list is the real starting position, and it is almost always shorter than the one in your head.
Hour two: take a copy of everything
Clone the repository — all branches, and the full history, not a shallow copy. Export the database. Download whatever design files exist. Screenshot the running application while it is still running, including the admin screens you will otherwise forget existed.
This is dull and it takes an afternoon and it is the step people skip. The commit history in particular is worth more than it looks: it is the only honest record of what was built, when, by whom, and how carefully. We have opened repositories where the history told us more in twenty minutes than three weeks of meetings had.
Then check the contract, not for blame but for facts
Two questions only, and neither is about who was at fault:
Does the contract assign IP to you on payment, or on completion? These are very different. “On completion” plus an incomplete project is a genuinely awkward position, and it is better to know that today than to discover it during a negotiation.
What does it say about handover? Many contracts specify deliverables — documentation, source, credentials — that were never actually delivered. That is useful leverage, and it is also a straightforward, unemotional thing to ask for. Most people who have gone quiet out of overwhelm will hand over a repository when asked plainly, in writing, without accusation.
If the company has entered administration rather than simply stopped replying, the situation changes shape: you are now dealing with an administrator, the answer is usually that assets can be released, and it is worth asking early because it gets slower as the process progresses.
Stop paying for work you cannot see
Obvious, and yet. Cancel the standing order. Do not pay the next invoice for progress nobody has demonstrated. If there is a retainer covering hosting or maintenance, separate that from the build — you may well need the hosting to keep running while you work out what to do with the code.
Now — and only now — find out what you’re holding
This is the part that decides everything else, and it is the part people most want to skip in favour of a decision. You cannot sensibly choose between carry on, hand to someone else or start again until somebody senior has actually read the thing.
What that read should tell you:
- Does it build and run from a clean machine, using only what is in the repository? If not, how far off is it? A project that only ran on one departed person’s laptop is a different problem from one with a broken README.
- How much is actually finished versus demoed. These diverge wildly on troubled projects. Features that looked complete in a call are frequently a hard-coded screen with nothing behind it.
- Are there tests, and do they pass? Not for their own sake — because tests are what make the next six months safe to change.
- What shape is the data in? A sound data model with messy code above it is recoverable. A confused data model is the expensive kind of problem.
- What is the actual risk list, in order? Not thirty issues. The three that decide whether this is worth continuing.
The output of that read should be a document, not a conversation. A conversation is easy to be optimistic in. A written memo — keep this, fix that, cut the other, and here is the reasoning — is something you can take to a board, a co-founder or another supplier, and it stays useful whoever you end up working with.
What we usually find
Two things, most times.
The first is that it is more salvageable than it feels. When you have been let down, the emotional pull toward “burn it and start clean” is very strong, and it is almost always the most expensive option on the table. Code that is unloved is not the same as code that is wrong. Quite often the data model is sound, the framework choices are conventional, and what is missing is tests, documentation and someone willing to own it.
The second is that the delay costs more than the code. By the time we are called, the average project has been drifting for two or three months. That is the expensive part — not the rewriting, the waiting.
The one thing to do differently next time
Whatever happens with this build, change one thing about the next arrangement: make continuous handover a condition rather than a final milestone. Repository in your organisation from day one. Credentials in your password manager, not theirs. A README that a new developer could follow on a clean laptop. A short architecture note kept current.
None of that is expensive while a project is healthy. All of it is what you are missing right now.
If you are in the middle of this: the technical debt assessment is ten questions and will give you a rough read in about two minutes. If you want someone senior to actually open the repository, that is The Memo — a written keep, fix, or cut, and it is yours to keep whoever you carry on with.