My App Developer Left: What to Do Next (A Founder's Recovery Checklist)
It usually starts quietly. A message goes unanswered for a few days. A small bug fix that used to take an afternoon now takes two weeks. Then the email arrives, or worse, it never does: your developer has taken a full-time job, moved on to another client, or simply stopped replying.
If you are a founder or business owner, this moment can feel like losing the keys to your own building. The app still runs, customers still use it, but the one person who knew how it all fits together is gone.
The good news is that this is one of the most common situations in software, and it is almost always recoverable. The bad news is that the first few days matter more than most founders realise. This guide walks through what to do, in the order you should do it, so that a developer leaving becomes an inconvenience instead of a crisis.
First, Don't Panic, and Don't Rebuild Yet
When a developer leaves, the instinct is often to start again with someone new and "do it properly this time". Resist that instinct for now.
A rewrite is the most expensive and slowest option available to you. It throws away months or years of work, including fixes for problems you may not even remember having. In most cases, the right first move is not to rebuild but to secure what you have, understand it and keep it running. You can decide whether parts of the app need rebuilding later, with proper information.
So the immediate goal is simple: make sure your business, not any individual, controls the application.
Step 1: Secure the Source Code Today
The source code is the app. Without it, you cannot fix, change or move anything. Ask yourself one question right now: can you, personally, log in and download the full code?
If the answer is no, this is your top priority.
Find out where the code lives. Usually this is GitHub, GitLab or Bitbucket.
Ask for the repository to be transferred to an account owned by your company, or for you to be added as an owner.
If a transfer is not possible straight away, ask for a complete copy of the repository, including its history.
Confirm that what you received matches what is actually running. Code on a laptop that was never pushed is a common surprise.
Even if your developer left on good terms and is still reachable, do this now. People change phones, lose access and forget details. A polite, prompt request is far easier than chasing someone in six months.
Step 2: Take Control of Every Account
Apps depend on many services beyond the code itself. Each one is a potential lock-out if it sits in someone else's name. Make a list and work through it.
Account | Why it matters | What you want |
Code repository | Without it you cannot change the app | Company-owned organisation, you as owner |
Cloud hosting (AWS, Google Cloud, Azure, Vercel, Firebase and others) | Controls whether the app stays online | Account in your company's name and billing |
Domain registrar and DNS | Controls your website address and often your email | Registrar account in your company's name |
Database and backups | Your customer data lives here | Company-owned, with backups you can access |
App store accounts (Apple, Google Play) | Needed to publish mobile updates | Company developer accounts |
Payment providers (such as Stripe) | Controls revenue | Company account with you as admin |
Email and messaging services | Customer notifications stop if these lapse | Company account |
Analytics and error monitoring | History and alerts | Company account |
AI providers and third-party APIs | Features stop if keys are revoked | Keys issued to your company |
For every account, check three things: who owns it, who pays for it, and who can log in.
A note on ownership: who legally owns code written for you depends on your contract and local law, which this article cannot advise on. If ownership is unclear, talk to a lawyer before the situation becomes a dispute. Practically, though, controlling the accounts is what lets your business keep operating.
Step 3: Rotate Passwords, Keys and Access
Once your company controls the accounts, tidy up access:
Remove the former developer's access to repositories, hosting and admin panels, unless you have agreed they will continue to help.
Change passwords on shared logins.
Rotate API keys and tokens that the developer created or could see, especially for payments, email and AI services.
Disable old SSH keys and deployment tokens.
This is not an accusation. It is basic hygiene that every well-run company follows when anyone leaves. It also protects your developer, who no longer has to hold responsibility for systems they are not working on.
Be careful with one thing: rotating a key the app depends on can break it if the new key is not added in the right place. If you are not sure how the app uses a key, ask the new team to do the rotation as part of the handover.
Step 4: Collect Everything You Can
Knowledge disappears fast. Gather whatever exists, even if it looks messy:
Any documentation, README files or setup notes
Design files and product specifications
Contracts, invoices and statements of work, which show what was promised
Lists of known bugs and unfinished features
Diagrams, screenshots or recorded walkthroughs
Login lists for every service the app uses
If your former developer is still reachable and cooperative, ask for one recorded handover call. An hour of them explaining how to deploy, where the data lives and what is fragile can save weeks of investigation. Keep the request small and specific; people are far more willing to help with one call than with an open-ended commitment.
If they are not reachable, that is fine. A capable team can reconstruct how the system works from the code and the running environment. It just takes longer.
Step 5: Make Sure the App Keeps Running
While you sort out access and find a new team, someone needs to make sure the app does not quietly fall over. Check these basics as soon as you can:
Is the app online, and will you know if it goes down? Free uptime monitoring tools can email you within minutes of an outage.
Are backups running, and has anyone ever restored one? A backup that has never been restored is a hope, not a plan.
When do the domain and SSL certificates renew? An expired domain can take your app and your email offline at once.
Are any payments due on hosting or services? Failed card payments are a surprisingly common cause of sudden outages.
Are scheduled jobs still running? Emails, reports and syncs often fail silently.
If you are not technical, this is the moment to get help rather than wait. A short stabilisation engagement is far cheaper than recovering from lost data.
Step 6: Get an Independent Review of the Code
Before you decide what to do next, get a clear, honest picture of what you have. An independent engineer or team should review:
Security: exposed secrets, weak access control, outdated libraries with known vulnerabilities
Code quality and structure: how hard the code will be to change safely
Dependencies and runtime versions: whether the platform is still supported with security fixes
Hosting and deployment: how the app is deployed, restarted and rolled back
Data and backups: where data lives and whether it can be recovered
Tests: whether there is any safety net for future changes
The output should be a written report in plain language, with risks ranked by urgency and an estimate for each fix. You should be able to understand it without a technical background. If the app was built partly or fully with AI coding tools, an AI-generated code audit is designed for exactly this.
Step 7: Decide How the App Will Be Maintained
Once you know what you have, choose who will look after it. There is no single right answer; each option suits a different situation.
Option | Strengths | Watch out for |
Hire a new in-house developer | Full-time focus, deep product knowledge over time | Recruitment takes months, and you rebuild the same single point of failure |
Hire another freelancer | Flexible and cost-effective for small changes | Same risk of them leaving; rarely includes monitoring or out-of-hours cover |
Development agency on projects | Good for new features | Ongoing support is often slow or expensive between projects |
Managed maintenance team | One accountable team for hosting, code, monitoring and incidents, with defined response times | A monthly commitment |
Many businesses combine options: a managed team keeps the app secure and running, while freelancers or an agency build new features as needed. What matters is that ongoing ownership never again depends on one person.
If you want a team to take the app over end to end, our guide to taking over an existing app explains how a structured takeover works, and Managed Run covers the monthly support that follows.
Should You Fix the App or Rebuild It?
This is the question every founder asks, and the honest answer is: usually fix, sometimes rebuild part of it, rarely rebuild everything.
Maintain and improve if the app works, customers use it and the main problems are age and neglect.
Upgrade in planned steps if the frameworks or runtime are outdated but the business logic is sound.
Replace one component if a single part is built on an abandoned service or is fundamentally insecure.
Plan a phased rebuild only if the code genuinely cannot support where the business is going, and keep the current app running while you do it.
Be wary of anyone who recommends a full rewrite before they have read the code. A rewrite can be the right call, but it should be a conclusion drawn from evidence, not a starting assumption.
How Long Does Recovery Take, and What Does It Cost?
Every situation is different, but a typical recovery follows this rough shape:
Phase | Typical duration | What happens |
Secure access | A few days | Code and accounts move into company control |
Review and stabilise | 1 to 3 weeks | Code review, monitoring, backups verified, urgent fixes |
Handover documentation | Alongside stabilisation | Setup, deployment and recovery written down |
Ongoing maintenance | Monthly | Updates, fixes, monitoring and incident response |
Costs depend on the size and state of the app. As a reference point, independent code audits commonly start in the hundreds of dollars for small apps, and ongoing maintenance retainers commonly range from a few hundred to a few thousand dollars per month depending on hours, response times and out-of-hours cover. Ask any provider for a fixed scope and a written estimate before work starts.
How to Make Sure This Never Happens Again
Whoever you work with next, set these rules from day one:
Accounts in your name. Every repository, hosting account, domain and service is created under your company, with your developer added as a user.
Code in your repository. Work is pushed to your repository regularly, not delivered as files at the end.
Written documentation. Setup, deployment and recovery steps are written down and kept up to date.
A staging environment. You can see changes before they reach customers.
Monitoring and tested backups. Alerts go to more than one person, and restores are tested.
Clear contracts. Ownership of code and work product is stated in writing.
No single point of failure. At least two people, or one accountable team, can deploy and fix the app.
Red Flags to Watch For in Your Next Developer
Reluctance to give you repository access
Delivering builds or files instead of source code
Accounts created in their personal name
No documentation, ever
Long periods without visible commits or updates
None of these alone proves bad intent, but each one increases the risk that you end up reading this article again.
Frequently Asked Questions
What should I do first if my app developer leaves?
Secure the source code and get every critical account, especially hosting, domain and code repository, into your company's control. Everything else can follow once you hold the keys.
Can another developer take over my app?
Yes. Taking over existing code is common. A new team starts with a code review and handover, then stabilises and maintains the app without needing to rebuild it.
Do I need to rebuild my app if my developer disappeared?
Usually not. Most apps can be maintained and improved. A rebuild should only follow an independent review that shows the code cannot support your business.
What if my developer won't give me the code?
Check your contract and talk to a lawyer about your rights. Meanwhile, secure every account you do control, such as your domain and hosting billing.
How do I know if my app is secure after a developer leaves?
Rotate passwords and keys, remove old access, and get an independent code review that checks for exposed secrets, outdated libraries and weak access control.
How much does it cost to take over an existing app?
It depends on the app's size and condition. Expect a fixed-scope review or setup fee first, followed by a monthly maintenance fee based on hours and response times.
The Bottom Line
A developer leaving is stressful, but it is rarely fatal. Secure the code, take control of the accounts, keep the app running, get an honest review, and then choose a maintenance model that does not depend on one person.
If you would like help, Codersarts takes over existing applications every month, including apps built by freelancers, agencies and AI coding tools. We start with a secure handover and a plain-language review, then keep the app secure, updated and monitored. Talk to us about your app.
Comments