Software Maintenance and Support: What to Agree Before Your App Launches

Custom software needs an operating plan after launch. Users will need help, external services will change and the business will request improvements. A maintenance agreement should make those responsibilities clear enough that people know what happens when the product needs attention.

The first distinction is between an incident, a defect, routine maintenance and a new feature. These categories may involve different priorities, budgets and approval processes. A vague promise of “ongoing support” leaves both the customer and development team to negotiate those differences during a problem.

Define the supported system

List the application, hosting environment, integrations and devices covered by the arrangement. Identify external providers and which accounts the business owns. A support team cannot resolve every provider outage, but it should know how to identify the dependency and communicate the effect.

Specify supported application and operating-system versions where relevant. An old mobile app still installed on a customer's device may behave differently from the current release. Agree how updates are communicated and which older versions remain supported.

Document exclusions in terms the business can understand. If data restoration, third-party configuration or out-of-hours work requires a separate agreement, make that visible before it becomes urgent.

Separate response from restoration

A response target describes when someone acknowledges and begins handling an issue. It does not necessarily describe when service will be restored or a permanent fix delivered. The time needed to resolve a problem depends on its cause, access requirements and external dependencies.

Define priority using business impact. A complete inability to accept orders is different from a cosmetic issue in an infrequently used report. Include examples from your own workflows so support and business staff classify incidents consistently.

Agree escalation and communication responsibilities. Who can declare a major incident? Who informs users? How often does the business receive a meaningful update? A clear communication route reduces confusion while technical work is underway.

Establish a useful reporting process

An issue report should include the affected workflow, time, user role, observed behaviour and relevant reference numbers. Screenshots can help when they avoid unnecessary personal or confidential information. Do not ask users to share passwords to reproduce an issue.

Provide a way to distinguish a single user's access problem from a wider outage. Support staff need enough operational visibility to investigate without asking every user to repeat the same test.

Retain incident history and the resulting changes. Repeated similar incidents may indicate a process or architectural problem that deserves planned improvement rather than another temporary workaround.

Monitor the workflows that matter

Server availability is not the same as a functioning product. The website may load while payment notifications fail or scheduled reports stop running. Monitor the important outcomes and dependencies relevant to the service.

Decide which alerts require immediate action and which belong in a routine review. Excessive low-value alerts make it harder to notice genuine problems. Each important alert should have an owner and an expected first response.

Keep logs useful without recording unnecessary sensitive data. Include request or job references that help trace failures across integrations. For billing systems, see our subscription workflow article for examples of operational states that need visibility.

Treat backups as a recovery capability

Identify what is backed up: databases, uploaded files, configuration and other information needed to restore operation. Define the acceptable amount of data loss and time to restore service as business requirements, then assess the architecture against them.

Test restoration in a controlled environment. A backup that has never been restored may be incomplete, inaccessible or incompatible with the current application. Record the procedure and make sure the required credentials and owners are known.

Consider what happens to transactions received after a restore point. Recovery may require reconciliation with payment, messaging or other external systems. Restoring a database alone does not automatically restore consistency across every dependency.

Plan routine updates and security work

Frameworks, operating systems and external APIs change over time. Decide how the team tracks relevant changes, assesses their effect and schedules updates. Avoid waiting for a forced platform deadline before checking whether the application remains compatible.

Separate routine dependency work from changes that alter product behaviour. Both require appropriate verification, but their business approval process may differ. Agree a release path with testing, deployment and recovery steps.

Security maintenance also needs ownership. The OWASP API Security project is one reference for reviewing relevant application risks. A support contract should explain the agreed maintenance activities rather than promising that software can never be compromised.

Manage improvements as a visible backlog

Users often identify valuable changes once they work with the product. Capture those requests with the problem, affected users and expected benefit. Do not automatically treat every request as an urgent defect.

Review the backlog with the business owner and choose improvements according to impact and capacity. Record assumptions and acceptance criteria before implementation. This protects support time from becoming an unplanned stream of unrelated features.

For an existing application with accumulated issues, a modernisation assessment may identify work that ordinary maintenance cannot address efficiently. The takeover guide explains what information helps that assessment.

Confirm ownership and handover

The business should know who controls its domain, hosting, app-store accounts, source repository and key provider accounts under the agreement. Define how another authorised team could take over if the arrangement ends.

Maintain documentation for deployment, configuration, recovery and critical business workflows. Documentation should be usable by the intended receiving team, not just a list of technologies. Our handover checklist provides a practical starting point.

Before launch, walk through a hypothetical payment failure, a lost user account and a required operating-system update. If nobody can explain who does what, the support plan needs more detail. Bring those scenarios to a project conversation so maintenance becomes an explicit part of the product's life.