What does app maintenance actually include each month?
Dependency and security updates applied and tested, uptime monitoring with alerts to us, a backup check, fixes and small features within the month's hours, platform upgrades on the plans that include them, and a month-end report of what shipped, what was patched and the hours used. Plans and prices are on our maintenance plans page; the work itself is the same list every month. What changes between plans is how many hours there are for your requests and how quickly a critical issue is answered.
How many hours of maintenance does an app need each month?
It depends on how much changes around the app and how much you want to change in it. An app with few users and no new features needs a few hours for updates and checks (our maintenance cost calculator gives a first estimate). One that is growing, with requests every week, needs more. Our maintenance cost calculator gives a starting estimate, and the first month's health check tells us both what is realistic. If the hours turn out wrong in either direction, you can move plans from the next month after the minimum term.
What happens in the first month of maintaining an app built by someone else?
It starts with a code audit, so we both know what is being maintained. Then onboarding: access to the code, servers and store accounts, monitoring set up, and a health check of the code and its dependencies. Anything urgent the audit finds is fixed first. The normal monthly rhythm starts once the floor is solid.
What happens when Google or Apple change their requirements?
We see it coming. Platform dates live on our calendar, so a target API change or a new store requirement is planned months ahead, tested on a copy and released before the cut-off. You hear about it in the monthly report as a line item, not as an urgent email the week before. When a change needs more than the month's hours, such as a large SDK upgrade, we estimate it separately and agree it with you first.
How do we ask for a fix or a small feature?
Write it down in one line on the shared board, or send it and we will put it there. We give it a priority level, agree it with you, and it moves across the board from inbox to shipped. If it is bigger than the month's hours allow, we say so and estimate it separately before anything starts. You can see every request's status on the board at any time, without having to ask.
What if something breaks at night or over the weekend?
Alerts reach us at any hour, but we answer in Indian working hours; we do not offer round-the-clock on-call cover. For the worst cases, the runbook for your product explains how to roll back the last release, which is the most common fix. If your product needs night cover, we will tell you honestly and help you find it. Either way, anything that happened overnight is the first thing we look at the next working morning.
Why update dependencies if the app works fine today?
Because the cost of an update grows with the gap. A library one version behind is a small change; five versions behind is a project, often with forced code changes, as the Flying Pup clean-up showed. Security fixes also only exist for current versions, so falling behind eventually means running known vulnerabilities with no patch available. Small monthly steps are also easier to test, and easier to roll back if one of them misbehaves.
Can maintenance cover our website and admin console as well as the app?
Yes. Most products are several pieces: a mobile app, a backend, an admin console and a website. Maintenance covers whichever of them you choose, with the same monthly list for each, and the report shows the hours by piece so you can see where the effort goes. The servers they run on can be included too, with security updates and backup checks on the same monthly rhythm.
