App maintenance when your original developer has gone.

Yes, and it is most of this work. The condition is an audit first: we read the codebase, the dependencies and the store status before quoting anything, because a monthly figure quoted against an unopened repository is a guess that one side pays for. The audit also establishes what you can still sign into, which matters more than the code quality does. If it turns out the app is in reasonable shape and needs three days a quarter rather than a retainer, that is what the audit will say.

Because the warning is about availability, not about function. Google Play requires a published app to target a recent Android version to stay available to new users on newer devices, and the requirement moves on a published date: from 31 August 2026 a new release must target Android 16, and an already-published app must target Android 15 to keep reaching those users. Apps below the line are not removed and existing users notice nothing at all. What changes is that new installs quietly stop, which is why this is usually diagnosed as a marketing problem first.

You should, and if you do not, getting them back is the first piece of work rather than an obstacle to it. The common case is a listing published under a former developer’s personal account, which means nobody at the company can add a build regardless of who holds the source code. Sometimes that is recoverable through the platform’s own process; sometimes the honest answer is republishing under an account you own, which has consequences for reviews and install counts that we set out before you decide. Either way it is established in week one, not week nine.

It is not a percentage, and the widely repeated figure for one has no source behind it. What a maintenance arrangement costs follows what it covers: how many platforms, whether the target floor and declarations are your responsibility or ours, how quickly something urgent has to be answered, and whether small feature work is inside the arrangement or quoted separately. We scope those four before quoting, which is also why the audit comes first. A number produced without them is a number one side will regret.

The app has already run against it, because platform previews are available for months beforehand. Running the app during that window is what turns an operating-system release from an incident into a scheduled change, and it is separate from the store floor question: one is about the app breaking, the other about the app being installable. Both are on published calendars. The work is booked against those dates rather than triggered by a user complaint or a console banner.

Yes, and it is usually cleaner than two suppliers, because most of what maintenance actually does is common to both: dependency patching, monitoring, the release process and the calendar of platform dates. The parts that differ are the two consoles and the two sets of requirements, which is work that benefits from one team seeing both. Where you currently have two suppliers, expect the first month to include reconciling two release processes that have quietly drifted apart.

Yes, and the size of the job depends entirely on how the original build handled layout. If the interface was written with directional layout in mind, adding Arabic is a translation plus a testing pass. If it was written with fixed left and right positioning, it is a revisit of every screen, and that is a project rather than a maintenance item. We run a directional audit first so the answer is a number rather than an estimate, and where it is the second case we say so plainly instead of starting and discovering it.