Software Maintenance After Launch: What It Actually Includes

Overview

Software maintenance after launch hides two different jobs: keeping users running day to day, and keeping the software itself healthy over time. This guide explains what maintenance genuinely includes — including improvements to an existing product — what is not automatically included, and what to agree in writing.

Key Points

• Maintenance is two jobs: day-to-day support that resolves incidents, and ongoing engineering that keeps the application secure, current, and changeable.
• Real maintenance work is a short recurring list: bug fixes, security patching, dependency updates, monitoring, tested backups, performance tuning, documentation.
• Improvements to existing features can be maintenance; major new capabilities and redesigns are not automatically included — coverage depends on agreed scope and capacity.
• Read SLAs for initial response, restoration, and permanent resolution targets by severity, stated support hours, and agreed consequences such as service credits.
• Match the pricing model to the work: fixed fees for predictable upkeep, retainers with defined capacity for mixed work, time and materials for variable demand.
• Get eight things in writing: scope, response targets, communication, roles, pricing, documentation, security, and exit terms.

Your product launched. It works. Customers are using it. Then the agency sends the quote for “maintenance” — and it reads like another project entirely.

The short answer is that the word hides two different jobs. The first is keeping your users running today: fixing what breaks, answering when something goes wrong. The second is keeping the software itself healthy over time: patches, updates, monitoring, backups, and the small unglamorous tasks that stop a working product from decaying. Confusing the two is easy at the buying stage — a quote for the second job can look like overkill if you only had the first in mind.

The two jobs hiding in the word "maintenance"

Separating the two jobs matters because they are bought, measured, and priced differently — “we'll look after it” usually means a menu, not a single promise.

The first promise is about your users' bad days: something breaks, a login stops working, a payment fails — someone picks up the problem and gets people moving again. Its quality shows in how fast and how well incidents get resolved.

The second promise is about the software's slow years: defects corrected properly rather than patched over, security fixes on a rhythm, dependencies kept current, performance watched, and documentation that describes the system in a crisis. Its quality shows up in what it aims to prevent: emergency upgrades, unexplained outages, a codebase everyone fears touching.

Support and preventive maintenance need clear owners. Either may be handled by your team or a provider; an agreement covering one should state who handles the other.

What the maintenance work actually is

Strip away the jargon and post-launch maintenance is a short list of recurring work:

Bug fixes and incident handling. When something breaks in production, there should be a repeatable path from report to fix to release. Good providers also chase root causes: a bug that keeps returning suggests the underlying cause was never addressed.

Security patching and dependency updates. The frameworks, libraries, and databases your product depends on release fixes continuously. Skipped updates accumulate into one large, risky upgrade later.

Monitoring and alerting. Monitoring systems watch availability, response times, error rates, and integration health continuously and raise automated alerts — but an alert is not a response. The agreement should say who receives alerts and which response hours apply: monitoring can run around the clock while engineer response is limited to stated hours.

Backups — that are actually tested. Backups run on a rhythm that matches how fast your data changes, live in more than one location, and get restored on purpose to prove they work. Until a restore has been tested, you have a procedure, not a safety net.

Performance tuning. Speed erodes gradually — data grows, queries get heavier — until users notice. Work planned around that drift is maintenance; the same work forced on you by complaints is firefighting.

Documentation and knowledge. Keep the records a stranger would need in a crisis: how the system is put together, what it connects to, how it is configured, what changed and when, and how to recover it. Current records are also what let you change providers or bring work in-house without starting from zero.

Four kinds of maintenance, in plain terms

Providers often describe maintenance using four categories — a commonly used split, not an exhaustive universal classification:

• Corrective: fixing what has already broken — bugs, crashes, failed transactions.
• Adaptive: adjusting the product because the world around it changed — a new iOS or Android version, a payment provider's updated API, a database reaching end of life.
• Perfective: improving what works — a faster workflow, a clearer interface, a feature refined after real usage.
• Preventive: reducing the chance of future failure — refactoring fragile code, upgrading dependencies, adding automated tests.

The balance between them matters. If nearly every hour goes to fixing what broke, prevention is underfunded. If adaptation work keeps piling up, the underlying stack may be ageing toward a bigger decision.

What maintenance is not

This is where arguments start: what counts as maintenance, and what counts as new work. Maintenance can include improvements to an existing product — refining a workflow, tuning a feature after real usage (the perfective category above). What is not automatically included is major new capability: a new module, a redesign, or anything that changes what the product fundamentally does. Whether such work is covered, and from what capacity, depends on what you agree.

So the agreement should spell out what is in scope and what is out, and how out-of-scope requests get estimated, priced, and approved before work begins. Without that process, every invoice becomes a negotiation.

Reading an SLA without rose-tinted glasses

The service level agreement says how fast things happen and what happens when they don't. A few things to look for:

Distinguish three milestones, because “first response” is not “fixed”: initial response (someone acknowledges the issue and starts), restoration or workaround (the service is usable again), and permanent resolution (the underlying fault is fixed). Targets for each can differ, and all should vary by severity.

Also check the mechanics: the support calendar (which days and hours count), how times are measured and reported, what is excluded (for example, failures caused by third-party platforms), and whether the clock pauses while the provider waits on you. Document what happens when targets are missed — common examples include service credits and escalation paths — so consequences are agreed in advance.

Support hours matter more than you think. Weekday business-hours coverage is a different product from round-the-clock cover with an on-call engineer. If your customers are in another timezone, check the hours cover them.

Review it, don't file it. An SLA that made sense at launch may not fit a year later; a periodic review keeps the targets honest.

How maintenance is priced

Maintenance is usually sold in one of three ways, and the right choice depends on the shape of the work:

• Fixed monthly fee suits predictable, steady maintenance — monitoring, scheduled patching, a known application. Easy to budget, but the scope must be tightly defined; a fixed fee for loosely defined work can create weak incentives to do more than the minimum.
• Retainer with defined capacity — a set amount of capacity per month, overflow billed at an agreed rate — balances predictability with flexibility.
• Time and materials suits variable, request-driven work where the volume is genuinely unknown. Flexible, but costs are harder to predict.

Match the model to the work, not the sales pitch. Fixed pricing on genuinely open-ended work can create the wrong incentives; open-ended pricing on routine tasks creates cost anxiety. The same risk logic applies after launch — the guide to fixed price versus time and materials covers it in full.

What to get in writing before you agree

Before signing anything, ask for the proposal to cover these points explicitly:

• What is included — and what is not. The recurring activities covered, and the boundary with new development.
• Response, restoration, and resolution targets, by severity, with stated support hours and an escalation path.
• How you communicate. Update cadence, channels for normal and urgent contact, and who acknowledges issues.
• Roles and responsibilities. Who owns incident reporting, change approval, testing sign-off, and access on each side — plus named contacts with decision-making authority.
• Pricing and payment terms. The billing model, the schedule, what costs extra, and how out-of-scope work is approved.
• Documentation and knowledge transfer. What records are kept current, and what you receive if the relationship ends — change logs, system documentation, credentials.
• Security and compliance. Confidentiality terms, access controls, audit logging, and responsibilities in a security incident.
• How the agreement ends. Term length, renewal terms, notice periods, and a handover process. Agreeing the exit while everyone is friendly is cheaper than negotiating it during a breakup.

None of this requires legal brilliance — just both sides writing down what they believe the deal is, and discovering the differences while they are still cheap to fix.

Practical next steps

If your product is already live, ask whoever maintains it three questions: which dependencies are past their supported versions, when were backups last restored in a test, and what share of maintenance time is corrective versus preventive?

If you are choosing a provider, ask for the proposal to address the eight points above in writing. If you are still building, plan the maintenance arrangement alongside the launch, not after it; the SaaS planning guide treats launch support as part of pre-build planning for exactly this reason. And when new work emerges from maintenance requests, the project cost calculator gives an indicative scope-based estimate of cost and timeline.

FAQ

Do I need a maintenance agreement from day one?

Not necessarily the agreement, but you need the activities from day one: monitoring, backups, and patching should be in place at launch. The written agreement matters as soon as someone outside your own team is responsible.

Can my own team handle maintenance instead of a provider?

Often, yes — if the team has the capacity. The same eight points apply internally: someone must own monitoring, patching cadence, backups, and documentation. The internal risk is that preventive work loses out when features compete for the same hours.

When is maintenance no longer worth it?

When the cost and risk of keeping it running exceed the value of operating it. Warning signs: recurring incidents from the same root causes, dependencies that can no longer be updated, rising costs, and architecture that blocks what the business needs next. Then the honest question is whether to modernise or retire.

Does maintenance cover my product's integrations?

They should, if they are in scope — integrations are among the fastest-moving parts of a modern product, and providers change their interfaces regularly. Make sure the agreement says who does the adaptation work.

A final note

Maintenance is the least glamorous part of owning software, which is exactly why it deserves the clearest agreement. Get the scope, response targets, and exit terms in writing while everyone is optimistic — and if you would like a second pair of eyes on a maintenance proposal, talk to us.

Sources

The following sources were read in full on 20 October 2026 (Asia/Karachi) and informed this article:

Key Points for Software Maintenance Contracts — Scrums.com; published 2024-11-25, updated 2026-09-30.

Software Maintenance Checklist for Businesses — Scrums.com; published 2024-08-23, updated 2026-09-30.

Application Maintenance and Support Guide — Damco Group; read 2026-10-20 (no publication date stated on the page).

What Is an SLA? Service Level Agreements Explained — Atlassian; read 2026-10-20 (no publication date stated on the page).

Service level agreements that work — Tallyfy; published 2017-03-29, updated 2026-03-14.