Agency abandoned your project or closed mid-build? What to do next

When an agency walks away from your project, or shuts down partway through, you lose more than the people writing code. Agencies often hold the accounts, design files, licences and project history as well. The way forward is to find out which situation you are in, collect everything that belongs to the project, and then judge honestly what state it is in before anyone new starts work.

Work out which situation you are in

The right first move depends on why work stopped.

• The agency still exists but has stopped working on your project. This might follow a budget dispute, a change in its priorities or a key person leaving. You can still ask for a handover, and a structured request usually gets results.
• The agency has closed or become insolvent. In many countries, an appointed insolvency practitioner, such as an administrator or liquidator, takes charge of the company's affairs. Check the public company register in the agency's country, and if someone has been appointed, write to them about your project materials and accounts.
• There is a payment dispute. Keep all communication in writing and consider legal advice before withholding money or making demands. Disputes are much easier to resolve when both sides can see exactly what was agreed and delivered.

List every asset, not just the code

Agency projects spread across many tools. Use this checklist to build your request:

• Source code for every part: web app, mobile app, backend, admin panel and any infrastructure or deployment scripts. Ask for all branches, not only the main one, since unfinished work often sits in branches that were never merged.
• Design files (for example Figma) and brand assets such as logos and fonts.
• Domain, DNS, hosting and cloud accounts. Agencies frequently host client projects under their own accounts.
• Database exports and recent backups.
• Third-party accounts created for you: email sending, analytics, maps, search, push notifications and app store listings.
• Licences for paid themes, plugins, fonts or component libraries, and whose name they are in.
• Project history: tickets, backlog, specifications and meeting notes exported from tools such as Jira, Trello or Linear.
• Documentation: setup steps, a list of environment variable names (not their values), architecture notes and test accounts.
• Details of any staging or test environment.

The Handover Checklist Generator turns your answers into a handover document you can send as part of the request.

Send a structured handover request

Write to the agency, or to the insolvency practitioner, and keep it practical. Refer to your contract or statement of work, attach the asset list, and ask for each item to be transferred properly: account ownership transfers, collaborator invites to the code repository, and design files moved to your workspace. Ask that no passwords are sent by email; anything shared that way should be changed immediately afterwards.

Request a short handover call with the developer who knows the project best, and set a reasonable date for completion. If your contract does not cover handover work, offering to pay for that time is often quicker than arguing about it. Our guide on how to hand over an unfinished software project explains what a complete handover looks like from both sides.

Questions worth asking on the handover call

If you get even thirty minutes with someone from the agency, use it for the knowledge that never makes it into documents. Write the answers down, or record the call with everyone's agreement.

• Which parts of the project are finished, which are half done, and which were never started?
• What are the known bugs, and are any of them risky for live users?
• How is the project deployed, and does anything depend on the agency's own accounts or tools?
• Are there scheduled tasks, background jobs or webhooks that run without anyone noticing?
• Which third-party services have usage limits or bills that could surprise you?
• If you were continuing this project yourself, what would you fix first?

The last question often produces the most useful answer of the whole handover.

Keep the live product safe meanwhile

If customers already use the product, protect it while the handover happens. Confirm the domain renewal date and who pays it, check that SSL certificates renew automatically, take your own backup of the database and files, and set up a basic uptime monitor so you know if the site goes down. The Production Readiness Checklist lists the essentials by stack.

Assess what you actually received

Once materials arrive, compare them with what you paid for. This is something you can do yourself:

1. Open your contract or proposal and list every feature or milestone.
2. Use the staging and live versions of the product and mark each feature as working, partly working or missing.
3. Check that the code you received is recent. If the repository is public, the Repo Health Check shows when it was last updated and whether it has a README and tests; for a private one, look at the dates of the latest commits.
4. Ask whether the live site is running the same version as the code you were given.

This record helps in any discussion with the agency, and it becomes the starting point for whoever continues the work. If the agency was effectively a single person who has now gone quiet, the steps on developer disappeared with the code may fit better.

What a developer picking up agency work looks at first

Agency-built projects have some recurring traits that a new developer will check early:

• Reusable agency code. Many agencies build on an internal starter kit or framework. The new developer needs to know whether you are allowed to keep using it.
• Build and deploy pipelines. Automated deployments are often connected to the agency's own accounts and stop working when access is removed.
• A clean-checkout test. They will try to set the project up from scratch using only the documentation. Whatever fails shows what was never written down.
• Mixed styles. Several developers may have worked on the code, so they will look for the parts that are fragile before changing anything.

Find someone to continue

When you have the assets, or know which ones are missing, post your project as a takeover for free. Describe the stack, what the agency delivered, what documentation exists and the state of account access. Freelancers and agencies who take over unfinished work can then contact you. Many will suggest a short paid assessment before quoting for the full job, which is a sensible first step. TakeoverWork does not check providers or handle payments, so read how to evaluate developers who want to finish your app and paying a developer safely before you commit.