The most common misunderstanding about apps is that they are finished at launch, like a printed brochure. They are not. An app lives on platforms that change every year, depends on libraries that release security fixes, runs on servers that need care, and serves users who will find things nobody tested. An app left alone for a year or two often needs substantial work before it can even be updated again.
This post explains what maintenance really covers, so you can plan for it instead of being surprised. It applies to the mobile apps, web apps and backends I build and run, such as Pro Clean+ and NeonTask.
Why apps need maintenance at all
Even if you never add a feature, the world around the app changes:
- Apple and Google release new OS versions every year. Some change how permissions, notifications, background work or layouts behave.
- The stores raise their requirements. Both require apps to be built against recent SDK versions to publish updates. An old app may be blocked from updating until it is modernized.
- Libraries get security fixes and new versions. Old versions stop being supported, and eventually stop working with new tools.
- Servers need patches. Operating systems, databases and runtimes all get security updates.
- Certificates, keys and accounts expire. Push notification keys, signing certificates, domain renewals and developer memberships.
- Third-party APIs change. Maps, SMS, payment and email providers update or retire API versions.
None of this is optional. Ignoring it does not save money; it defers the cost and adds interest.
What maintenance covers
Mobile apps
- Testing on each new iOS and Android release, ideally during the beta period, and fixing what breaks.
- Updating React Native and native dependencies regularly, in small steps.
- Rebuilding and resubmitting to meet new store requirements.
- Monitoring crash reports and fixing new crashes.
- Keeping store listings, screenshots and privacy declarations accurate.
- Renewing developer memberships and certificates.
Web apps and websites
- Updating frameworks and packages, such as Next.js, React and their dependencies, with attention to security advisories.
- For WordPress sites: core, plugin and theme updates, tested so they do not break the layout.
- Checking performance and fixing regressions.
- Browser compatibility as browsers update.
Backend and servers
- Operating system and security updates.
- Database maintenance and version upgrades.
- Backup checks and periodic restore tests. See Postgres backups that actually restore.
- Monitoring and responding to alerts. See monitoring and alerts for a small product.
- Disk cleanup, log rotation and capacity planning.
- Renewing domains and checking TLS certificates.
Bug fixes and small improvements
Real users find real bugs. Maintenance should include fixing them, along with small adjustments, such as reworded labels, an extra filter or a tweak to a report, that do not count as new features.
Handling the first weeks
The weeks right after launch deserve their own plan. This is when real usage reveals confusing screens, missing edge cases and assumptions that did not match how staff actually work. Expect more fixes in this period than later, review crash reports and support messages daily, and batch non-urgent improvements into a planned update instead of releasing every small change separately.
What maintenance does not cover
It helps to separate maintenance from new development. New features, redesigns and integrations with new services are projects of their own, scoped and priced separately. Mixing them into a maintenance arrangement leads to disagreements about what is included.
How to approach the budget
I will not quote figures, because they depend on the size of the system. What drives the effort:
- Number of moving parts: one website is simple; a mobile app on both stores plus a web admin plus an API plus a database is several systems.
- How many third-party integrations it relies on.
- How often the business needs changes.
- Expected response times. A booking system that must be fixed within hours needs a different arrangement from a brochure site that can wait a day.
- How healthy the code is. A codebase with tests, a CI/CD pipeline and up-to-date dependencies is much cheaper to maintain than one that has been neglected.
Common ways to structure it:
- A monthly retainer covering a defined scope: updates, monitoring, a set amount of fixes, with a response time.
- Scheduled maintenance windows, for example a quarterly update cycle, plus pay-as-you-go for urgent fixes.
- In-house, if you have a technical team, with the original developer available for handover and questions.
Whichever you choose, agree on it before launch.
The cost of skipping it
The pattern I see when picking up neglected apps:
- The app works, so nobody touches it for a long time.
- The business wants a small change, or the store requires an update.
- The project no longer builds with current tools. Dependencies are several major versions behind, some are abandoned, and the store rejects the old SDK.
- A small change becomes a modernization project before any visible work can start.
Small, regular updates avoid this. Updating dependencies a little at a time is routine; updating years of them at once is a project. If you are in that situation now, a short audit helps decide whether to modernize or rebuild. See taking over an inherited codebase.
How good engineering reduces maintenance
Some decisions made during the build make maintenance cheaper for years:
- One codebase for both platforms, such as React Native, means OS updates and fixes are handled once. See React Native vs native.
- Automated builds and deployments through CI/CD make releasing an update routine rather than an event.
- Dockerized services make server upgrades and moves predictable.
- Monitoring and error tracking mean problems are found early.
- Tests on critical logic let updates proceed with confidence.
- Documentation and a runbook mean anyone can pick it up.
Questions to ask your developer before launch
- What maintenance does the app need in the first year?
- Who renews the accounts, keys and certificates, and when do they expire?
- How are dependency and OS updates handled?
- What is the response time for critical issues?
- Where is the documentation, and who has access to the code and servers?
An app is an ongoing service to your customers. Treating maintenance as part of owning it keeps it reliable, secure and ready for the next improvement.
If you need someone to maintain an existing app or plan maintenance for a new one, see my work and get in touch.