Shimira IT
It usually happens gradually. Replies take a day instead of an hour, then three days. The demo gets postponed. Then a message goes unanswered for a week, and you realise nobody is working on your software.
Whether your developer has genuinely disappeared or is simply avoiding you, the next two weeks matter more than the previous two months. Work through these steps in order. The early ones cost nothing and are the ones people most often skip.
First: take stock before you take action
Resist the urge to fire off an angry message or hire a replacement today. Ten minutes of assessment first will save you weeks.
Write down the answers to these:
- When did they last send working software, not a status update?
- What did you actually pay for, and what have you paid so far?
- Is anything live that customers depend on right now?
- Whose name is on the accounts: the code repository, the hosting, the domain, the app store listings?
That last question is the important one, and it's where this guide really starts.
Step 1: get control of your accounts today
This is the single most urgent action, and it's the one most people take too late. If your developer controls the accounts your product runs on, everything else is negotiation. If you control them, you have options.
Go through this list and check who holds the master account for each:
- Code repository (GitHub, GitLab, Bitbucket)
- Hosting and cloud (AWS, Google Cloud, Vercel, a VPS provider)
- Domain registrar
- Database, if it's hosted separately
- App Store Connect and Google Play Console
- Third-party services: payments, email, SMS, maps, analytics, any AI APIs
- DNS, which is sometimes separate from the registrar
Where an account is in your name but your developer has access, change the password and enable two-factor authentication now. Where the account is in their name, note it: recovering those is Step 3.
One thing worth checking immediately: if any service is paid on your developer's card, it will lapse when they stop paying. A domain expiring or a cloud bill going unpaid can take your product offline entirely.
Step 2: make a copy of everything
Before anything escalates, get your own copy.
- Download or clone the code from every repository and branch you can reach.
- Export the database, or take a snapshot if it's hosted.
- Download user-uploaded files from wherever they're stored.
- Save any documentation, designs, or credentials you've been given.
- Screenshot or export your project management board and chat history.
Keep it somewhere you control. This costs you an hour and protects you from the worst outcome, which is losing access while a dispute plays out.
Step 3: recover accounts that aren't in your name
If the repository, cloud account, or app store listing is in your developer's name, you have more routes than people expect.
If you paid the bills. Cloud providers, registrars, and app stores all have account recovery processes, and being the paying customer with billing records is strong evidence. Contact their support with your invoices.
If it's a company account. Where the account was created under your company's name or email domain, most providers will transfer control to the domain owner.
If your contract covers it. Many development contracts state that IP and access transfer to the client on payment. If yours does, a formal written request citing that clause often resolves things quickly, because the alternative is a contract dispute your developer will probably lose.
If none of that applies. A rebuild may be cheaper than a legal fight. Get a technical assessment first, so you know what rebuilding actually involves before you decide.
Contract and IP disputes are a question for a lawyer. Everything else on this list is technical recovery you can start today.
Step 4: send one clear, professional message
Keep the tone neutral. Your goal is information and access, not an apology. Something like:
Hi [name], I haven't heard from you since [date] and I need to plan around that. Could you confirm by [date, 3–5 days out] whether you're able to continue? Either way, please transfer ownership of [repository, hosting, domain, app store listing] to [your account], and send the current state of the work. If I don't hear back by then, I'll arrange for another team to take over.
Send it by email, even if you normally use chat, so there's a record. Keep it short. An angry message makes cooperation less likely, and a one-hour handover call from the person who wrote the code can save a new team days of work.
Step 5: find out what you actually have
This is where most people go wrong in the opposite direction: they panic and hire the first agency that says "we'd need to rebuild it from scratch."
Sometimes that's true. Far more often it's the easiest thing for a vendor to say, and it conveniently maximises their invoice. You can't judge either way without an assessment.
A proper take-over audit tells you:
- What's genuinely finished, what's half-built, and what was never started
- The state of the code: is it something a competent team can work with?
- Security problems, especially exposed keys and unprotected data
- Whether backups exist and whether they actually restore
- What it would cost to finish, versus to rebuild, part by part
Expect to pay for this. A fixed-price audit typically runs $2,000–$5,000 depending on the size of the system, and the written report should be yours to keep, even if you take it to a different vendor. That last detail is a good test of whether a vendor is being straight with you.
Step 6: stabilise before you add anything
If something is live and customers are using it, fix what's broken before building anything new. Failing payments, crashes, and broken sign-ups cost you customers every day they continue. New features on an unstable base just create new outages.
The order that works: recover access, stop the bleeding, then finish the build.
How to avoid this next time
Whoever you work with next, insist on these. Good developers won't object, because they're normal practice.
- Every account in your name from day one. Your developer gets access as a collaborator, not as the owner.
- Code in your repository, with commits pushed regularly rather than delivered in one lump at the end.
- Working software every two weeks. Not status updates, not screenshots. Something you can click.
- Written scope and milestones, with payments tied to delivered work rather than the calendar.
- More than one person who knows the system, even if it's just a documented handover.
- Documentation as you go, including how to deploy.
The common thread is simple: at any moment you should be able to hand the project to someone else without a crisis. A developer who makes that easy is a developer worth keeping.
If you need help now
Taking over half-finished and abandoned projects is regular work for us. We start with a fixed-price take-over audit so you know exactly what you have before committing to anything, and helping you recover access is the first thing we do.
If your app was built with an AI tool like Lovable, Bolt, or Replit, the failure patterns are different and we have a separate process for those: see AI-built app rescue.
Either way, tell us what's happened and we'll give you an honest read, including if the answer is that you need less help than you fear.