Launch day feels like the finish line. For your software it is closer to the starting gun. From the moment real people use it, the world around it keeps changing: phones update, browsers change, services you depend on retire old versions, and security researchers publish new vulnerabilities. Software that nobody maintains does not stay the same. It decays.
This guide explains what maintenance covers, how to budget for it and how to choose a support plan that protects what you have built.
Four kinds of maintenance
Software engineers group maintenance into four categories, and a good support plan covers all of them.
- Corrective: fixing bugs your users find, and the ones monitoring catches before users notice.
- Adaptive: keeping the software working as its environment changes, from new iOS and Android versions to updated payment gateway APIs.
- Preventive: reducing future problems by updating dependencies, improving test coverage and cleaning up code that has become fragile.
- Perfective: improving what already works, such as faster pages, clearer screens and small features your users ask for.
Most businesses budget only for the first kind and are then surprised by the other three.
What keeps changing around your software
Your code might not change for months, but everything it touches will.
Operating systems. Apple ships a major iOS release every year, and Google releases a new Android version on a similar cycle. Each can change permissions, background behaviour or interface rules. Google Play also requires apps to target a recent Android version to keep publishing updates.
Browsers. Chrome, Safari, Firefox and Edge update every few weeks. Most changes are harmless, but some affect cookies, storage or layout.
Dependencies. Modern software is built on hundreds of open-source libraries. New versions arrive constantly, and some fix security holes that attackers start exploiting within days of publication.
Third-party services. Payment providers, mapping services, messaging platforms and AI model providers retire old API versions on a schedule. When they do, anything still using the old version stops working.
Certificates and credentials. SSL certificates, API keys and signing certificates expire. An expired certificate can take a site or an app offline without any change to the code.
What a support plan should include
A support plan turns maintenance from emergency spending into a predictable monthly cost. Look for these elements:
| Element | What it means in practice |
|---|---|
| Monitoring | Uptime checks, error tracking and alerts, watched by a named team |
| Response times | Agreed targets for acknowledging and fixing issues, by severity |
| Security updates | Regular dependency updates and patching when a vulnerability affects you |
| Platform updates | Testing against new iOS, Android and browser versions before they reach your users |
| Backups | Automated backups, plus restores tested on a schedule |
| Improvement time | A monthly block of hours for small enhancements |
| Reporting | A monthly summary of incidents, updates and the health of the system |
Response times deserve close reading. A plan might promise to acknowledge a critical issue within an hour but say nothing about fixing it. Ask for both, and ask what counts as critical.
Budgeting for maintenance
A common planning figure is 15 to 20 per cent of the original build cost per year. Simple websites need less. Complex platforms with many integrations, mobile apps on both stores and systems handling sensitive data need more.
Treat that figure as a starting point, and adjust for these factors:
- Integrations. Each external service is another thing that changes without asking you.
- Mobile apps. Yearly OS releases add adaptive work that web-only products avoid.
- Regulation. Health, finance and personal data raise the bar for security updates and audits.
- Rate of change. If you plan to keep adding features, budget for development on top of maintenance.
Skip the budget and you still pay, later and in a hurry, when something breaks during your busiest week.
Choosing a plan
Ask any prospective support provider these questions:
- Who will look after our system, and have they worked on it before?
- How do we report an issue, and how quickly will someone respond out of hours?
- How do you decide what to update, and how do you test updates before they go live?
- What happens to unused improvement hours each month?
- Who holds the accounts, credentials and code? (The answer should be you.)
The team that built your software usually maintains it most efficiently, because they already understand its structure. That advantage only holds if the code is well documented, so ask for documentation regardless of who supports it.
Keep the keys in your hands
Maintenance goes wrong fastest when nobody on your side can reach the systems. Whoever supports your software, make sure your company holds these directly:
- The code repositories, with your own administrator account.
- Cloud and hosting accounts, registered to your company, with billing in your name.
- Domain names and DNS, which control whether anyone can reach your site at all.
- App store developer accounts for Apple and Google.
- Credentials for third-party services, stored in a password manager your company controls.
- Documentation: how to deploy, how to restore a backup and who to call when something breaks.
With these in place, you can change support providers without losing access to your own product, and a new team can take over in days instead of months.
Signs your software needs attention
If you recognise these, maintenance has fallen behind:
- Your team avoids updating anything because "it might break".
- Pages or screens have become noticeably slower over the past year.
- Security scans or app store reviews flag outdated libraries.
- Nobody on your side knows where the code lives or who can deploy it.
- Small changes take weeks because every change breaks something else.
Each of these is fixable. The sooner you start, the cheaper the fix.
Planning for the long run
Every project we build can continue on a support plan run by the team that built it, covering monitoring, security, platform updates and a monthly block of improvements. If you have software that needs a home after launch, or an existing system that has drifted, get in touch. For the bigger picture on budgets, see our guide to what custom software costs.
Written by the engineering team at Aventra Global LLC, Dubai.