How to Plan Maintenance, Updates and Support After Software Delivery
The figure talked about most in software projects is the development fee. Yet delivery is not the end of the project; it is the moment the product starts living. This article explains what happens after delivery, which items continue and what needs to be in writing in a maintenance agreement.
Why no software stays “finished”
Software that works on the day you deliver it will degrade over time even if nobody touches it. The reasons are independent of you:
- Operating systems get updated. iOS and Android release a new version every year, and the app stores may require apps to target a certain version.
- Browsers change. An interface written years ago may behave differently in today’s browser.
- Dependencies get updated. Security vulnerabilities are found in the libraries used and patched; you have to patch too.
- Third-party services change. When the payment provider, courier company or map service updates its interface, your connection can break.
- Regulations change. Changes on the invoicing, tax or data protection side are reflected in the software.
- Your business changes. A new service, a new pricing structure, a new branch.
None of these is a sign of “badly written software”. It is the nature of software, and it needs to be budgeted for.
Maintenance is not one thing: four different jobs
Very different kinds of work are gathered under the heading “maintenance”. The quote should state separately which of them is covered.
| Type | What it means | How it is usually charged |
|---|---|---|
| Corrective | Bug fixing — repairing something that does not work as expected | Free within the warranty period, afterwards by agreement |
| Preventive | Security patches, library and infrastructure updates, backup checks | Monthly or annual maintenance package |
| Adaptive | Adjusting to changes in the outside world — a new operating system, a changed service interface | Maintenance package or separate job |
| Enhancement | New features, new screens, scope expansion | Separate project or hourly |
The most frequent dispute lies at the boundary between the first and last rows: “Is this a bug or a new request?” The contract should define what a bug is — for example, “a function defined in the accepted scope not producing the expected result”. Behaviour that was never discussed in the scope is not a bug but a new request.
Costs that continue after delivery
Separate from the maintenance service, there are regular items that keep the product running:
- Server and database hosting — grows with the number of users
- Domain name and SSL
- App store developer accounts (for mobile apps)
- Usage fees for services such as notifications, SMS, email and maps
- Payment provider fees
- Error monitoring and backup tools
- Paid licences, if any
Also clarify in whose name these items will be opened. Having the accounts in your business’s name ensures that the product and the data stay with you even if you change providers later.
What must be written in a maintenance agreement
A verbal understanding is useless on the day a problem appears. The following should be in writing:
- Scope: Which of the four types above are included?
- Definition of a bug: What counts as a bug and what counts as a new request.
- Severity levels: “The system has stopped completely” and “there is a typo” cannot have the same urgency. A separate response time should be defined for each level.
- Response and intervention time: How long after a report will you get a reply, and how long until work starts? These are different things.
- Working hours: Is support during weekday office hours or 24/7? The two are priced very differently.
- Hours included: How many hours are in the monthly package, and what happens when they are exceeded?
- Reporting channel: Where will requests be sent? It should be a traceable channel, not a personal phone.
- Backups: Frequency, where they are kept, recovery time and whose responsibility this is.
- Termination and handover: When the agreement ends, how will code, data and accounts be handed over?
Is a maintenance agreement mandatory?
No, but decide knowing what the alternative is. There are three routes:
- Regular maintenance package: A fixed monthly fee. Predictable cost, priority support. In periods with few problems it can feel like “paying for nothing”.
- On demand: A work order is opened when a problem appears. No payment in months without problems. In return you join the queue, and in an emergency the developer may not be available.
- None: The product is left as it is. Cheap in the short term; the accumulated updates come back one day as a big job.
If your business depends on this software — if work stops when it stops — the third option is not a real option.
How to submit a support request
A small routine on your side shortens the resolution time noticeably:
- Use a single channel; do not let requests scatter across different people’s phones.
- Write down what you did, what you expected and what happened.
- Attach a screenshot or a short video.
- Which user, which device, which browser — these three narrow down most problems at first glance.
- Is the problem constant or occasional? “It happens sometimes” is information too.
- Appoint a single contact person on the business side; let them collect the requests.
Frequently asked questions
How long should the warranty period be?
There is no single standard in the industry; free bug fixing for a certain period after delivery is common. What matters is that the period and what it covers are written in the contract.
What determines the maintenance fee?
The size of the system, how critical it is, the number of integrations, the expected response time and the support hours are the deciding factors. There is a serious difference between 24/7 support and office-hours support.
What happens if I start working with another company?
The contract should contain a handover clause for this possibility: delivery of the source code, transfer of server and account access, technical documentation. The easiest time to discuss this clause is at the start of the project, while the relationship is good.
Will I get a quote every time I want a new feature?
It depends on the working arrangement. For small, frequent changes a monthly pool of hours is practical; large additions are planned as separate projects.
Should I pay for maintenance on software that is never used?
If it is not used, the real question is why. If it holds data, security updates are still needed; if it is to be abandoned completely, it is better to export the data and shut the system down.
Let’s talk about maintaining your current project
If you have software that is already running, we can work out together which items are ongoing and what needs updating. If you are planning a new project, we discuss these items within the scope of the quote from the start. You can look at our custom software, mobile app and website services and contact us; we communicate in English or Turkish. We collected the questions to ask when choosing a provider in our article on choosing a software company.