Your developer has gone quiet. Maybe the freelancer took a full-time job. Maybe the agency was bought, or folded, or simply stopped answering. The software they built is still running your orders, bookings or jobs every day, and nobody left in the building knows how to change it.
This is more common than anyone admits, and it is fixable. The mistake most businesses make is not the original choice of developer. It is what they do in the first fortnight after that developer leaves: panic, hire whoever replies first, and commission a rewrite before anyone has looked properly at what exists.
Symentic Technologies is a UK software company that builds custom systems for operational SMEs in the UK, Australia and New Zealand. We also run two live SaaS platforms of our own, and we take over existing projects, but only after an honest review of the codebase. This post is the order we would do things in if it were our business. You can follow most of it without us.
What "software project rescue" actually means
Software project rescue is taking responsibility for a system someone else built, getting it back to a state where it can be safely changed, and then deciding what to do with it. It is three jobs, in this order:
- Secure it. Make sure you control every account, key and copy of the code.
- Stabilise it. Make sure it can be built, deployed, backed up and restored by someone new.
- Decide. Keep improving it, partly replace it, or rebuild it, based on evidence rather than the new developer's taste.
Most failed rescues skip straight to step three. A new team looks at unfamiliar code, dislikes it, and quotes for a rewrite. Sometimes that is right. Often it is just the most comfortable option for the person quoting.
First 48 hours: secure what you own
Before anyone writes a line of code, find out what you actually control. Make a list and put a name next to every item: who owns the login, whose email it is registered to, and whether you can get in today.
- Source code. Where is the repository (GitHub, GitLab, Bitbucket, a laptop)? Is it in an account your company owns, or the developer's personal account?
- Domain and DNS. Who is the registrant on the domain? Who can change DNS records?
- Hosting and cloud. AWS, Azure, Google Cloud, Vercel, a VPS. Whose card, whose root login?
- Databases and backups. Where is the production data, and when was a backup last restored, not just taken?
- App store accounts. Apple Developer and Google Play listings belong to whichever account published them. Both stores have transfer processes, but they need the current account holder's cooperation.
- Payments and third-party services. Stripe or other payment providers, email sending, SMS, maps, accounting integrations, AI APIs. Each one has keys that may live only in the old developer's head or config.
- Documentation and credentials. Any password manager vault, environment files, deployment notes.
Then change what you can. Rotate passwords and API keys that the departing developer held, remove their access from production systems once you have your own, and make sure two people at your company can get into each critical account. If the system holds personal data, controlling who has access is not housekeeping. It is part of your obligations under UK GDPR, Australia's Privacy Act 1988 or New Zealand's Privacy Act 2020.
If the developer is cooperative, ask for a handover now, while goodwill exists. If they are not, find out what your contract says. We covered why paying for software does not automatically mean you own the code in You paid for it. In most countries, that doesn't mean you own it. If ownership is unclear, speak to a solicitor before you spend money building on top of it. This post is practical guidance, not legal advice.
Week one: stabilise before you change anything
Freeze new features. It feels like lost time. It is not. Every change made before the system is understood is a change nobody can safely undo.
A new developer's first job is to prove five things:
- It builds from clean. Someone who has never touched the project can check out the code and build it, using only what is written down.
- It deploys repeatably. There is a known way to push a change to production, and a known way to roll it back.
- Backups restore. A backup has been restored somewhere safe and the data checked. An untested backup is a hope.
- Secrets are out of the code. Passwords and keys are not committed in the repository. If they are, they get rotated, because anyone with a copy of the code has them.
- Someone is watching. Errors, uptime and failed payments or orders alert a person, not just a log file nobody reads.
Until those five are true, you do not have a software project. You have a running process that nobody can maintain. Getting them true is usually the cheapest and highest-value part of any rescue.
The honest codebase review
Once the system is stable, a good review answers business questions, not style questions. "The variable names are inconsistent" is not a finding. "Order totals are calculated in three places and they disagree on discounts" is.
Ask your reviewer to cover:
- What the system actually does today, mapped against how your business really runs. Undocumented behaviour is often your business rules hiding in code.
- Where the risk sits. Money, stock, customer promises and personal data first. Cosmetic issues last.
- Dependencies. Which frameworks and libraries are out of support or have known security issues, and how hard they are to upgrade.
- Tests. Whether any exist, and whether they cover the paths that would hurt if they broke.
- Data model. Whether the database structure can carry the next two years of the business, or is already being bent around.
- Bus factor. Which parts only make sense to the person who left.
The output should be a short written report you can understand without a developer in the room, with a recommendation and the reasoning behind it. If the review comes back as a rewrite quote with no findings attached, treat it as a sales document.
Keep, refactor or rebuild
There is a long-standing argument in software, made most famously by Joel Spolsky in his 2000 essay "Things You Should Never Do", that rewriting working software from scratch is one of the worst strategic mistakes a team can make, because the messy old code contains years of fixes for real problems. That argument still holds up more often than new teams like to admit.
A practical way to decide:
| Signal | Usually keep and improve | Usually rebuild, in phases |
|---|---|---|
| Core logic | Correct, just messy | Wrong in ways that cost money |
| Stack | Mainstream and still supported | Abandoned, or nobody hires for it |
| Data model | Fits how you work | Fights every new requirement |
| Change cost | Slow but predictable | Every small fix breaks something else |
| Security | Fixable issues | Structural problems with data or access |
Even when a rebuild is justified, it rarely needs to be a big bang. Put a new module beside the old system, move one workflow across, prove it, then move the next. Your team keeps working the whole time, and you can stop at any phase if the old part turns out to be good enough.
If a rebuild is on the table, scope it the way you would scope a new build. You can't look up what your MVP costs, but you can work out how many weeks it is, and the same logic applies to replacing part of a system.
Choosing who takes it over
The second developer matters more than the first, because they inherit both the code and the lack of trust. Things worth checking:
- Have they taken over someone else's code before, and will they talk about what they found without slagging off the previous team?
- Will they start with a paid review rather than a fixed rewrite price on day one?
- Will everything sit in accounts you own: repository, hosting, domain, app stores?
- Will they write things down, so you are never in this position again?
- Do they run production software themselves? Building and running are different skills. Someone who has been paged on a Friday night thinks differently about backups.
Do the same company checks you would do for any supplier. Our guide to checking a UK software supplier covers what Companies House and a few direct questions will tell you. And read every supplier looks the same until you try to leave before you sign, so the next handover is a formality rather than a rescue.
What this looks like when we do it
When a business asks us to take over a system, we start with access and a written review, not a rewrite quote. We tell you what we found, what we would keep, and what we would change first. After that, work runs on fixed scope or a monthly retainer, agreed in writing before it starts. Code, infrastructure and documentation stay in your name. If the honest answer is that your current system is fine and just needs looking after, we will say that.
FAQ
Can a new developer take over a project they did not build?
Yes, if they can get the code, the accounts and a working build. The first few weeks go on understanding and stabilising the system rather than adding features. A developer who promises big changes in week one has not looked closely enough yet.
Should we rebuild our software when our developer leaves?
Not automatically. Secure and stabilise it first, then get a written review. Rebuild only when the evidence shows the core logic, stack or data model is holding the business back, and even then do it in phases beside the old system.
What if the old developer will not hand over the code?
Check your contract and whether code ownership was assigned to your company in writing, and take legal advice before building on top of it. Meanwhile, secure every account you do control, especially the domain, hosting and payment provider.
How long does a software rescue take?
It depends on the system. Getting a stable, understood baseline with backups, deployments and monitoring in place is usually a matter of weeks, not months. What comes after depends on the review.
What should we prepare before talking to a new developer?
A list of every account and who controls it, any contract with the previous developer, whatever documentation exists, and a plain description of what the system does for your business day to day. That is enough for a useful first conversation.
The short version
When your developer disappears, do not start with a rewrite. Secure every account and copy of the code. Prove the system builds, deploys, backs up and alerts. Get a written review that talks about business risk, not code style. Then keep, refactor or rebuild in phases, based on what the review found. Keep it all in accounts you own, so the next handover is routine.
Inherited a system nobody can change? Book a 30-minute discovery call and walk us through how an order, job or request moves through it today. We will tell you what we would secure first, what a review would cover, and whether it looks like a keep or a rebuild. You can also see what we've built or get in touch by email.
Related reading: You paid for it. In most countries, that doesn't mean you own it. · Every supplier looks the same until you try to leave · Their portfolio is curated. Their filing history isn't. · Offshore isn't the risk. An unclear brief is.
