Three words get used as if they were synonyms in software proposals: warranty, maintenance, and SLA. They are not synonyms. They answer different questions, they are priced differently, and confusing them is how a buyer ends up paying a monthly fee for something they believed was already included.
Here is what each one actually is, how they interact, and what to check in a contract.
What is a warranty?
A warranty is a promise about defects in work that was already delivered.
It says: if the system does not do what we agreed it would do, we fix it at no additional charge, for an agreed period. It is retrospective. It looks back at the delivered scope and guarantees it.
Four properties define a warranty:
- It only covers defects: the gap between agreed behaviour and actual behaviour. Not new requirements.
- It only covers work the warranting party built. Nobody warrants someone else's code.
- It is included in the delivery price. A separately billed warranty is a support contract wearing a warranty's name.
- It has a fixed term, agreed before the work starts.
Ours runs one year as standard, extendable up to three years by agreement, with the term written into the contract before the project begins. What it covers and what it excludes is set out on the warranty page.
What is maintenance?
Maintenance is ongoing care of a system that is in production.
It is prospective. It looks forward at the things that will need doing regardless of whether anything was ever wrong: security patches as they are released, platform version updates, dependency upgrades, performance work as traffic and data grow, backup and restore verification, monitoring, and small changes as the business changes.
Three properties define maintenance:
- It covers change and upkeep, not just defects.
- It can be provided by anyone, including on systems the maintainer did not build.
- It is a separate, ongoing cost, usually monthly, sized to the system.
Our arrangement is described under support and maintenance, and it is deliberately priced and contracted apart from the warranty, including for systems built by other people.
What is an SLA?
An SLA (service level agreement) is not a category of work at all. It is a set of measurable commitments attached to whatever work is being done.
This is the distinction people most often miss. Warranty and maintenance describe what is done. An SLA describes how fast, how reliably, and what happens if not. You can have a warranty with an SLA or without one. You can have maintenance with an SLA or without one. An SLA on its own covers nothing, because it is a description of service levels for a service defined elsewhere.
A meaningful SLA states at minimum:
- Severity definitions. What counts as critical, high, normal, in terms of business impact, not developer opinion.
- Response targets per severity. And explicitly whether these are first-response or resolution targets.
- Operating hours and time zone. "Four hours" means something very different at 22:00 on a Saturday.
- The escalation path. Who is contacted, in what order, when a target is missed.
- Consequences. What happens when a commitment is not met.
Our published response targets are four hours for critical issues, one business day for high priority, and three business days for normal, and they are stated as first-response targets, not resolution times. The distinction matters: a resolution time cannot honestly be promised for a defect nobody has diagnosed yet. Operating hours, severity definitions, escalation and any resolution commitments are set out in the support agreement for your specific system, because a public service with a seasonal peak and an internal tool used in office hours should not carry the same numbers.
Side by side
| Warranty | Maintenance | SLA | |
|---|---|---|---|
| What it is | A promise about defects | Ongoing upkeep and change | Measurable commitments on service |
| Looks | Backwards at delivered scope | Forwards at the system's life | Neither: it qualifies the other two |
| Who can provide it | Only whoever built it | Anyone | Anyone providing a service |
| How it is priced | Included in the project price | Separate and recurring | A term of another agreement |
| Duration | Fixed term, agreed up front | As long as you want it | For the life of the agreement it qualifies |
| Covers new features? | No | Usually yes, within scope | Not applicable |
How the three interact in practice
A system that has been live for eighteen months might be covered like this: the warranty is still running, so defects in the original build are fixed at no charge; a maintenance agreement covers patching, upgrades and small changes for a monthly fee; and an SLA attached to that maintenance agreement sets the response targets and escalation path for both.
The interesting case is overlap. Suppose the checkout stops working after a platform update. Is that a warranty claim or maintenance work?
The answer depends on cause, which is why cause should be established before commercial terms are discussed. If the code we wrote was incompatible with a core minor version, that is warranty. If a third-party payment API changed its contract, that is maintenance: nobody warrants another company's roadmap. If someone edited the code directly on the server, it is neither, and the honest response is to say so and quote the work.
A supplier who treats every incident as billable is not being fair to the warranty. A buyer who treats every incident as warranty is not being fair to the boundary. Naming the cause first keeps both sides honest.
What to check in a proposal
Five checks, each of which takes about a minute.
- Are warranty and maintenance priced on separate lines? If they are bundled into one figure, the warranty is being sold to you. Ask which portion of the fee it represents. The answer should be none.
- Does the warranty term appear in the contract, not only the proposal? A term that lives in a sales deck is not a term.
- Are the exclusions listed? Every real warranty has a boundary. A supplier who will not draw it has either not thought it through or is relying on you not asking.
- Do the response targets say first-response or resolution? If it does not say, assume first-response, and ask.
- Who does the work? The team that built the system, or a separate desk that will be reading the code for the first time during your incident?
The thing that outlasts all three
Warranty, maintenance and SLA are all promises from a company. They are only as good as the company's continued existence and willingness. That is not cynicism, it is just what a contract with a supplier is.
What sits underneath all three, and does not depend on anyone's continued goodwill, is whether you hold the source code. If you own the repository (the application code, the custom modules, the theme, the build tooling and the deployment configuration), then a supplier who cannot honour a commitment becomes a procurement problem rather than a rebuild. If you do not, every one of these agreements is also a dependency.
We ship the full source from day one on every engagement, which is the argument we make here. It is also the reason our warranty can be long: we are not using the code as leverage, so there is no commercial reason to keep the term short.
If you want to see how the warranty term fits into a scope and a price, our pricing page sets out the bands and the milestone structure, and you can ask us directly what any of it would look like on your system.