Developer left project midway: what to do in the first 24 hours
Stop further payments, gather every login, invoice and message you have, and check which accounts are in your name. Do not delete anything, do not argue in chat, and do not let anyone new touch the code yet.
When a developer left project midway, the instinct is to call the next developer immediately. Resist it for a day. Your bargaining position and your options depend on what you control right now, and a new developer cannot help much until that is clear. Open your email and search for messages from domain registrars, hosting companies, GitHub or GitLab, Google Play Console, Apple and cloud providers. Each email tells you which account exists and often whose name it is under.
Save the entire chat history, the quote or contract, payment receipts and any files they shared. Export WhatsApp chats with media. Take screenshots of the current state of the staging site or test app. These records matter whether the developer comes back, you negotiate a handover, or you ever need legal advice.
- Pause any pending or scheduled payments
- Export chats, emails, quotes and receipts to one folder
- Search your inbox for registrar, hosting, repository and store emails
- Screenshot the staging site or install the latest test build
- Write down every login you already have and test that it works
Is the developer really gone? How long to wait and how to ask
Send one calm, dated written request listing what you need, with a reasonable deadline, through every channel you have. Silence after that deadline is your signal to move on.
Developers go quiet for many reasons: illness, family emergencies, overcommitment, a dispute over payment or scope, or simply losing interest. Some come back. A clear message gives a returning developer an easy way to hand over properly, and gives you a record if they do not.
A useful message is short and specific: the project name, the date, a list of items you are requesting (repository access, database export, credentials for domain, hosting and store accounts, design files), and a date by which you need them. Keep it factual and polite. We do not give legal advice, and if significant money or a formal contract is involved, speak to a lawyer before sending anything that might be read as a notice. Our own terms show how we set out responsibilities in writing so this situation is less likely with us.
Make an inventory of everything the project depends on
After a developer left project midway, list every account and asset the website or app needs to run, and mark each as “in my name”, “in their name” or “unknown”. This one sheet becomes your recovery plan.
Most stalled projects involve more pieces than the owner realises. A basic business website depends on a domain, DNS, hosting and often business email. An app adds a code repository, a backend server or Firebase project, a database, a Play Console account, an Apple Developer account, push notification keys and third-party services such as maps, SMS or payment accounts. Each can be registered to a different person.
- Domain name and DNS settings
- Hosting or cloud server, including control panel access
- Business email and where it is hosted
- Source code repository (GitHub, GitLab, Bitbucket) or at least the code files
- Database and file storage, with recent backups
- Google Play Console and Apple Developer accounts, and the app listings
- Firebase or other backend project
- API accounts: maps, SMS, WhatsApp, email sending, payment collection
- Design files (Figma or similar) and brand assets
- Analytics, Google Search Console and Google Business Profile
Share this sheet with anyone you bring in. It saves hours of detective work and makes quotes far more accurate.
How to recover your domain when the developer registered it
If your developer left project midway holding the domain, find out who the registrant is, then either get the developer to move it to your account or ask the registrar for help if you can prove the name belongs to your business. The domain is the most important single asset because your email and every printed link depend on it.
Check the registration through a WHOIS or RDAP lookup; many records hide personal details now, but the registrar name will show. If you know the registrar and the domain is in your name or your business name, the registrar’s support team can usually help you regain access with identity documents.
If it sits in the developer’s account, the cleanest path is a push to your account at the same registrar, or a transfer to a registrar of your choice using the authorisation code. ICANN’s Transfer Policy for generic domains requires the registrar to provide that “AuthInfo” code to the registered name holder within five calendar days of a request, and it allows a 60-day lock on inter-registrar transfers after a new registration, a previous transfer or a change of registrant. Plan around that lock rather than being surprised by it. Country-code domains such as .in follow their own registry rules, so check with the registrar.
Getting hosting access and the source code back
When a developer left project midway, ask for the code repository to be transferred to your account, or at minimum for a full copy of the code and a database export. If the site runs on a server the developer controls, plan a migration to hosting in your own name.
For websites, a working copy of the files plus a database export is usually enough to rebuild the environment elsewhere. For apps, you need the actual source code; an APK or IPA file is a compiled package and is not a substitute. Also request any signing keys or keystore files for Android and the configuration files for the backend, because without them updates can become much harder.
If the developer refuses or cannot be reached, look at what you can reach. A hosting control panel in your name lets you download files and databases directly. A live website can sometimes be partially recovered from the server even without the repository. Where nothing is recoverable, the audit will tell you how much of the design and structure can still guide a rebuild. For moving off a server you do not control, see website migration.
What if the app is on the developer's Play Console or App Store account?
If the developer left project midway with the app on their account, ask them to transfer it to a developer account you own. Both Google and Apple have formal transfer processes, and both need the original account holder to start or support them.
Google’s Play Console help explains that you submit a transfer request, the target account reviews and approves it, and Google’s support team processes it, usually within two business days. Both accounts must be registered and active, the apps must comply with policy, and a new target account requires the one-time US$25 registration fee. Users, ratings, reviews and statistics move with the app; earnings reports and previous orders do not, so download them first. Integrated services such as Firebase need their permissions updated separately.
Apple’s App Store Connect help says the transferring Account Holder initiates the transfer and the receiving Account Holder accepts it. Reviews, ratings and the bundle ID stay with the app. TestFlight builds and testers must be removed first, and subscription apps need extra preparation. If the developer will not cooperate, contact the store’s developer support with proof of ownership; as a last resort, some owners publish a new listing under their own account and ask users to move.
Payment, SMS, maps and other services set up by the old developer
Move every paid or data-holding service into accounts under your business, then rotate the keys. Old keys the developer still knows should stop working once the new ones are live.
Payment collection accounts must be in your business name for settlements to reach you; if a developer opened one on your behalf with their own details, contact the provider’s support. SMS, email sending, maps and WhatsApp Business Platform accounts often sit on the developer’s card, and they may simply stop working when a card lapses. Analytics and Google Search Console can be reclaimed by verifying the domain once you control DNS.
Rotating keys and passwords is not about assuming bad intent. It is basic security when someone outside your business no longer works on the project. We handle this as part of a takeover and document each new credential in a handover sheet you keep.
Who owns the half-built code when a developer left project midway?
Ownership depends on your agreement. India’s Copyright Act, 1957 makes the author of a work its first owner by default, with an exception for work made by an employee under a contract of service, and section 19 says a copyright assignment is valid only if it is in writing and signed by the assignor.
In practice that means a freelancer or outside firm who wrote the code may hold the copyright unless your contract assigns it to you in writing. Many simple quotes never mention it. If you paid for the work, you likely have strong arguments, but how that plays out is a legal question we cannot answer. Speak to a lawyer if the developer is refusing to hand over code you paid for.
What we can do is make sure the next build avoids the problem: the repository sits in your account from the first commit, and your written quote with us records that the code is yours. That single clause would have prevented many of the takeovers we are asked about.
How to audit a half-finished website or app
Once a developer left project midway and you hold the code, an audit answers four questions: does the project build and run, which features actually work, what is missing, and what is unsafe or outdated. The output should be a written report you can show any developer.
We start by setting the code up in a clean environment in your account. If it will not build, that alone is an important finding. Then we walk through each feature against the original scope, marking it working, partly working or missing. We review the database structure, look for secrets or passwords written directly into the code, check library versions for known security problems, and note how the code is organised.
For apps we also check Android and iOS project settings against current store requirements; Android’s developer documentation states that from 31 August 2026 new apps and updates on Google Play must target Android 16 (API level 36), with some exceptions, so an app abandoned a year ago may need upgrades before any release. The report ends with a finish-or-rebuild recommendation and the reasons.
- Builds and runs in a clean environment?
- Feature-by-feature status against the original scope
- Database design and data quality
- Hard-coded passwords, keys and other secrets
- Outdated or vulnerable libraries
- Store and platform requirements for apps
- Code structure and how easily someone new can continue
Should you finish the existing code or rebuild from scratch?
Finish when the code builds, follows a common framework, has a sensible structure and covers a meaningful share of the features. Rebuild when it will not build, relies on abandoned tools, has serious security flaws, or when finishing would cost close to a clean build anyway.
Owners understandably want to protect money already spent. But the money is spent either way; the real question is which path gets a working, maintainable product for less from today. A half-built app on a current version of Flutter or React Native with clear folders is often worth finishing. A website built on a heavily modified, outdated plugin stack with no documentation often is not.
A middle path works surprisingly often: keep the design, the database schema and any good backend code, and rebuild the front end or the weakest module. The audit makes this visible module by module, so you do not have to choose all or nothing.
Lean towards finishing
Code builds, common framework, sensible structure, most core features working, no serious security issues.
Lean towards rebuilding
Does not build, outdated or abandoned tools, hard-coded secrets throughout, missing source for key parts, scope has changed a lot.
How much does it cost to finish a project another developer abandoned?
When a developer left project midway, the cost to finish depends on what the audit finds, so a responsible quote comes after the audit, not before. As a reference, our starting prices for new work are websites from ₹10,000, apps from ₹40,000 and custom software from ₹60,000.
Three things drive a rescue cost: how much of the original scope genuinely works, how much of the existing code must be repaired before new features can be added, and how much account recovery and migration is needed. A clean codebase with a few missing features can be quick to complete. A tangled one may cost more to fix than to replace. Recovery and migration are usually modest in effort but essential.
You receive an itemised quote in about two working days after access is shared and the audit is done, with the audit, recovery, fixes, new features and relaunch as separate lines. Nothing is billed before your written approval. Payments are by UPI or bank transfer in India, or in USD by Wise, bank wire or PayPal from abroad.
Handing a stalled project to a new developer the right way
Give the new developer your asset inventory, all recovered credentials through a password manager or secure channel, the original scope, chat history about decisions, and a clear list of what you want finished first.
Then set up the next phase so it cannot happen again. Every account stays in your name, with the new developer added as a user. Code goes to your repository with regular commits you can see. Payments follow working builds you can test. Each week you get a short written update. If your new developer resists these conditions, that tells you something.
When we take over, the third of us runs the recovery checklist with you, another of us handles domain, hosting, cloud and store account moves, and one of us leads the code audit and completion. At the end you receive a handover sheet listing every account, where it lives and how the site or app is deployed, so any developer could pick it up after us.
Keeping a live site, app users and SEO safe during the takeover
If your developer left project midway after launch, protect what is working before improving anything. Back up files and databases, keep existing URLs, and schedule changes so customers are not disrupted.
For websites, a migration to new hosting should keep every URL the same or redirect old URLs properly, keep the sitemap and robots settings correct, and re-verify Google Search Console once you control DNS. Otherwise rankings built over years can drop sharply. Our guide to traffic drops after a migration covers what to check.
For apps with real users, avoid a forced new listing unless there is no other way, because users must reinstall and reviews start from zero. Keep the backend running while the app moves to your accounts, and release updates through staged rollouts so any problem affects a small share of users first. When payments are involved, test the full flow in a sandbox before switching live keys.
Contract terms that stop a developer leaving you stranded next time
So that no future developer leaves you stranded, put ownership, access and handover duties in writing before any work starts. These clauses cost nothing to agree and are what you will wish you had if the next developer ever disappears.
- All accounts (domain, hosting, cloud, repository, stores, APIs) opened in the client’s name
- Written assignment of copyright in the code and designs to the client on payment
- Code committed to the client’s repository at least weekly
- Milestone payments tied to builds the client can install or view
- Weekly written progress update, even if brief
- Handover duty on exit: credentials list, database export, deployment notes
- A named backup person who knows the codebase
- A defined notice period if either side ends the engagement
Have your lawyer review the wording. For more on what to ask before signing, read questions to ask an app developer before hiring, and for billing structures see fixed price vs time and material.
Example: a developer left project midway on a diagnostic lab's booking platform
Here is a hypothetical case to show the steps in order. Say a diagnostic lab in Kanpur hired a developer for a test-booking website and Android app. After receiving most of the payment, the developer stopped replying with the site on a staging server and the app in closed testing.
Day one: the lab owner exports the chats and receipts, then finds that the domain is in the lab’s name at a registrar, but hosting, the repository, the Firebase project and the Play Console account are all under the developer’s email. Day two: one written request for access goes out with a seven-day deadline. No reply comes. The lab regains the domain through the registrar, points DNS to new hosting in its own account and asks Google Play support about the listing.
An audit of the code the developer had shared earlier finds a Flutter app on a recent version that builds cleanly, with booking and reports working but payments and home-collection scheduling missing, and API keys hard-coded. The recommendation: finish, not rebuild, after rotating keys and moving the backend. Completion would be quoted on our app and web app starting points. This is an illustration, not a real client.
Recovery checklist after a developer left project midway
Work through these in order. Tick each only when the account is confirmed in your name and you have logged in yourself.
- Chats, quotes, receipts and files saved in one place
- Asset inventory completed with owner marked for each
- One dated written request for access sent
- Domain in your account, with DNS access
- Hosting or cloud account in your name, with a fresh backup
- Source code in your repository, plus Android signing keys if it is an app
- Database export and file storage copied
- Play Console and App Store listings moved to your developer accounts
- Third-party service accounts moved and all keys rotated
- Audit report received with finish-or-rebuild recommendation
- New contract with ownership, milestone and handover clauses