Silence from the people building your product is a particular kind of stress, because every day of it costs money and you cannot tell whether the work is happening. If you are dealing with a dev agency abandoned project, here is what to do, in order, starting today.

The first 48 hours: secure what is yours

  1. Repository. Log into GitHub, GitLab or Bitbucket. If the organization is yours, remove the agency's write access and clone everything, including every branch. If the organization is theirs, request a transfer in writing today and take a full clone of anything you can reach. A mirror clone (git clone --mirror) captures all branches and tags in one step.
  2. Cloud and hosting. Confirm the root account is in your name. Rotate the root password, enable two-factor authentication on your own device, and create a new admin user for whoever helps you next. Do not delete the agency's users yet; you may need to see what they set up.
  3. Domain and DNS. Log into the registrar. If you cannot, this is the most urgent recovery of all, because whoever controls DNS controls whether your site exists. Check the renewal date while you are there. A domain that lapses during a dispute is a second crisis.
  4. App-store accounts. Apple and Google developer accounts must be owned by your company. If the app was published under the agency's account, request a transfer; Apple supports it, Google requires a transfer request through the console.
  5. Payments, email, SMS, analytics. Each service in your name, each with its own rotated credentials.
  6. Write it all down. Every request you send, the date, and the response. You will need it if this becomes a contractual dispute.

Assess what you actually have

Most abandoned projects are 60 to 80 percent recoverable, and the code is rarely as bad as the silence suggests. Spend one hour with a developer you trust, or run these yourself. Give each check about ten minutes and stop there; the goal is a rough picture, not a full audit.

  • Does it run? Clone it, follow the README, try to start it. If there is no README, note what questions you had to ask. Good: running locally in under 30 minutes. Bad: missing environment files, a database nobody can recreate, or "it only works on Dave's machine."
  • What is the last commit date, and what does the history look like? Steady commits with clear messages are a good sign. One giant commit a week before the silence is a sign of a hand-off, and a reason to look for a second repository. Running git log --oneline --since="3 months ago" shows the recent pace in one screen.
  • Are there tests, and do they pass? A few passing tests around payments and login are worth more than hundreds of empty ones. Zero tests is common and not fatal, but it slows every change that follows.
  • What is deployed, and does it match the repository? Compare the production version with the latest commit. A gap means uncommitted work somewhere.
  • Are there secrets in the code? API keys and passwords in the repository mean they need rotating, and they tell you something about the agency's practices. Free scanners such as Gitleaks or GitHub's built-in secret scanning will find most of them in minutes.
  • How old are the dependencies? Run npm outdated, or the equivalent for the stack. A few minor versions behind is normal. Framework versions two or more majors behind, or past end of life, mean upgrade work before new features.

Why agencies go quiet, ranked

The cause shapes the recovery, so it is worth a guess. In rough order of how often we see them:

  1. The fixed price ran out. The project was underquoted, the budget is spent, and nobody wants to have that conversation. The code is often fine. It just stopped.
  2. The key developer left. Small agencies often have one person who understood your project. When they go, the rest of the team stalls. Expect thin documentation.
  3. A scope dispute. Both sides believe the other owes them something. Silence is a negotiating position. A written notice usually restarts the conversation.
  4. A technical dead end. An integration that does not work, or an architecture that cannot scale to the next feature. This is the case most likely to need a restart.
  5. The agency folded. Least common, hardest to recover from, because nobody is left to transfer accounts. Act on the account checklist first.

Continue, restart or rebuild a dev agency abandoned project

Continue when the code runs, the history is healthy, and the remaining work is clear. A new team can usually be productive in a week.

Restart on the same stack when the code runs but the structure is poor. Keep the data model and the working features; rewrite the worst parts one at a time. A typical case: the checkout works, but every screen talks to the database directly. You keep the checkout and move logic behind an API one screen per sprint.

Rebuild when it does not run, nobody can explain it, and the remaining scope is most of the product. Even then, the design work, the data model and the integrations research are usually reusable.

The test that matters is cost per feature, not code quality. If the next three features would take longer to build on the existing code than from a clean start, rebuild. If not, keep going. Teams that rebuild because the code is "ugly" often spend months re-creating features that already worked.

Protect yourself contractually

Read the contract for three clauses: intellectual property (when the code becomes yours, usually on payment), termination (notice period and what is delivered on termination), and payment terms (what you owe for work completed). Then send a written notice that cites the clause, states what you need (code, credentials, documentation) and a reasonable deadline, usually ten business days. Keep it factual. If there is no response, you have the record you need for a formal claim or a chargeback on milestone payments.

Be specific about what you are asking for. "All project materials" invites argument. "Admin access to the repository, the AWS root credentials, the Apple developer account transfer and the database schema" does not. Send it by email and by any channel the contract names for notices.

Do not pay a pending invoice until you have the deliverable it covers. Do not post about the agency publicly; it rarely helps and it can complicate recovery.

What the first week of a rescue looks like

Day one is the account checklist above, done together, and a read-only audit of the code. By day three you have a written assessment: continue, restart or rebuild, with the reasons and a plan for each. Days four and five are the first fixes that make everything after cheaper: a reproducible local setup, a deploy pipeline, monitoring. Nothing of yours is deleted, and every finding is in a document you keep.

What good looks like at the end of that week: any developer can clone the project and run it from the README, a deploy to staging takes one command, and you get an alert when production breaks. None of that is a feature, but each one removes a reason the next team could go quiet on you.

If you are in this situation now, request a free code audit. The first hour is the assessment above, run by an engineer, and you can decide what to do with the findings afterwards.

Frequently asked questions

The agency says we do not own the code until the final invoice is paid. Is that true?

It depends on the contract, and it is a common clause. Read it. If the work was delivered and the invoice is fair, paying it and taking the assignment in writing is often the fastest path. If the work was not delivered, the clause does not help them.

Can a new team pick up someone else's code?

Yes, if it runs and the history is readable. Expect a week of orientation and a list of things the previous team would have done differently; that is normal and not a reason to rebuild.

How long until we are shipping again?

Typical ranges: one to two weeks to ship again if you continue, a few weeks to a couple of months if you restart, and several months if you rebuild. Account recovery can add time if the agency controls the app-store or cloud accounts.

How do we avoid this next time?

Own every account from the first commit, insist on a staging link you can see every sprint, and require a written scope with an out list. Agencies that work this way have nothing to hide and no reason to go quiet.