Software maintenance and support, on written terms
Your software keeps running, up to date and improving.
Software maintenance and support services keep an application running, secure and useful after launch: fixing faults, adapting it to changes around it and improving it as your business changes. This page covers the types of maintenance, how to read a software SLA before signing, retainer versus hours, and how taking over software or switching supplier should work.
If any of these sound familiar, we can help.
- 01Nobody looks after the software once it's live.
- 02Pending security updates.
- 03Improvements piling up with no date set.
What's included
We agree the exact scope with you in the proposal.- Any sector
- Software in production
- Portals
- Apps
- 01
Support
With response times in writing.
- 02
Updates
Security and dependencies up to date.
- 03
Monitoring
We know something's wrong before you do.
- 04
Improvement hours
Hours for new features.
Maintenance and evolution of a customer portal that is already in use.
It could include a monthly review of priorities and a report on the work done, with the terms in writing.
Corrective, adaptive, perfective and preventive maintenance
Software engineering has long split maintenance into corrective, adaptive and perfective work, and the international standard ISO/IEC/IEEE 14764 adds a fourth type, preventive, as the IEEE's SWEBOK guide explains. A support contract usually mixes all four, so check which ones yours actually covers:
| Type | What it is | Example |
|---|---|---|
| Corrective | Fixing faults found in use | A report that adds up wrongly when an order has returns |
| Adaptive | Keeping the software usable as its surroundings change, without changing what it does | Your ERP changes its API, or an app store demands a newer system version |
| Perfective | Improving the software or adding features for users | A new type of user, a new report or another integration |
| Preventive | Finding and fixing latent problems before they cause failures | Updating vulnerable dependencies, testing backup restores, watching disk space |
Why software that works still needs maintenance
Software does not wear out, but everything around it changes. Adaptive maintenance is the type most often forgotten, and mobile apps show it clearly. According to Google, from 31 August 2026 new apps and updates submitted to Google Play must target Android 16 (API level 36). According to Apple, since 28 April 2026 everything uploaded to App Store Connect must be built with Xcode 26 and the iOS 26 SDK. If nobody keeps the app current, the day you need an urgent fix you first have to bring the whole project up to date.
Security has deadlines too. If your company holds or is working towards Cyber Essentials, IASME's guidance says updates must be applied within 14 days when the vendor rates the vulnerability critical or high risk, or it scores 7 or more on CVSS v3. That applies to the libraries and servers behind your software as much as to office laptops.
How to read a software SLA before you sign
The service level agreement (SLA) is the part of a software support contract that says how quickly, and on what terms, each problem is handled. There are no universal figures: reasonable times depend on how critical your software is. What matters is that they are in writing and that you understand them. Check these points:
- Severity levels: what counts as critical (the system is down), high (an important function fails with no workaround) and what can wait.
- Response time versus resolution time: responding means someone starts work; resolving means it is fixed. Many contracts only commit to the first.
- Hours of cover: working hours, extended or every day. A four-hour response in working hours does not cover Friday night. If the supplier is in another time zone, check the hours are stated in yours.
- How to report an incident: the channel that starts the clock.
- Exclusions: hosting outages, a third party's API, or changes made by someone else.
- Reporting: what was done, what is pending and how much of the budget has been used.
- Exit terms: notice period, and what you receive when the contract ends.
Monthly retainer, bank of hours or a project
There are two common ways to buy application support, and many companies combine them: a retainer to keep the software healthy and a bank of hours to make it grow. Larger improvements usually fit better as a separate project with its own fixed price. Our guide to fixed price vs time and materials explains when each model makes sense.
| Model | How it works | Fits when | Watch for |
|---|---|---|---|
| Monthly retainer | A fixed monthly amount for corrective, adaptive and preventive work within a defined scope | You want predictable cost and the software is stable | What falls outside the retainer and how it is charged |
| Bank of hours | Hours used for improvements as you request them | Improvements arrive at an irregular pace | Whether hours expire, and how usage is reported |
| Fixed-price project | A larger improvement quoted separately with its own scope | A substantial new feature or integration | That the scope is written down before work starts |
Taking over existing software, and switching supplier
We can take over software we did not build. First comes a software code audit, because nobody can commit to an SLA on something they do not know. The handover starts with an inventory of access: repository, domains, hosting, app store accounts and keys for external services, all moved into your company's name. Then a test environment is set up and a small first change is released, to prove that deployment can be repeated safely. If the audit shows the platform is beyond patching, legacy software modernisation may be the better route.
And if one day you prefer another team, it should be just as simple in reverse: the code is in your repository, deployment is documented and the access is yours. That is one of our commitments; the others are on how we work.
Frequently asked questions
See all FAQs →Do you maintain software you didn't build?
Yes, after an audit to get to know it.
What does maintenance include?
We put it in writing: what it covers, response times and how new features are requested.
Can we switch supplier later?
Yes. Everything is documented and the code is yours.
Can we contract corrective maintenance only?
You can, but it is rarely the cheapest option over time. Without adaptive and preventive work, problems build up until a store requirement or a security update forces a large, urgent piece of work. A small retainer covering all three is far easier to budget than an emergency.
What happens to hours in the bank that we don't use?
It depends on the contract, which is why it should be written down. Common options are hours that roll over for a set period or hours that expire at the end of each term. Check this before signing, along with how usage is reported.
How do we ask for a new feature?
Through the agreed channel, with a short description of the problem it solves. Small changes come out of the bank of hours after an estimate you approve; larger ones are quoted as a separate project with its own fixed price.
What other running costs does software have besides maintenance?
Hosting, domains and certificates, app store fees for mobile apps, and third-party services the software uses, such as maps, SMS, email delivery or AI models. A good support report lists them, so you know what you pay for and to whom.
You might also be interested in
- Advisory and supportCode audit of existing softwareAn independent opinion on the software you already have.
- Advisory and supportDiscovery and prototypingBefore you spend on code, you know what to build and what it will cost.
- Web platformsExcel to web appThe spreadsheet your business runs on, turned into a tool you can rely on.
Tell us about your project.
We'll reply within one working day. We start by understanding the problem, not by selling you a solution.