What technical support for an app includes
Support for an app is not just "fixing bugs." It covers several areas: fixing errors that surface in real usage; updates for new versions of iOS, Android and browsers, otherwise the app eventually stops launching; infrastructure upkeep and availability monitoring; dependency updates and closing vulnerabilities; small improvements and feature development. The first three are the bare minimum just to keep the product running; the rest is about keeping it competitive.
Maintenance models: hourly, SLA and retainer
There are three common models. Hourly (Time & Material) - you pay for actual hours, convenient when tasks are rare and unpredictable. SLA - a service-level agreement with a guaranteed incident response time, needed when downtime is critical. Retainer - a fixed monthly package of hours for support and minor changes, the most budget-predictable option for a live product. The choice depends on how critical downtime is for you and how often changes are planned.
How much to budget for support
The reference the market uses is roughly 10-20% of the development cost per year for support and evolution. The exact figure depends on complexity: an app with payments, integrations and high load costs more to maintain than a simple catalog. It is important to plan this budget in advance, at the development estimate stage, rather than being surprised by it after release. This is an indicative range - the specific cost is always calculated for your product and the required service level.
What happens if you do not maintain the app
A product without support does not stay in the same state - it degrades. First minor failures accumulate, then a new OS version ships and some users lose access, then an unpatched vulnerability surfaces. Dependencies are a separate problem: libraries age, and in a year or two updating the app becomes more expensive than maintaining it gradually all along. Saving on maintenance almost always turns into a costlier one-off rework.
How to hand a product over for support without losing control
For transparent support you should hold the source code, access to the infrastructure and accounts, and documentation. Then the product can be maintained by the original team or any other - you are not tied to one contractor. We hand over the code and infrastructure to the client in full, so support does not become dependency: you pay for the work, not for someone else holding the keys to your product.