How to take over software from a previous developer
To take over software after a developer or agency has left, do five things in order: gather every account, repo, hosting, and domain login you can find; get an independent audit that reads the actual code; make the salvage-or-rebuild call from that read; secure full ownership and reset access in your name; then stabilize and run it. Control the accounts first. Everything else is recoverable once the code and infrastructure are provably yours.
01 / Start here
Your developer is gone and the software still has to run. The first job is control, then code.
When a developer, agency, or AI-coding tool disappears, the fear is that the whole business is stranded on something nobody can touch. Usually it is not. What you have is a system whose keys are scattered and whose map lives in one person's head. Your task is to collect the keys, get an honest read on what exists, and put your name on everything before you change a single line.
Do not panic-hire a replacement and do not let anyone start rewriting yet. The most common way owners lose money here is spending on a rebuild before anyone has read what they already own. Roughly a third of lower-middle-market companies carry key-person IT risk, where critical system knowledge sits in one person's head. If that person left, this guide is the recovery path.
02 / Gather this first
Before you touch anything, collect the accounts and access that prove the software is yours.
Work through this list and write down what you have and what you are missing. The gaps are as useful as the finds, because they tell you exactly what leverage the old developer still holds.
- ✓ The source code repository (GitHub, GitLab, Bitbucket) and who owns the account it sits in.
- ✓ Hosting and servers (the cloud account: AWS, Vercel, Google Cloud, a VPS) and the billing owner.
- ✓ The domain registrar and DNS, so the site and email cannot be pulled out from under you.
- ✓ The database and where it lives, plus any backups and how far back they go.
- ✓ Third-party keys and logins: payment processor, email sender, SMS, any API the app depends on.
- ✓ Any documentation, prompts, or evals if AI was involved, and any README or setup notes.
- ✓ The last person who touched it and their contact, even if the relationship ended badly.
Missing most of this? That is normal. Start a conversation and we will help you find what exists.
03 / How a takeover runs
A clean takeover is five steps, in order. Skipping the audit is the mistake that costs the most.
- 01Week 0 to 1
Audit the system.
Get an independent read of the actual code, infrastructure, and build quality before any decision. A short paid software audit tells you what was built, what is salvageable, where the risk sits, and whether the previous work is a foundation or a liability. This is the one step that turns guessing into a plan.
- 02Week 1
Make the salvage-or-rebuild call.
With the audit in hand you can decide from facts, not fear. Sometimes the build is sound and needs an owner. Sometimes it is fragile enough that starting clean is cheaper than fixing it. Our guide on rebuild vs rescue walks the trade-off, and the audit gives you the specific answer for your system.
- 03Week 1 to 2
Secure ownership and reset access.
Move the repository, hosting, domain, and third-party accounts into your own name and rotate every credential the old developer held. From here on, the client owns the repo, source code, infrastructure, docs, prompts, and deployment outright. Nobody who left should still hold a key.
- 04Weeks 2 to 6
Stabilize the running system.
Fix what is broken, get backups working, patch the findings the audit surfaced against a written standard, and write down how the system runs so it is no longer trapped in one person's memory. The goal is a system that stays up and can be handed to anyone.
- 05Ongoing
Run it or hand it over.
Decide who keeps it healthy going forward. That can be an embedded team that runs and evolves it, or a clean handover to whoever you choose next, with the documentation and access to make the transition a ramp instead of a rebuild.
This is what a software rescue covers. Start a conversation to begin.
04 / Risk before, safeguard after
What a takeover replaces.
Each risk you inherit has a concrete safeguard on the other side of the takeover.
| Area | Before takeover (the risk) | After takeover (the safeguard) |
|---|---|---|
| Source code | The repo lives on the old developer's account. You are a tenant, not the owner. | The repository is in your account, with full history, and it is provably yours. |
| Access | Old logins and keys still work. Anyone who left can still reach production. | Every credential is rotated and held by you. No departed party has a key. |
| Knowledge | How it runs lives in one person's head. That person is gone. | Setup, architecture, and run-book are written down. Anyone can pick it up. |
| Code quality | Unknown vulnerabilities. AI-written code often ships with holes and no one checked. | The audit maps the findings and stabilization patches them against a written standard. |
| Continuity | No working backups. One bad day could lose the data the business runs on. | Backups run and are tested. The system can survive a failure and be restored. |
| The build itself | You do not know if it is sound, salvageable, or a rewrite waiting to happen. | A salvage-or-rebuild call made from a real read of the code, not a guess. |
05 / Red flags the previous build is fragile
Some signals mean the inherited system needs attention before you rely on it further.
None of these alone forces a rebuild, but a cluster of them is why the audit exists. The code risk is real. Veracode found in 2025 that 45% of AI-generated code ships with at least one OWASP Top-10 vulnerability, so a build stitched together with AI tools deserves a proper read before you trust it with customer data.
- No documentation, no tests, and no one who can explain how the system works.
- The code lives in an account you do not control, or you have never seen the repo at all.
- Passwords and API keys are hard-coded into the code instead of stored safely.
- There are no backups, or nobody has ever tested restoring one.
- Everything depends on one server, one account, or one person who has now left.
- Large amounts of AI-generated code with no review, especially near payments or personal data.
Recognize a few of these? Read signs you hired the wrong developer next.
06 / What ownership must include
A takeover is not finished until you own the whole stack, not a copy of the files.
Real ownership means you could hand the system to any competent team tomorrow and they could run it without asking the old developer for anything. If access still routes through someone who left, you do not yet own it. One safeguard worth knowing about is source code escrow, which holds a copy with a neutral third party so you are covered even if a future vendor vanishes.
- ✓ The source code repository and its full history, in your account.
- ✓ The infrastructure and hosting, billed to and controlled by you.
- ✓ The domain and DNS, so your site and email cannot be held hostage.
- ✓ The database, backups, and a tested way to restore them.
- ✓ Documentation, prompts, and evals if AI is part of the system.
- ✓ Every third-party account and key, moved into your name.
Want the full playbook? See software rescue and the audit, or start a conversation.
07 / Common questions
My developer disappeared and I have no documentation. Where do I start?
Start by collecting access, not code. Make a list of every account the software touches: the code repository, the hosting or cloud account, the domain registrar, the database, and any payment or email keys. Note what you have and what is missing. The gaps show you what leverage the old developer still holds. Then get a short paid audit that reads the actual system and tells you what exists. You do not need documentation to recover a system. You need the keys and an honest read.
Can a new team take over software they did not build?
Yes, as long as you can hand them the code and the access. A competent team can read an unfamiliar system, map how it works, and pick it up after a short ramp. The audit is what makes that ramp short, because it produces the map the old developer never wrote down. Where it gets hard is when you cannot get the repository or the accounts at all. Then the first job is recovering ownership before anyone can take over. That is what a software rescue handles.
Should I fix the existing software or rebuild it from scratch?
Decide from an audit, never from fear. Sometimes the inherited build is sound and needs an owner and some stabilization. Sometimes it is fragile enough that a clean rebuild is cheaper than untangling it. The only honest way to know is to have someone read the actual code, infrastructure, and build quality first. Our guide on rebuild vs rescue walks the trade-off, and the audit gives you the specific answer for your system so you are not guessing with real money.
How do I know if the inherited software is safe to keep running?
Look for a few concrete signals: working backups you can restore, credentials stored safely rather than hard-coded, and code that someone has reviewed. AI-built systems deserve extra scrutiny, since Veracode found in 2025 that 45% of AI-generated code ships with at least one OWASP Top-10 vulnerability. An audit maps these findings and tells you what to patch before you trust the system further. Until then, keep it running but treat it as unverified, and do not add new features on top of an unread foundation.
What does it mean to own my software?
Ownership means you could hand the system to any competent team tomorrow and they could run it without asking the previous developer for anything. In practice that is the repository and its full history, the hosting and infrastructure, the domain and DNS, the database and backups, documentation and any prompts or evals, and every third-party account, all in your name. If access still routes through someone who left, you do not yet own it. Securing all of it is a core step in any takeover.
How long does a software takeover take?
The read is fast and the stabilization depends on what the audit finds. An audit typically runs one to two weeks and gives you the salvage-or-rebuild call. Securing ownership and rotating access is usually days once you have the accounts. Stabilizing a running system, fixing what is broken, and writing down how it works commonly takes a few weeks. From there you either run it with an embedded team or hand it over cleanly. Start a conversation and we reply within a day with a fixed price and a date.
Last updated June 2026 · Talk with Felipe
Your build
Taking on new builds
Have something in mind?
Tell us what you're making. We reply within a day with a fixed price and a date.