If your developer disappeared or left you with code nobody wants to touch, the way out is a rescue in four steps: recover your code and accounts, get the app assessed by a developer, stabilise what’s broken, then continue building on solid ground. You do not need to read code to get through this, and you usually do not need to rebuild from scratch. What you need is ownership of your own assets and one honest technical assessment — everything else follows from those two things.
First: secure what is yours
Before any technical work, get control of the assets. Work through this list today, even if some items are out of reach:
- The code. Is it in a repository (GitHub, GitLab, Bitbucket) you can log into? If it only exists on the developer’s machine, request a copy in writing.
- The hosting and domain. The servers the app runs on and the domain name should be in accounts you own — not the developer’s.
- App store accounts. For mobile apps, the Apple and Google accounts the app is published under. If the app was published under the developer’s account, users’ updates depend on someone you can’t reach.
- Third-party services. Payment providers, email services, databases, analytics — anything the app talks to.
If the developer is unreachable and holds any of these, contact the providers directly. With proof of payment and business ownership, hosting companies, registrars and app stores have processes to transfer control. It is slower than asking the developer, but it works.
Second: get the app assessed — not rebuilt
The most expensive mistake owners make at this point is hiring the first developer who says “this is terrible, we should rebuild it.” Sometimes that is true. But a rebuild quote before anyone has read the code is a sales pitch, not a diagnosis.
A proper assessment is a short, fixed piece of work, usually a few days, where a developer reads the code, tries to run it, and writes you a plain-language report: what exists, what actually works, what is risky, and what the realistic options cost. In our experience the report changes the owner’s plan more often than not: apps that “feel” broken often mostly work, and the fastest path is stabilising what is there.
An assessment also protects you in the other direction. If the code genuinely is beyond saving (an abandoned framework, no safe way to update anything, fixes that break two things for every one they repair), the report gives you the evidence, and the rebuild decision is yours instead of a stranger’s.
Fix or rebuild? How to decide
There is no universal answer, but the pattern is fairly consistent:
| Signal | Points to |
|---|---|
| The app runs and has real users | Fix — working software is worth more than clean software |
| Bugs are annoying but predictable | Fix — stabilise, then improve |
| The framework or platform is abandoned | Rebuild — you can’t patch a dead foundation |
| Every fix breaks something else | Assess deeper — this can go either way |
| The developer left no repository history | Careful — the real risk is what you can’t see |
A rebuild throws away every lesson the old code already paid for — all the edge cases fixed over the years disappear with it. That is why, in our experience, fixing wins more often than owners expect. But when foundations are wrong, patching them is the expensive path. The assessment exists to tell you which case you’re in.
Third: stabilise before you build
Rescues fail when new features get built on top of broken foundations. The boring order is the one that works:
- Safety first — backups exist and restore, security holes are closed, crashes are caught and visible.
- Understanding second — the new developer documents what they found, so knowledge stops living in one head.
- New work last — only once the app is stable does new development make sense.
This is also the honest test of whoever you hire for the rescue: a developer who starts with monitoring, backups and documentation is planning for your continuity. One who starts with a redesign is planning for their invoice.
What this looks like when it’s done properly
The end state of a good rescue is simple to describe: the app runs, you own every account, the code lives in a repository in your name with its history intact, there is documentation a new developer could follow, and production is monitored so problems are seen before users report them. That end state is how we run software at Givore Studio — it’s the same setup we use for Givore, the community app with ~10k users that we built and still run end to end — and it is what you should demand from anyone who takes over your app, including us. A rescue done properly fixes more than the app: it makes sure nobody can leave you stranded like that again.
If you’re in this situation now, the next step is small: a short assessment, honest numbers, and a plan you can take anywhere. What to ask before hiring helps you vet whoever you talk to — including us. And if you want the maintenance side explained, how much it costs to keep an app running covers the numbers nobody quotes upfront.