Warranty Period in Software Development: What Gets Fixed Free
Basics4 minInnovialabs editorial team
In short
A warranty means free fixes for defects, that is, deviations from the agreed specification, for a set period after delivery. New features and problems caused by environment changes are not covered; that is what a support contract is for.
What a warranty period is
A warranty period is the time after project acceptance during which the contractor fixes defects at no cost. A defect is any case where the system behaves differently from what was agreed in the specification, the designs or the acceptance criteria.
The key word is "agreed". A warranty protects you from the contractor's mistakes, but it does not turn them into a free development team. If the spec says "orders are sent to the CRM" and they are not, that is a defect. If you now want orders sent to Telegram as well, that is a new task.
What is covered and what is not
| Situation | Covered? | Why |
|---|---|---|
| The payment button fails in a supported browser | Yes | An agreed scenario is broken |
| Discount calculated incorrectly versus the spec formula | Yes | Code does not match requirements |
| You need a new report or filter | No | This is a new feature |
| An integration broke because a third-party service changed its API | Usually not | The environment changed, not the code |
| The host upgraded PHP or Node.js and the site stopped working | Usually not | Infrastructure change outside the contractor's control |
| A client employee edited code or settings and broke something | No | Third-party interference |
| Slow performance under a load that was specified in the spec | Yes | A non-functional requirement is not met |
The grey zone is environment changes: updates to operating systems, browsers, third-party libraries and APIs. It helps when the contract lists supported versions and platforms explicitly. Then it is clear that a bug in an iOS version released after delivery is not a defect but an adaptation.
How long a warranty usually lasts
There is no single standard. In practice, terms range from one month to a year, most often a few months. The term depends on:
- system complexity — more scenarios and integrations mean rare bugs take longer to surface;
- usage frequency — if a feature runs once a quarter, a bug in it may only appear months later;
- contract terms — a longer warranty is sometimes priced into the project;
- who runs the server — if the client manages infrastructure after delivery, the warranty usually covers code only.
What matters is not only how long, but when the clock starts: on signing the acceptance act, on production launch or on the start of real use. Put this in writing.
Warranty vs support contract
| Parameter | Warranty | Support contract |
|---|---|---|
| Payment | Included in the project price | Separate, usually monthly or hourly |
| Covers | Defects only | Defects, updates, monitoring, agreed improvements |
| Duration | Limited | As long as the contract runs |
| Response time | Often unspecified | Usually fixed by an SLA |
| Environment changes | Usually not | Yes, one of its main purposes |
A warranty is a promise to fix your own work. Support is a service that keeps the system running while the world around it changes.
How to put the warranty in the contract
- Define what counts as a defect, ideally by referencing the spec and acceptance criteria.
- State the term and the start date.
- Describe how to report issues: where to write and what to attach (steps to reproduce, screenshots, time).
- Set response times, at least for critical bugs that block the main scenario.
- List exclusions: third-party interference, environment changes, misuse.
- List supported platforms: browsers, OS versions, devices.
Common client mistakes
- Saving up issues until the end of the warranty. Report bugs right away; they are easier to reproduce and fix.
- Presenting new wishes as bugs. It damages the relationship and ends in a dispute anyway.
- Not using the product after acceptance. A warranty only works if bugs are found.
- Handing the code to another team during the warranty without discussing it. After someone else's changes, the contractor may reasonably withdraw its obligations.