"Ongoing support" appears in almost every software contract. What it actually covers varies enormously — and the gap between expectation and reality is where most post-launch disappointments happen.
When a software development project concludes and a client transitions to "ongoing support," both parties often have different mental models of what that means. The development team considers certain work in scope; the client expects other things to be covered. These misalignments surface at the worst possible time — when something goes wrong.
This post covers the actual categories of post-launch software support, what service level agreements mean in practice, what to look for in a support arrangement before you sign, and the specific red flags that indicate an arrangement won't hold up when you need it.
The categories of post-launch support
The first clarification that matters: "support" is not one thing. It covers several distinct types of activity that have different costs, different timelines, and different implications for what a contract should say.
Bug fixes
Correcting behavior in the existing software that doesn't match the intended specification. A button that doesn't work, a calculation that produces the wrong result, a workflow that breaks under a specific condition that wasn't covered in testing.
Bug fixes are typically the core of any support arrangement. The questions that define whether the arrangement is functional: How quickly do bugs get acknowledged? How quickly do they get resolved? Who decides what counts as a bug vs. a feature request? What's the process for reporting them?
Maintenance and updates
Work that keeps the software running correctly over time without adding new functionality: dependency updates, security patches, compatibility fixes as browsers or operating systems change, infrastructure updates as cloud providers evolve their services.
This is the category most commonly missing from support agreements that were written with only bug fixes in mind. Maintenance work is non-optional — software that doesn't receive it accumulates vulnerabilities and eventually breaks — but it's also not always visible, which makes it easy to omit from contracts and easy to neglect.
Feature development
New capabilities added to the software after launch. This is categorically different from bug fixes and maintenance, and is typically handled differently in contracts — often billed separately, scoped through a separate process, or subject to a separate statement of work.
The common confusion: clients often experience missing functionality as a bug ("the software doesn't do what I need") when it's actually a feature that was never in scope. Distinguishing between "the software doesn't do what it was designed to do" (bug) and "the software doesn't do something we now want it to do" (feature) is foundational to managing support expectations.
Infrastructure and hosting management
Monitoring the servers and services the application runs on, managing deployments, responding to infrastructure incidents, managing scaling, and handling the operational layer of the application. This may or may not be part of a support engagement depending on who hosts the application and what the arrangement covers.
If a development partner hosts the application, infrastructure management is typically included — it's part of keeping the software running. If the client hosts it themselves, infrastructure management is the client's responsibility, and the support engagement may only cover the application layer.
Strategic and advisory support
Higher-order engagement: advising on technology decisions, reviewing the application's architecture as requirements evolve, helping prioritize a development roadmap, evaluating new integration opportunities, or serving as a technical sounding board for business decisions that have technical implications.
This type of support is often the most valuable and the most underspecified. It's also the most likely to exist in practice as an informal expectation without ever being formally scoped or priced.
What SLAs actually define
A Service Level Agreement (SLA) is a commitment about the quality and timeliness of service delivery. In the context of software support, SLAs typically cover some combination of:
Response time — How quickly will an acknowledgment be sent after a support request is received? Response time is not resolution time. A 1-hour response time SLA means someone will acknowledge your issue within an hour, not that it will be fixed in an hour.
Resolution time — How quickly will an issue be resolved? This is harder to guarantee than response time because resolution depends on the complexity of the issue. Mature SLAs often define resolution targets by severity tier rather than a single blanket commitment.
Uptime — For hosting arrangements, the percentage of time the application is available and functioning. (Covered in more detail in our cloud hosting post.)
Support hours — When is support available? Business hours only, extended hours, or 24/7? This matters most for applications where downtime at any hour has significant business impact.
A typical tiered structure looks like this:
| Severity | Definition | Response | Resolution target |
|---|---|---|---|
| Critical | Application down or data at risk | 1 hour | 4 hours |
| High | Major feature unavailable, significant user impact | 4 hours | 1 business day |
| Medium | Feature degraded, workaround available | 1 business day | 3 business days |
| Low | Minor issue, cosmetic problem | 2 business days | Next release |
The definitions of each severity tier matter as much as the time commitments. An agreement where the support provider controls severity classification without input from the client creates obvious incentive misalignment.
Response time vs. resolution time: the distinction that matters most
This distinction is where the most significant expectation gaps form. A client experiencing a critical issue cares about when it will be fixed, not when it will be acknowledged. But resolution time is genuinely hard to commit to because different issues have radically different complexity.
A database index missing from a query might be diagnosed and fixed in 15 minutes. A race condition that only occurs under specific concurrent load conditions might take days to reliably reproduce, let alone fix. Both might come in as "the application is slow" — the same symptom, very different resolution paths.
What good SLAs do: define resolution targets by severity, with explicit carve-outs for issues that require extended investigation. The honest position is "we will have a working fix or a concrete timeline for a working fix within X hours for critical issues." This is different from "all critical issues will be fixed within X hours."
What to watch for: agreements that blur the distinction between response and resolution, making response commitments sound like resolution commitments.
Questions to ask before signing a support agreement
These questions surface the most common misalignments before they become problems:
What is explicitly included? Get a clear list of what's in scope: bug fixes only? Maintenance and dependency updates? Feature development? Hosting management? Strategic advisory? Anything not on the list is out of scope by default.
What is explicitly excluded? The most informative part of any support contract is what it doesn't cover. New feature development is commonly excluded. Changes required by third-party API updates may be excluded. Issues caused by client-side changes are often excluded.
How is a bug distinguished from a feature request? The criteria matter. Is it "behavior not matching the original specification"? "Behavior not matching user expectations"? Something else? Who makes the call?
Who is the point of contact, and what are their qualifications? Is there a dedicated account contact who understands your application, or does every request start from scratch with whoever is available? Continuity of context has significant impact on support quality.
What is the escalation path for unresolved issues? If a critical issue isn't resolved within the committed timeframe, what happens? Who does it escalate to, and by what mechanism?
What happens during off-hours? Is there on-call coverage for critical issues outside business hours? What's the mechanism for engaging it?
Who controls severity classification? The client, the support provider, or a joint definition with clear criteria?
What are the reporting and transparency obligations? Will you receive regular updates on open issues, maintenance activity, and system health? Or is it reactive only?
What are the exit terms? If you end the support engagement, what happens to your access to the codebase, the infrastructure, and the documentation? What is the transition process?
Red flags in support agreements
"Best effort" without definition. "We will use best efforts to resolve issues promptly" is not an SLA. It's an attitude statement. If response and resolution commitments aren't specific, they're not enforceable.
Response time presented as resolution time. Marketing language that describes "1-hour support" without clarifying whether that's response or resolution. Almost certainly it's response.
No severity tiering. A single SLA commitment that applies to all issues equally means critical outages get the same treatment as cosmetic bugs. Or it means critical outages are the only thing the commitment actually applies to, and everything else gets deprioritized.
No definition of what constitutes a bug. Without a shared definition, "this isn't a bug, it's a feature request" becomes a mechanism for avoiding support obligations rather than a meaningful distinction.
No documentation handoff obligations. If the support engagement ends, what documentation exists to allow another team to take over? Support agreements that don't address this create dangerous continuity risk.
Support hours that don't match your business risk. Business-hours-only support for a consumer-facing application that operates 24/7 creates unacceptable gaps. Evaluate whether the support availability matches the operational requirements of your application.
No process for proactive communication. An arrangement where you only hear from your support partner when you raise an issue — and never proactively when they see something concerning — is reactive by design. Proactive monitoring and communication are what make a support partner valuable before things go wrong.
Written by
Chris Coussa
Founder, Day2 Innovative Technical Solutions