Business software 7 min read
Maintenance and support costs after a software launch
What drives the cost of keeping software secure and working after launch, and how to choose a support arrangement that fits.
On this page
Software maintenance cost is what you spend after launch to keep a system secure, working and useful: fixing bugs, applying security updates, hosting and monitoring, and supporting the people who use it. It is separate from building new features, although the two are often bundled together. We will not quote prices here, because they depend on the system and the provider. Instead, this guide explains what drives the cost and how to choose a support arrangement that fits.
Maintenance is easy to overlook when planning a new system, because it only starts once the system is live. Budgeting for it from the beginning avoids hard choices later. If you would like help with an existing or planned system, our custom software service page explains how we work.
Why software needs ongoing maintenance
Software that is left alone does not stay the same. The world around it changes.
- Security fixes are released for frameworks, libraries and server software, and must be applied.
- Supported versions end. Frameworks and languages publish support timelines, after which versions stop receiving fixes.
- Other systems change. Payment gateways, supplier APIs and email services update how they work.
- Data grows, and queries or screens that were fast at launch can slow down.
- Users find problems that testing did not reveal.
- The business changes, and rules or processes in the system need updating.
A worked example
A booking system launches on a supported framework version and runs well for two years without updates. Then its payment gateway announces the retirement of an older API, and the framework version has left its security support period. Now the gateway change requires a framework upgrade first, turning a small task into a larger project. Regular maintenance would have kept both steps small.
Integrations are a regular source of maintenance work because other services change, and our guide to business software integration explains how to plan for failures.
Bug fixes and security updates
These are the core of any maintenance budget.
What drives the effort
- The size and complexity of the system, including the number of features and integrations.
- The quality of the code and tests. Well-tested code is quicker and safer to update.
- The number of third-party packages, each of which receives its own updates.
- How far behind the system is. Regular small updates cost less than rare large ones.
- How urgent fixes need to be, since faster response times usually cost more.
Steps in a healthy update routine
- Check for security advisories and new versions regularly.
- Apply updates on a staging copy first.
- Run automated tests and check key journeys.
- Deploy with a way to roll back if something goes wrong.
- Record what was updated and when.
Hosting and monitoring
Running costs continue for as long as the system is live.
| Item | What it covers | What changes the cost |
|---|---|---|
| Hosting | Servers, databases and storage | Traffic, data volume and performance needs |
| Backups | Regular copies and tested restores | Frequency, retention period and storage location |
| Monitoring | Uptime, errors and performance alerts | Number of checks and who responds |
| Third-party services | Email, SMS, maps, payment and supplier fees | Usage volumes and provider pricing |
| Licences | Paid libraries, tools or plugins | Number of users, sites or renewals |
A common mistake and its fix
A common mistake is paying for hosting and assuming it includes backups, monitoring and security updates. Often it does not, or only partly. The fix is to list each item in the table above and confirm in writing who provides it.
New features vs maintenance
Keeping maintenance separate from new work makes budgets clearer and protects the system.
- Maintenance keeps the existing system secure and working: updates, fixes, monitoring and support.
- Improvements change or extend what the system does: new features, new reports, new integrations.
- Budget them separately, so improvements never crowd out essential updates.
- Review improvements regularly with the people who use the system, and prioritise the ones with the clearest benefit.
Questions to ask when a request comes in
- Is this fixing something that does not work as agreed, or changing what the system does?
- Is it urgent because of security, money or customers, or can it wait for the next planning cycle?
- What would it cost to leave it as it is for now?
Choosing a support arrangement
Support can be arranged in several ways. The right one depends on how critical the system is and how often it changes.
| Arrangement | How it works | Best for |
|---|---|---|
| Pay as you go | Work is quoted or billed when needed | Small, stable systems with rare changes |
| Monthly retainer | A set amount of time each month for maintenance and small changes | Systems that need regular care and occasional improvements |
| Service agreement with response times | Defined response times for issues, often by severity | Business-critical systems |
| In-house developer plus external support | Your developer handles daily work; a partner provides depth and cover | Larger systems with constant change |
Checklist for any agreement
- What is included: updates, fixes, monitoring, backups, support.
- Response times for urgent and non-urgent issues.
- How unused time is handled, if time is included.
- How improvements are quoted and approved.
- Who owns the code, hosting and accounts.
- How the arrangement ends and how handover works.
How to get an accurate maintenance quote
A provider can only price maintenance accurately once they understand the system. Expect the work to happen in phases:
- An onboarding review. The provider checks the code, versions, tests, hosting, backups and integrations, and lists anything urgent.
- Catching up. Any overdue updates or urgent fixes found in the review are quoted separately.
- Routine maintenance. Regular updates, monitoring and support under the agreed arrangement.
- Improvements. New work quoted and approved as it comes up.
What to share with a provider
- Access to the code repository and a description of how the system is deployed.
- The framework, language and hosting in use, with their versions.
- The list of integrations and third-party services.
- How critical the system is, and when it is used most.
- Known problems and planned changes.
A quote based on an onboarding review is far more reliable than one based on a short description.
Maintenance is easier to plan when the system was well scoped from the start. Our guides on how to roll out new software to your team and how to write software requirements cover the earlier stages.
Summary
- Software needs ongoing care because security fixes, supported versions, connected systems and data all change.
- Bug fixes and security updates are the core of maintenance; regular small updates cost less than rare large ones.
- Budget for hosting, backups, monitoring, third-party services and licences, and confirm who provides each.
- Keep maintenance separate from new features so essential updates are never squeezed out.
- Choose a support arrangement that matches how critical the system is, with clear scope and response times.
Planned maintenance keeps a system reliable and avoids expensive surprises. If you'd like to discuss maintenance for your software, you can tell us about it here.
