Mobile Development
Maintenance & Updates
Ongoing care for an app that is already live — crash fixes, OS updates, store rule changes and a clear record of what changed.
What this actually is
Apps rot if left alone. OS updates, new device sizes and store rules all arrive whether you are ready or not.
Both platforms ship major OS releases on a regular schedule, and each one quietly breaks something — a permission that now needs asking twice, a layout that no longer fits, a library that stops being allowed. New phone sizes arrive. Store policies tighten. None of this waits for your roadmap, and none of it announces itself until a user leaves a one-star review.
Maintenance is a standing arrangement, not a series of emergencies. We watch crash reports and store reviews, fix what is breaking, keep dependencies and SDK targets current before the deadline rather than after it, and ship on a predictable cadence. Each cycle ends with a plain summary: what changed, what it cost, what is queued next. No jargon, no surprise invoice.
How we work
Four steps, in this order.
Watch
Track crashes and reviews so problems surface before they spread.
Patch
Fix and ship on a predictable cadence rather than in a panic.
Keep current
Stay ahead of OS releases and changing store requirements.
Report
A plain summary each cycle of what changed and what it cost.
What you get
Every engagement hands over these.
- A monitored app with crash reporting and review alerts wired up
- Scheduled store releases keeping OS and SDK targets current
- A plain-language report each cycle covering changes, crashes and cost
- A prioritised backlog of known issues and deferred work
Who it’s for
This is usually the right fit when…
- Your app is live, the team that built it has moved on, and nobody is watching it.
- Reviews are slipping and you suspect crashes, but you have no idea where or how often.
- You got a store warning about an SDK or policy deadline and cannot act on it.
Questions
The things people ask before starting.
We have no new features planned. Do we still need this?
Yes, and this is exactly the case people get wrong. Maintenance is not feature work — it is keeping a working app working while the ground moves. Stop entirely and the app degrades quietly: crashes on new phones, rejected updates, eventually removal from a store for an out-of-date target. Restarting from that point costs far more than never stopping.
Will you maintain an app your team did not build?
Usually. We start with a read of the codebase and an honest verdict — some apps are in good shape and just need attention, others are held together badly enough that maintaining them costs more than replacing them. You get that assessment either way, including the uncomfortable version. We would rather say it early than bill you for it slowly.
What counts as maintenance and what counts as a new project?
Anything that keeps the current app working is maintenance: crash fixes, OS and SDK updates, store compliance, small copy and layout corrections. Anything that adds a screen, a flow or an integration is new work, quoted separately. We draw that line in writing at the start so neither side is arguing about it later.
Can we stop whenever we want?
Yes. Maintenance runs on a rolling arrangement with a notice period, not a lock-in. When it ends you keep the repository, the accounts, the monitoring setup and the release runbook — everything needed for another team to pick it up. We do not hold anything back as leverage. That is not a service, it is a hostage situation.
Have a project in mind?
Tell us about your project, study or idea — and let's see what's possible.
Get in touch