How to Take Over a Software Project When Your Developer Leaves (2026)

Your developer has left, or your agency has stopped replying, and you are holding a product you cannot change. It is recoverable if you move in the right order. This guide is for founders who need to take back a software project and hand it to someone new. It covers access, the handover, an independent audit, fix versus rebuild, the next hire and how to avoid a repeat.

Step 1: secure access before anything else

First, find out what you actually control. Do it in the first 48 hours. For every item below, write down the account owner, the email it is registered to, who pays the bill and who has admin rights.

• Domain name: the registrar account. If it sits in the developer's personal account, your website and company email depend on them.
• Hosting and cloud: AWS, Google Cloud, Azure, Vercel, DigitalOcean and similar. Whoever's card is on file can switch it off.
• Code repository: GitHub, GitLab or Bitbucket. You should own the organisation. The developer should be a member, not the owner.
• Databases and backups: where the data lives, and whether there is a recent backup you can download yourself.
• App store accounts: Apple Developer and Google Play Console. Apps published under someone else's account can be transferred, but it takes time and the current holder has to cooperate.
• Third-party services and keys: payments, email delivery, maps, analytics, login providers, AI APIs.
• Admin logins: the CMS, the app's admin panel, error monitoring.

Once an account is yours, add yourself as owner and remove access that should no longer exist. Download a copy of the code and a database backup first, so a mistake cannot lock you out. Then rotate any password or key the departing person knew. For keys the live app uses, put the new key into the config, confirm the app still works, then revoke the old one.

Step 2: what to ask the departing developer for

If they are reachable, keep it calm and specific. Most departures are not hostile, and a friendly, precise request gets more than a legal threat.

• Transfer of every account above into your name.
• The full repository with its history, not a zip of the latest files.
• Environment variables and config needed to run the app, shared through a password manager rather than chat.
• Deployment steps: how code gets from the repository to the live site or the app stores.
• Known bugs, half-finished work and shortcuts.
• One or two hours of recorded handover, ideally with the next developer on the call.

Offer to pay for the handover hours. If there is no contract, or it is vague on ownership, get legal advice before the conversation turns sour.

If they are not reachable, work from what you control. Most registrars, hosting providers and app stores have a recovery or dispute process, and proof that you paid the bills or own the company email domain helps. Expect it to be slow.

Step 3: get an independent code audit

Before you hire someone to keep building, pay a different senior developer for a short, fixed audit. The person judging the code should not be the one paid to rewrite it. As a guide, plan for a few days on a small app and one to two weeks on a larger system. The number of components and integrations drives that.

The audit should produce a written report that covers:

1. Can it be built and deployed from the repository by someone new?
2. Architecture: the main components, where data lives, which external services it depends on.
3. Security: exposed secrets, outdated dependencies with known problems, missing access controls.
4. Code quality: tests, structure and the parts that are fragile.
5. Data: whether backups exist and whether a restore actually works.
6. A ranked problem list: fix now, fix soon, can wait, with rough effort for each.

"The code is bad" is not an audit.

Step 4: fix or rebuild?

A new developer will often suggest a rebuild. Be sceptical. Rewrites nearly always take longer than estimated, the old system has to keep running meanwhile, and a lot of ugly code is ugly because it handles real cases somebody once hit.

Fixing in place is usually right when the app builds and deploys, the data model is sound, the problems are concentrated in a few areas and real users depend on it today.

A rebuild can be justified when the source is incomplete, the framework is abandoned, the product has changed so much that the code solves the wrong problem, or it is a small prototype.

The middle path is to replace parts one at a time while the existing system keeps running. It is safer.

A rewrite feels like a fresh start. Usually it is the same project, paid for twice.

Step 5: brief and hire the next developer

Hire with the audit in hand. It turns "take over our app" into a defined job. Your brief should include:

• What the product does, who uses it, and the stack.
• The audit report and its ranked problem list.
• What must happen in the first month, for example "get deploys working and fix the top three security items".

Look for someone who has inherited code before. Ask: "Tell me about a codebase you took over. What did you do in the first two weeks?" Good answers start with stabilising, not rewriting. A short paid trial on one item from the audit list tells you more than a CV.

Step 6: avoid being locked in again

• Ownership in the contract: IP assigned to you on payment, accounts in your name, and a handover obligation at the end.
• You own the accounts, they get access: repository organisation, cloud, registrar and app stores in your name, billed to your card.
• Shared credentials in your password manager, not in someone's head or chat history.
• Documentation as part of done: a README that lets a new developer run the project, a deploy note, and a list of services and keys.
• Milestones tied to working, deployed features, not to time passing.

None of this assumes the next developer will behave badly. Clear ownership makes any future handover routine.

Next steps

When you are ready to hire, you can browse developer profiles on DevDey for free without an account, including DevDey-verified profiles, or post the job and use the audit to describe the work. Posting is free, DevDey takes no commission, and you pay the developer directly, so ownership terms sit in your own contract. Before you sign, work through our contracts, IP and NDA checklist, and consider a paid trial project on one item from the audit list.