Your development agency stopped responding. What to do in the first 14 days

The script is always the same. A deadline moves. The weekly call gets shorter, then cancelled. The person you signed with is replaced by someone who needs it all explained again. You ask for the source code and the tone changes. Then nothing. Here is what to do, in order - and the order matters more than the speed.

Days 1–3: control, not code

Do not start by looking for a new developer. Start by finding out what you actually own. Make a list of every account the product depends on and whose name and email is on each:

Anything registered to the contractor is something you rent, not own. Small-business owners have found their shop locked and their payouts paused because an "agency" account was the only admin. Transfer what you can today; document what you can't. Change passwords and enable two-factor on everything that is yours. Export the database, if you can reach it - a copy from today is worth more than any promise about tomorrow.

Days 3–5: the paper trail

Write one calm email to the contractor. State what was agreed, what was paid, what was delivered, and what you need by a date: full source code with history, all credentials, documentation of the deployment. Don't threaten; just be specific and copy it to yourself. If they reply, you've got what you need. If they don't, you've got the beginning of a claim - which you may never make, but which changes the conversation with your bank, your insurer and the platforms whose accounts you're trying to recover.

Collect the contract, every invoice, every payment confirmation and every message where a deadline or a scope was agreed. A chargeback or a dispute has a window; find out what yours is.

Days 5–10: the truth about the code

Now bring in an engineer - but not to fix anything yet. You want a written, as-is assessment that answers three questions in order: what blocks trust (security holes, exposed data, payments that don't reconcile), what slows delivery (architecture, tests, deployment), and what can wait. It should record the state of the repository, the test coverage, the infrastructure and the open vulnerabilities in language a non-engineer, an investor or a lawyer can use.

Be careful with the first opinion you hear. "Start from scratch" is the easiest thing for a new developer to say and the most expensive thing for you to do. Sometimes it's right. More often the parts of the system your users already rely on are worth more than the clean architecture a rewrite promises. Ask any engineer who recommends a rewrite to write down why, and what they'd keep.

Days 10–14: choosing who comes next

You've been burned, so you're now the most careful buyer in the market. Use it. Before anyone touches the code, a rescue team should be willing to show you:

And one warning from the second-burn stories: a company that offers a "code takeover" and turns out to have no in-house engineers is not a rescue. Ask who, specifically, will do the work - and meet them.

What recovery actually looks like

Control recovered or documented. A written picture of the code you can hand to anyone. The bleeding stopped - crashes, security, payments - and monitoring in place so the next failure is seen before a user reports it. Then the product kept live while broken parts are replaced piece by piece, with a rewrite only where the risk forces it. The end state is something that would pass a technical due diligence: tests, CI/CD, readable history, documentation, and a team - yours or a partner's - that can run it.

The hardest part is not technical. It's trusting that this time it will ship. The only cure for that is weekly, visible, clickable progress - which is why that's the first thing to insist on. If you want to talk through where you stand, tell us what you have access to and what you don't; we'll tell you what to secure today.