Taking over a codebase from a failed agency: the first 30 days

Taking over a codebase from a failed agency means working without the people who built it. This guide is for the case where the agency is unresponsive, withholding access, disputing invoices or gone, and nothing is documented. By day 30 you should hold the accounts, have an inventory, a ranked list of what's wrong, and a decision on who runs the code next. Think of it as a project handover checklist you run without the other side's help. If the exit is cooperative, use the guide to moving agency work in-house on cooperative terms instead. The wider choice of delivery models is in software development engagement models.

Is it a failed agency, or an agency in a dispute?

Three situations look alike from the outside and need different handling.

In the first, the agency is reachable and cooperative. You have a planned handover, and the guides on moving work in-house and on replacing an offshore team (see its FAQ on doing so without the vendor's cooperation) cover it. Nothing below is aimed at you yet.

In the second, the agency answers but holds something back: the repository, the admin logins, the final deliverables. Usually there's an unpaid or disputed invoice behind it. In our experience that is usually a money problem presenting as a technical one, so the fix starts with separating the two.

In the third, nobody replies. Emails bounce or sit unanswered, the account manager has left, the company may have closed. Here you recover what you can through the platforms and treat the rest as lost.

Most failures announce themselves before the silence. Japeto's guide to switching agencies lists the warning signs: your senior contact disappears, three deadlines in a row are missed, verbal updates replace demos, and payment terms change. Our rule of thumb, not Japeto's: if you have seen two of those, plan as if you're heading for the second or third situation.

How to take over a failed agency's codebase

1. Inventory every account and its owner of record (days 1-3)

Before you ask anyone for anything, find out what exists and whose name it's under. ApexStack's takeover guide sorts assets into eight categories: identity and email, source repository, hosting, domain and DNS, database, payments and authentication, mobile distribution, and design records. For each service, write down the owner of record, the recovery contact, the billing contact and the admins.

Your best evidence is your own inbox and card statements. Invoices, receipts and "welcome" emails from hosting, app stores and SaaS tools show which services were set up, and under which email. If that address belongs to someone who has left the agency, you may be unable to prove ownership to the vendor's support.

2. Snapshot first, then remove access, then rotate (days 1-3)

Export before you cut anything. Take a copy of the repositories, a database dump if you can reach one, and screenshots of hosting and DNS settings. Then remove the agency's people from each service, and rotate every token, database credential, API key and signing secret you can reach. Removing a collaborator doesn't delete the clones already on their laptops, so assume they still have the code and that old secrets in it are live until changed. Put the new secrets in a secrets manager, not a shared document, and read each service's audit log for access you don't recognise.

The mechanics of rotating as access transfers are in the cooperative guide linked above. What's different here is the order: you act first, because nobody is going to hand you the keys.

3. Check the contract and payment record (days 1-3)

Read what you signed before you write to anyone. In the US and in England and Wales, ownership of contractor-written code generally turns on a written, signed assignment rather than on having paid. In the US, section 204 of the Copyright Act (17 U.S.C.) makes a transfer of copyright ownership valid only if it's in writing and signed by the owner of the rights. In the EU the position varies by country, and the piece on who owns contractor code in the EU walks through it. For England and Wales, the Japeto guide says copyright belongs to the writer by default and an assignment must be written and signed. This is general information, not legal advice. Have a lawyer read the contract and your payment history before you send a formal demand.

4. Separate the money from the code (days 3-7)

Agencies hold code back because they think they're owed money. Take away that grievance without conceding what you dispute. Pay the undisputed amounts, dispute named items in writing, and offer a paid handover if the work is real. Then send one written request that lists the items you want, the format, and a deadline.

Ruzora's guide to a developer who won't hand over code gives a worked illustration, which is that source's example and not ours: a $1,500 invoice, $1,000 undisputed and paid, $500 disputed, settled at $1,200 in exchange for the code. It suggests a 7-day deadline. Keep the tone calm and the request narrow, because you may need this letter later as evidence that you asked reasonably.

5. Recover domains and other accounts (days 3-10)

Recovery routes differ by service, and most only work if the right person is still reachable or you control the recovery email. For domains, Japeto's notes say the registrant of record is the one who can act: .uk domains move by an IPS tag change, while .com, .net, .org and other gTLDs need an EPP or auth code and are subject to ICANN's 60-day transfer lock (not applicable to .uk). For GitHub, cloud and app-store accounts, follow each vendor's own transfer and recovery documentation.

6. When they've stopped answering (days 7-10)

If the written request goes unanswered, the next step is a formal demand; ask a lawyer whether it should go through counsel. The Japeto guide describes an escalation ladder for England and Wales: a formal chase, a Letter Before Action, mediation, then court, with small claims up to GBP 10,000. That's one jurisdiction's ladder, so treat it as an example of the shape and not as a rule for yours.

In our reading, escrow is prevention rather than a cure: it only helps if it was signed before the relationship broke down.

If the code truly isn't coming, plan for Plan B, which Ruzora describes as rebuilding: use the live app, its data and your designs as the specification. Be realistic about how much a running app tells you. You can see behaviour and recover content. You can't reliably see the logic behind it, the edge cases it handles, or anything that only runs on a schedule.

7. Prove you can build and run it (days 4-10)

Once you have a repository, the first question is whether it's complete. ApexStack's audit asks for a build from a clean environment, a deployed revision you can map back to a commit and its configuration, a backup and restoration path for production data (we would test an actual restore), a record of dependencies, licences and runtime versions, a secret scan of history and config, and one critical user flow exercised end to end.

Draco Automation's piece on inherited codebases treats a day-one clone-and-run as the signal: if local setup fails, expect the rest to be worse.

Two findings matter most. If the deployed version doesn't map to any commit, you probably don't have the real source. If a restore fails, you can't rely on your backups.

8. Triage by evidence, then ship one small thing (days 10-30)

Don't start with the code that looks ugly. Unicoconnect's takeover plan points to hotspots: files with the most git churn and the most support tickets. Put what you find into a risk register ranked by likelihood and impact. Security exposure on user data and anything that blocks deployment go to the top.

Before changing risky code, write characterization tests that record what it does today, bugs included. Then ship one small, safe fix through the full path, from branch to production. That's your end-to-end test of the new team, the pipeline and the access you recovered. It's cheap, and it tells you more in a week than another document would.

Repair, replace or rebuild: what the findings say

ApexStack frames four options: repair, replace one component, rebuild in stages, or rebuild the first release. Draco lists the conditions that push toward a rebuild: a broken data model, unsupported dependencies, code that won't run locally, and security problems on user data. Draco's rule: if your estimate to finish is close to the estimate to rebuild, rebuild.

Our judgment, not a sourced rule: a clean build and a working restore usually point to repair with a small senior team. No source, or a failed restore, points to rebuilding from the spec you can reconstruct.

What this means for who takes over the codebase

The day-30 findings decide the staffing question, so don't hire before you have them. This is judgment, not a sourced rule. A reproducible build, a verified restore and a short risk list suit a small senior team, whether in-house hires, nearshore engineers or a replacement agency. Missing source or a failed restore means budgeting for a rebuild, which changes the team size and the launch date.

Whoever you pick, hold three things constant: every account in an organisation you own, at least two owners on each (ApexStack recommends at least two GitHub org owners), and handover terms in writing before work starts, so you never repeat this month. Budget for a slower first quarter: the new team has no one to ask about the code.

Once the findings are in, the choice between fixing and starting again is covered in the guide to software project rescue and rewrite decisions.

Hiring engineers to take over a codebase through HighCircl

If your inherited stack is React, Node.js, Python, iOS, Android, Flutter, Go or DevOps, HighCircl can supply the engineers. Every candidate passes four vetting stages run by senior engineers. You get a shortlist of 3-5 within 72 hours, drawn from seven European countries: Poland, Hungary, Slovakia, Serbia, Slovenia, Romania and Spain. There's no subscription and no recruitment fee, and if an engagement isn't working, the engineer is replaced at no additional recruitment cost. See the HighCircl hire page for the roles covered.

FAQ

Who owns the source code if the contract is silent?

It depends on where you are, and it isn't something to settle on the internet. In the US, a transfer of copyright needs a signed writing. In England and Wales, copyright starts with the writer unless assigned in writing. In the EU, national rules differ, and contractors often need a written assignment (some countries, such as Poland, require one); see the linked guide. A silent contract is a reason to see a lawyer before you demand anything. This is general information, not legal advice.

Can a new developer recover code from the live app?

Partly. A rebuilt team can reproduce what users see and reuse your data and designs as a specification, which is the Plan B Ruzora describes. It can't reliably recover server-side logic, scheduled jobs or the reasoning behind them. Treat it as a fallback that costs a rebuild, not a substitute for the repository.

What is a source code escrow agreement, and does it help now?

It's an arrangement where a third party holds a copy of the code for release under agreed conditions. Unicoconnect lists escrow as an option to discuss when you depend on an outside team. If your contract didn't have one, it is unlikely to help with this agency. Write one into the next contract.

How long until a new team is productive?

Unicoconnect puts time to productivity at about 60 to 90 days, and deep knowledge of a medium or large system at 6 to 12 months. The 30-day plan above gets you control and a decision, not full productivity.