When Your Developer Disappears: Rescuing a Stalled Software Project
If your developer has disappeared or the project has stalled, act in this order. First, secure access to everything: domain, hosting, code repository, database, app store accounts and connected services. Second, take a complete backup of the code and data. Third, keep the live system running. Fourth, get an independent assessment of what exists against what was promised. Only then decide whether to finish, repair or replace, and re-contract on terms that stop it happening again.
The order matters. Teams that start by hiring a new developer to “just continue” often discover weeks later that nobody can deploy the system, because the server password left with the last person.
The short answer
- Keys before code. Every account in your company’s name, with old access revoked.
- Back up everything now: code, database, files and configuration.
- Stabilise what is live before changing anything.
- Assess independently: what works, what is missing, and what condition the code is in.
- Decide: finish, repair, or replace in parts. Starting from scratch is rarely the right call.
- Prevent a repeat with ownership, milestone payments and documentation built into the new contract.
“The first job in any rescue isn’t code; it’s keys. Until every account is in your company’s name, you don’t own a system. You rent it from whoever holds the passwords.” — Abdulqader Wahiba, founder and CEO of ZAWAT
The first week, step by step
The sequence below is the first-week checklist Abdulqader Wahiba recommends to any owner whose project has stalled, whoever ends up finishing the work.
1. Make an access inventory
List every account the system depends on and check, for each one, whose name it is in and whether you can log in today.
| Account | Why it matters | What to check |
|---|---|---|
| Domain registrar and DNS | Controls your web address and email routing | Registered to your company; you hold the login |
| Hosting or cloud account | Where the system runs | Account owner and billing are yours |
| Servers and databases | The live system and its data | You hold administrator credentials |
| Code repository | The source code and its history | The repository belongs to your organisation |
| App Store and Google Play | Your published apps | Developer accounts are in your company’s name |
| Email, SMS and WhatsApp services | Notifications and customer messages | Accounts and API keys are yours |
| Payment gateway | How you get paid | Merchant account is yours; keys can be rotated |
| Analytics and monitoring | What you can see | You have owner access |
| Backups | Your safety net | You know where they are and can restore one |
2. Change credentials and revoke old access
Once you hold an account, change its password, rotate any API keys and remove access for anyone who no longer works on the system. Do it carefully: rotating a key without updating the system that uses it can take the service down. If in doubt, list the changes first and make them with someone who can test each one.
3. Take a complete backup
Copy the full source code, the database, uploaded files and the server configuration to storage you control. Do it before anyone changes anything, so you have a known starting point.
4. Keep the live system running
If the system is already in use, stability comes first. Make sure someone can restart it, renew its security certificate and restore it from backup. New features can wait.
5. Read the contract and put requests in writing
Check what your contract says about ownership of the code, delivery of source code, and termination. Then ask the previous developer, in writing, for everything outstanding: code, credentials, documentation. Payment does not automatically transfer ownership of software; under Omani law the written contract matters, as who owns the software you paid for explains. This is a point to take to a lawyer if the developer will not cooperate.
6. Check who had access to personal data
If the developer could reach customer or staff data, record what access they had and remove it. Your obligations under Oman’s data protection law continue when a supplier leaves; hiring a software company without handing over your data covers what your agreements should have said and what to put in the next one.
The independent assessment
Before anyone writes new code, have a different team assess what exists. A useful assessment answers:
- Can it be built and deployed from the repository, by someone new, using the documentation available?
- What works, feature by feature, compared with what was promised?
- What condition is the code in: structure, tests, outdated libraries and known security issues? Technical debt, explained for owners covers what to look for.
- What is missing: documentation, environments, data migration, integrations?
- What will it take to reach a usable first version, given as a range?
Ask for the assessment as a written report you own, separate from any offer to do the work.
Finish, repair or replace?
| Situation | Usually the right move |
|---|---|
| Code is reasonably structured; features partly done | Finish it, with a new team and a smaller first release |
| Code works but is fragile, with heavy debt | Repair while finishing: stabilise, add tests, then extend |
| Some parts are sound, others unusable | Keep the sound parts and replace the rest in slices |
| Code cannot be built or deployed, or is insecure throughout | Replace, but reuse what was learnt: requirements, designs, data |
Starting from scratch feels clean, but it throws away working parts and knowledge along with the problems. Replacing in slices, while keeping what works, is usually faster and safer; replacing a legacy system without stopping the business explains the approach.
Whatever you choose, cut the scope of the next release. A rescued project regains confidence by delivering something small that works, not by promising the original plan on the original date.
Warning signs, before it gets this far
- Demonstrations of working software stop, replaced by status messages.
- Requests for repository or server access are deflected.
- Payments are requested ahead of milestones.
- Estimates keep moving with no explanation.
- Only one person ever answers, and replies get slower.
Any one of these is worth a direct conversation. Several together are worth starting the access inventory now, while relations are still good. How long a software project takes covers what a healthy schedule conversation sounds like.
Making sure it does not happen again
- Code in your company’s repository from the first day, with the supplier invited as a collaborator.
- Every account in your company’s name.
- Payment against working software, demonstrated at each milestone.
- Documentation written as the project runs, not promised for the end.
- More than one person on the supplier’s side who knows the system.
- An exit clause that guarantees handover. Choosing a software partner in Oman lists the clauses.
Frequently asked questions
Can I get my source code if the developer refuses to hand it over? It depends on your contract and on copyright law, so take legal advice. Your position is far stronger if the contract assigns ownership in writing and the code was kept in a repository your company owns.
Can a new team continue someone else’s code? Usually, yes, if the code can be built and deployed and is reasonably structured. An independent assessment tells you before you commit. Expect the new team to spend some early time understanding and stabilising it.
Should I pay the previous developer to finish? Only if they re-engage reliably, hand over full access first and agree to milestone payments against working software. If trust is gone, it is usually better to pay for a clean handover and move on.
How long does a rescue take? Securing access and backups can take days. The assessment typically takes a few weeks, depending on the size of the system. The time to a usable release depends on what the assessment finds.
What if customer data was exposed? Act quickly: revoke access, establish what data was reachable and by whom, and take advice on your obligations under Oman’s data protection law, including whether people must be notified.
Is your project stuck, or has your developer gone quiet? ZAWAT can assess a stalled custom software project and help you decide whether to finish, repair or replace it, starting with securing your access and your data. Book a call.