Almost every software contract contains the word "warranty". Almost none of them agree on what it means. For a buyer comparing proposals that is a problem, because the warranty clause is one of the few places where a supplier states, in writing, what they will still be responsible for after the invoice is paid.
This is a plain description of what a software development warranty covers, what it does not, and which questions separate a real commitment from a sentence written to be reassuring.
What is a software development warranty, exactly?
A warranty is a promise about defects. It says: if the system we delivered does not do what we agreed it would do, we fix it, at no additional charge, for an agreed period.
Three parts of that sentence carry all the weight.
"Does not do what we agreed." A warranty is measured against the agreed scope, not against what anyone later wished the system did. This is why the scope document matters more than the warranty clause: a vague scope makes the warranty unenforceable in both directions, because neither side can say whether a given behaviour is a defect or a new requirement.
"At no additional charge." A warranty that bills for the fix is not a warranty, it is a support contract with a discount.
"For an agreed period." The term has to be stated before the project starts, in the contract, not discussed after something breaks.
At WeebPal every project includes a one-year warranty as standard, extendable up to three years. The term is agreed with you before the project starts and written into the contract. We say "up to three years" rather than "three-year warranty" because the length is a contractual choice, not a slogan: the standard is one year, and three is available by agreement. The full terms are on the warranty page.
What does a warranty actually cover?
Our warranty covers four categories, and they are worth spelling out because they are narrower than most people assume and broader than most contracts offer.
- Bug fixes and defect resolution. The system does not behave as specified. A form rejects valid input, a report totals incorrectly, a workflow stalls in a state it should pass through.
- Security vulnerability patches. A vulnerability is found in the code we wrote, or in a component we chose, and it needs patching.
- Performance optimisation issues. Something we built is slow in a way that was not part of the agreed behaviour.
- Compatibility updates for Drupal core minor versions. Core moves; the code we wrote keeps working with it.
That last one deserves attention, because it is the category most often left out. A system built on an actively maintained platform is a moving target: minor releases arrive on a schedule whether or not anyone is watching. A warranty that covers the code but not its compatibility with the platform underneath it protects you for about six months.
What does a warranty not cover?
An honest warranty has a boundary, and a supplier who will not draw it is either not thinking clearly or hoping you will not ask. Ours excludes four things.
- New feature development. If the system does what was agreed and you now want it to do something else, that is a change, not a defect. This is the boundary that matters most in practice, and it is why a precise scope protects the buyer as much as the supplier.
- Third-party service changes. A payment gateway deprecates an API version, a mapping provider changes its terms, an identity provider alters its token format. We did not cause it and cannot prevent it. Adapting to it is work.
- Issues caused by unauthorised modifications. If someone else edits the code, we cannot warrant the result. This is not a lock-in clause (you own the source and may change it freely, and we will still help), but a change we did not make is not a defect we introduced.
- Infrastructure or hosting issues outside our control. A data centre outage is not a software defect.
How quickly does a warranty claim get answered?
A warranty without a response commitment is a promise with no clock on it. Ours states target first-response times by severity: four hours for critical issues, one business day for high priority, three business days for normal.
Read that carefully, because the distinction is one buyers are routinely allowed to miss. Those are targets for our first response: acknowledgement, triage, and a view on what is happening. They are not resolution times. Nobody can honestly promise a fixed resolution time for a defect that has not been diagnosed yet, and a supplier who does is quoting a number they intend to renegotiate later.
Operating hours, time zone, severity definitions, the escalation path and any resolution commitments are set out in the support agreement for your specific system, because those genuinely differ between a public-facing service with a seasonal peak and an internal tool used during office hours.
Why can we offer a long warranty at all?
The honest answer is not generosity. It is that the same team that built the system does the warranty work.
Most warranty economics break because of handover. When a defect arrives three months after launch and lands with a team that has never seen the codebase, the first two days are spent reading code, and that cost has to be recovered somewhere. It gets recovered by making the warranty short, narrow, or expensive.
Keeping the build team attached to the system removes that cost. Nobody has to learn the codebase before they can fix it. That is most of why a long warranty is affordable to offer and useful to hold, and it is also why we resist the pattern where delivery and support are different companies with different incentives.
Warranty, maintenance and support are not the same thing
These three get used interchangeably in sales conversations and they mean quite different things commercially.
| Warranty | Maintenance | |
|---|---|---|
| What it covers | Defects in what we built | Updates, monitoring, changes, ongoing care |
| Who built the system | Must be us | Can be anyone, including systems we did not build |
| Cost | Included in the project price | Separate, ongoing |
| Duration | Fixed term agreed up front | For as long as you want it |
Conflating them is how a buyer ends up paying monthly for something they were told was included. If a proposal quotes warranty and maintenance together on a single line, ask which portion of the fee is the warranty. The answer should be none of it.
Our ongoing arrangement is described under support and maintenance, and it is deliberately separate from the warranty, including in price.
What should you ask a supplier about their warranty?
Six questions, in the order they matter.
- How long, and is it in the contract? If the term only appears in the proposal, it is marketing copy.
- What is excluded? A supplier who cannot list the exclusions has not thought about the boundary, and you will discover it during an incident.
- Who does the warranty work? The build team, or a support desk that has never seen the code?
- What are the response targets, and are they first-response or resolution?
- What happens if you are unavailable? This is the question that matters most and is asked least.
- Do we hold the source code? A warranty is worth what it is worth, but source code ownership is what you fall back on if the warranty cannot be honoured.
That last point is not a detail. A warranty is a promise from a company, and a company is a thing that can change hands, change direction or stop trading. Source code ownership is what turns a broken promise into an inconvenience instead of a rebuild. Every engagement we take on ships with the full repository from day one: here is why we contract that way.
Where the warranty sits in the price
Ours is included in the project price rather than billed separately, which is a deliberate commercial choice: a warranty priced as an add-on is a warranty the supplier expects some buyers to decline, and a supplier who expects that has priced the risk of declining into the base. Our pricing page sets out the bands and the milestone structure, and the warranty term is part of the scope conversation before any of it is committed.
If you are comparing proposals right now and the warranty clauses read differently, the six questions above will separate them faster than the price line will. And if you want to talk through what a warranty would cover on your specific system, get in touch.