Web application support is the ongoing work required to keep a live system running reliably after the initial build is complete. The term sounds straightforward, but the scope varies significantly between suppliers and contracts. Understanding what is genuinely included prevents disputes, budget surprises and operational gaps.
Support typically divides into four areas:
Set operational expectations around these areas
Infrastructure and hosting
Keeping the servers, databases and related services operational. This covers server uptime, database availability, file storage and the network configuration that connects them. If the application goes down because a server fails, infrastructure support addresses the recovery.
Application stability
Fixing defects that appear in existing functionality. If a process that worked at launch stops behaving correctly—perhaps a report no longer generates, or a form submission fails silently—this falls within defect resolution. The key distinction is that the functionality was specified and accepted; it has since broken.
Security maintenance
Applying updates to the underlying framework, libraries and server software to address known vulnerabilities. This is not the same as a full security audit. It is the routine patching that prevents the application from becoming exposed through outdated dependencies.
Third-party dependency management
Monitoring the services the application relies on—payment gateways, API providers, authentication services—and responding when those services change their endpoints, deprecate features or alter their terms.
What support does not typically include is new feature development. Adding a new report, extending a workflow or integrating an additional system is a change request, not a support matter. Some suppliers bundle a small allowance for minor changes into a support package, but this should be explicitly stated and measured.
The contract or service-level agreement should define each of these areas with specific boundaries. A statement such as "bug fixes included" is insufficient without clarification of what constitutes a bug versus a change, which parts of the stack are covered and what response and resolution times apply.
The right support scope depends on what the application does, who uses it and what happens if it stops working.
An internal admin panel used by five staff members during office hours carries different risk from a customer-facing portal that processes orders around the clock. For the internal tool, a next-business-day response to a defect may be acceptable. For the customer portal, you may need defined response times within hours and resolution targets measured against revenue impact.
Applications with heavy integration dependencies need particular attention in the support scope. If your CRM syncs with an accounting package, a CRM support contract that excludes third-party integration issues leaves a gap. The CRM supplier may correctly state that the accounting API changed, while the accounting provider points to the CRM's implementation. The support scope should state who investigates and resolves integration failures, even when the root cause lies partly outside the application.
For SaaS products serving multiple tenants, support must also cover multi-tenant isolation issues, tenant-specific data queries and onboarding problems that existing users encounter. The scope here is broader because the supplier is effectively supporting both the operator and the operator's customers.
When evaluating a support package, practical questions to put to the supplier include:
- Which components of the stack are you responsible for, and which are my responsibility?
- How do you distinguish between a defect and a change request, and who makes that determination?
- What is your escalation path if a second or third line of expertise is needed?
- Do you monitor the application proactively, or do you rely on me to report problems?
- What access do you need, and how is that access controlled and audited?
- Who is responsible for restoring data if a deletion or corruption occurs, and what are the recovery time expectations?
The answers should be written into the agreement, not left as verbal assurances.
Support risks and checks
The most frequent mistake is assuming that a support contract provides complete protection against all operational problems. Support addresses defined categories of work within defined boundaries. It does not eliminate risk; it allocates responsibility for managing specific risks.
A common limitation is the exclusion of issues caused by user error or unauthorised configuration changes. If a staff member with admin access alters a setting that breaks a workflow, some support contracts classify this as outside scope. Whether that is reasonable depends on your situation, but it must be understood upfront rather than discovered during an incident.
Another recurring problem is unclear ownership of credentials and access. Support cannot be delivered effectively if the supplier does not have appropriate access to hosting panels, databases, error logs and deployment environments. Equally, retaining sole control of all access creates a dependency that becomes critical if the relationship ends. Access arrangements should be documented, with a clear record of who holds what credentials and how access is revoked if needed.
Data backup responsibilities are frequently ambiguous. The hosting provider may perform server-level backups, the application may have its own backup routines, and the support supplier may or may not be responsible for testing restore procedures. You need to know not just whether backups exist, but who verifies they work, how often they are tested and who performs the restoration if required.
Key checks before agreeing to a support arrangement:
- Confirm that the SLA defines both response time (how quickly someone acknowledges the issue) and resolution time (how quickly the issue is fixed), and that these are separate commitments.
- Verify that the scope explicitly lists what is excluded, not just what is included.
- Ensure there is a defined process for raising, prioritising and tracking issues.
- Check whether the support period has a fixed duration and what happens to pricing on renewal.
- Confirm that security patching is tied to a defined schedule rather than left to ad-hoc judgement.
- Establish who holds the source code, where it is stored and whether the support supplier's access to it is conditional on the contract remaining active.
Support is not a substitute for clear ownership, documented access and an exit strategy. Those are separate matters that should be resolved before or alongside the support arrangement, not left as assumptions within it.