My Developer Left. How Do I Take Over My App?

What should I do first when my developer leaves?

Whether they left on good terms, stopped answering, or the agency contract simply ended, the first 48 hours look the same. Do not try to fix bugs or ship features yet. Secure what you have.

1. Write down every service the product uses. Look at your card statements and invoices for the last 12 months — hosting, domains, email, app stores, APIs. Each charge is a service your app depends on.
2. Make sure you are an owner or admin on each one. Not a guest, not "they'll add me later". Owner.
3. Get the code. A full repository with history, not a zip of the latest files. History tells the next developer why things are the way they are.
4. Take a backup of the database and file storage and store it somewhere the previous developer cannot reach.
5. Change shared passwords and rotate API keys you know about — after you have confirmed you can still log in everywhere.
6. Collect the environment variables. The secret keys and settings the app needs to run usually live outside the code. Without them, the code alone will not start.

Which accounts do I need to own?

This is the list we check first on every takeover. If any of these is in someone else's name, you do not fully control your product.

If the product was built recently and you are still at the stage of choosing who builds the next version, these same items belong in the contract before work starts — we covered that in the questions to ask before you pay a developer a deposit.

What if the developer won't hand over access or the code?

Most handovers are uneventful once you ask clearly. When they are not:

• Read your contract. Look for an intellectual property assignment clause. Under most service contracts the client owns the work they paid for, but the wording matters, and without a written agreement ownership can default to the author in many countries.
• Ask in writing, with a list. Name each account and each item: repository with history, database export, environment variables, credentials. A specific list gets a specific answer; "please send everything" gets a zip file.
• Use the platforms' own recovery routes. Domain registrars, app stores and payment providers all have processes for proving business ownership of an account. They are slow but they work when you can show invoices in your company's name.
• Get legal advice for anything contested. If money is owed in either direction, or the developer claims ownership of the code, talk to a lawyer before you escalate.

How do I know if the codebase is in good shape?

You do not need to read code to get a useful answer. Ask whoever takes over to answer these questions in writing after a first review:

1. Can the app be built from a clean copy of the repository, using only what is written down?
2. Can it be deployed to production by someone new, without the previous developer?
3. Are there automated tests, and do they pass?
4. How out of date are the dependencies, and do any have known security problems?
5. Are passwords or API keys committed into the code itself?
6. Are there backups, and has anyone restored one?
7. What is the one part of the system they would least like to touch, and why?

The answers tell you whether you are looking at a normal handover or a rescue. The last question is often the most useful one.

How long does an app takeover take, and what does it cost?

These are typical 2026 ranges for a takeover that ends with the product documented, deployable by the new team and monitored. A rescue of a badly broken system can cost more.

Those numbers cover understanding and stabilising the product, not new features. Ask any provider whether the takeover is a separate fee, and what you will have in hand at the end: written documentation, a working deploy process and access in your name.

Should I rewrite the app or keep the existing code?

Keep it, in most cases. A new team's first instinct is often to rebuild, because unfamiliar code always looks worse than code you wrote yourself. A rewrite throws away years of small fixes for edge cases nobody remembers.

A rewrite starts to make sense only when several of these are true at once:

• The framework or language is no longer supported and cannot be upgraded step by step.
• Every small change breaks something unrelated.
• The product's core workflow has changed so much that most of the code no longer fits it.
• It was built on a no-code platform that now limits the business.

Even then, a gradual replacement — one part at a time while the product keeps running — is usually safer than a big-bang rebuild.

How do I avoid depending on one developer again?

• Every account in the company's name, with the developer added as a member, never the other way round.
• A written deploy process that a new person can follow.
• Monitoring alerts that reach more than one person, including someone on your side.
• A team, not a person. If one person's holiday stops your product, the problem is the arrangement, not the person.

How we take over existing apps

We are a team of senior product builders, and taking over codebases other people wrote is a regular part of our work. With our Run plan — €1,900 a month, cancel any time, excl. VAT — the takeover is included: we secure and document access in your name, get the product deploying reliably, then keep it monitored 24/7, patch it, fix errors and deploy the fixes, with one improvement always in progress and a monthly report. You keep owning all code, data and accounts. See our prices for the full plans.

Frequently asked questions

What should I do first if my developer quits?

Secure access before anything else: make sure you are owner or admin on the code repository, hosting, domain, database, payment provider and app stores, get a full copy of the code with history, back up the database, and collect the environment variables the app needs to run.

Who owns the code if my developer leaves?

It depends on your contract. Most service contracts assign the work to the client who paid for it, but without a written intellectual property assignment, ownership can stay with the author in many countries. Check the contract and get legal advice if ownership is disputed.

How long does it take a new developer to take over an app?

A careful takeover typically takes 1–2 weeks for a small web app, 2–4 weeks for a mid-size SaaS or marketplace, and 3–6 weeks when native mobile apps are involved.

Should I rebuild my app after my developer leaves?

Usually not. Keeping and stabilising the existing code is cheaper and safer in most cases. A rebuild makes sense only when the technology is unsupported, small changes keep breaking things, or the platform itself limits the business.

Does ConceptZone charge extra to take over an existing app?

No. Taking over an existing codebase is included in the Run plan at €1,900 a month excl. VAT, cancel any time, together with 24/7 monitoring, security patches, error fixes and one improvement always in progress.

---