The Orphaned App Playbook
Your developer has stopped replying and your app is still running your business. What to do this week, how to get your accounts back, and what a takeover actually involves.
Contents7 sections
The messages went from same-day to next-week to nothing. Your booking system, or your shop, or the app your customers use, is still running perfectly well — and there is now nobody who can change it, and nobody who can tell you what would happen if it stopped. This page is what to do about that, in order, starting with the part that is time-sensitive.
What should you do this week?
Five steps, in this order
Write down everything your system touches
The website address, the app listings, the place the code is stored, the hosting, the database, the payment provider, the email sender, any text-message or mapping service. You do not need to understand them. You need the list, because the list is what a new firm will ask for and what you are about to take ownership of.
Find out whose name each account is in
Log in where you can. For anything you cannot get into, note who set it up. The usual pattern is that a few are in your company's name and the rest are in the developer's, and the ones in their name are the urgent ones.
Secure the domain name first
It is the single most valuable item and the easiest to lose. Log in to the registrar, confirm the renewal date, make sure the payment card on file is yours and current, and change the contact email to one you control. If the domain is in the developer's account, contact the registrar directly — most have a documented dispute process for exactly this.
Get your own copy of the code
If you can reach the repository, download a copy today, even if you cannot read a line of it. If you cannot reach it, your contract almost certainly says the work is yours; a short, factual letter citing the clause resolves this far more often than people expect.
Write one last clear message
Not a complaint. A short list: transfer these accounts, send the code, confirm where the live system runs. Give a date. Keep it in writing. A surprising number of silent developers respond to a specific, unemotional request when they have been ignoring general ones.
Why will nobody take it on?
Because taking responsibility for software someone else wrote means taking responsibility for problems you cannot see yet, usually at a fixed price, for a client who is understandably impatient. Most firms would rather sell you a rebuild, which is easier to price, easier to deliver and much more expensive for you.
That is the honest explanation for the wall of polite refusals. It is also why the firms that will do it work in two stages: a paid period of reading the system and writing down what is in it, and only then a price for looking after it. A fixed maintenance quote offered before anyone has read the code is either padded heavily or about to become a change order. How to choose a development partner covers what else to ask before signing.
What does a takeover audit involve?
Someone reads the system and produces a written description of it. That description is the thing you are actually buying, and you keep it whether or not you continue with the firm that wrote it.
| What gets looked at | What you get in writing |
|---|---|
| How the system is built and what the parts are | A plain-English description of the pieces and how they fit together |
| Which outside services it depends on | A list, with who pays for each and what happens if one stops |
| Whether it is up to date with Apple's and Google's requirements | A dated list of what is compliant now and what expires when |
| Security of customer data | Findings ranked by severity, each with an estimate to fix |
| Whether anyone but the original developer can release a change | A written, repeatable release process |
| What would break first under load or after an operating-system update | The known risks, and which are worth pre-empting |
Which deadlines are already on the calendar?
An unmaintained app does not fail loudly. It falls out of circulation, and the two mechanisms below are the usual cause. Both are published by the platform owners and both are dated — and if you are choosing someone to keep on top of them, the mobile agency shortlist compares firms on exactly that.
| Platform | Requirement | Date | What happens |
|---|---|---|---|
| Apple App Store | Every upload must be built with Xcode 26 or later, against an iOS 26 SDK | 28 April 2026 | Older builds are rejected — you cannot publish an update at all |
| Google Play | Existing apps must target API 35 or higher to stay available to new users on newer devices | 31 Aug 2026, extension to 1 Nov 2026 | The app is not deleted. It stops being visible to new users on current phones |
What should maintenance cost?
The figure everyone quotes is 15 to 20 per cent of the original build cost per year. Treat it as a convention rather than a finding — it is repeated everywhere and traces to no single study. What is better attributed is the bigger picture: published estimates put maintenance at somewhere between two-thirds and over ninety per cent of a system's total lifetime cost, which is the number worth planning around.
What a maintenance arrangement should actually cover
- Keeping up with Apple's and Google's yearly requirements, before the deadline rather than after
- Security updates to the underlying components, which is most of the invisible work
- A named response time for something being broken, and a different one for something being wanted
- An agreed amount of small-change time each month, so minor requests do not each become a negotiation
- Somewhere you can see what was done, without having to ask
Common questions
Can anyone really maintain software they did not write?
Yes, and it is ordinary work — but only after a paid period of reading it properly. The firms that refuse are usually refusing to quote a fixed price on an unknown, which is reasonable. The two-stage approach exists precisely to make this possible: read first, price second.
My developer says the code is theirs. Is it?
Usually not, if you paid for it under a contract that says so — but the wording matters and it varies. Find the agreement and look for assignment or work-for-hire language. If there is no written contract at all, the position is more complicated and worth an hour of a solicitor's time before you spend anything else.
Should I just have it rebuilt?
Very rarely as a first move, and be cautious of anyone who opens with it. A working system that your customers already use is worth a great deal, and a rebuild throws away everything the original learned about how your business actually operates. Get it read first; the reading costs a fraction of the rebuild and often makes it unnecessary.
How do I stop this happening again?
Own every account in the company's name, hold your own copy of the code, and insist that more than one person can release a change. Those three make the next transition ordinary instead of a crisis, and none of them costs anything to arrange at the start.
How urgent is this really?
The accounts are urgent this week. The code and the maintenance arrangement can take a few weeks without harm. The platform deadlines above are the thing to work backwards from — if a release is required by a fixed date, you need someone reading the system well before it.
The short of it
Secure the domain and the accounts this week. Get your own copy of the code. Then pay someone to read the system and write down what is in it, and make the first deliverable a release process that works without the person who built it. That sequence turns an emergency into a piece of ordinary business.
