Scope note: Contract terminology, remedies and time limits depend on the signed agreement and applicable law. Use this guide to structure the commercial review and obtain current legal advice for a live dispute.

Agree what must be proven before sign-off

A defect liability period is a fixed window after a web application has been formally accepted, during which the development supplier is obliged to fix certain problems at no additional charge. In construction, the equivalent is a snagging list; in software, it is a mechanism for dealing with bugs that were present in the delivered work but only surfaced after go-live.

The concept sits between two other project stages. Before it comes user acceptance testing and formal sign-off. After it comes whatever ongoing support or maintenance arrangement has been agreed separately. The defect liability period is not a support contract. It is a time-limited warranty on the quality of the build itself.

What counts as a defect

A defect, in this context, means the application does not behave as described in the agreed specification or acceptance criteria. If the contract stated that a customer portal should allow users to download invoices as PDFs and the button produces an error instead, that is a defect. If the business later decides it would also like CSV exports, that is a change request, not a defect — even if it feels like a small addition.

This distinction matters because disputes commonly arise from exactly this boundary. The supplier sees a new requirement; the client sees a broken promise. The clearer the acceptance criteria were before sign-off, the less room there is for that disagreement during the liability period.

How the period is triggered

The defect liability period does not start when the supplier says the work is finished. It starts when the client formally accepts the deliverables against the agreed criteria. If acceptance is delayed because the client has not completed user acceptance testing, the clock has not started. If the client signs off while knowing that certain items are incomplete, those items may be excluded from the liability period unless the contract says otherwise.

The trigger mechanism should be written into the contract. A simple email confirming acceptance is common, but some agreements require a signed acceptance document. Without a clear trigger, both sides can end up arguing about when — or whether — the period began.

What is typically excluded

Most defect liability clauses exclude problems caused by factors outside the supplier's control. Common exclusions include issues arising from changes made by a third party, failures in third-party services or APIs that the supplier does not operate, problems caused by the client modifying the hosting environment, and anything that results from the client's own data being malformed or incomplete.

Security vulnerabilities discovered during the period can sit in a grey area. If the vulnerability existed because the supplier did not follow the security practices outlined in the specification, it is arguably a defect. If the vulnerability relates to a newly disclosed weakness in an underlying framework that nobody could have foreseen, the position is less clear and depends on what the contract says about ongoing patching.

Negotiating the length of the period

The duration of a defect liability period is a commercial negotiation. There is no single correct length. A short internal admin tool with a small user base and straightforward workflows might reasonably have a shorter period than a customer-facing SaaS platform handling payments and personal data. What matters is that the length reflects the complexity of the system and the realistic time it will take for latent defects to surface under real usage.

Some suppliers offer a longer period in exchange for a higher project price. Others keep it short and expect the client to purchase a separate support package. Neither approach is inherently right or wrong, but the business needs to understand what it is paying for and what happens when the period ends.

Reporting and prioritising defects

The contract should set out how defects are to be reported and how they will be prioritised. A sensible approach is to categorise defects by severity — for example, critical defects that prevent a core function from working, moderate defects that cause incorrect behaviour in a non-critical area, and minor defects such as visual inconsistencies.

Response and resolution times can then be tied to those categories. A critical defect might require the supplier to begin investigation within a defined number of hours, whereas a minor defect might be batched into a scheduled release. Without this structure, the client may expect immediate action on every issue while the supplier treats everything as low priority.

How it works across different system types

For a custom CRM or internal business system, the defect liability period typically covers the core workflows, data handling and reporting that were specified. If the system replaces a spreadsheet and the calculated figures do not match the agreed logic, that falls squarely within the period.

For a customer portal, the period might cover login and registration, document access, messaging and any payment integration — but only to the extent those functions were part of the original scope. If the portal goes live and users report that uploaded documents occasionally fail to render, that is a defect. If the business then asks for a new document-approval workflow, that sits outside the period.

For SaaS products, the defect liability period is less common as a fixed post-launch window because the product is continuously evolving. Instead, SaaS development agreements often build quality obligations into an ongoing support and development retainer. Where a defect liability period is used for a SaaS MVP, it usually covers only the initial release and ends when the ongoing development cycle begins.

Relationship to acceptance criteria

The value of a defect liability period is directly proportional to the quality of the acceptance criteria that preceded it. If the acceptance criteria were vague — for example, "the system should be user-friendly" — then almost any complaint can be framed as a defect, and almost any defence can be framed as a subjective difference of opinion. If the criteria were specific and testable, the scope of the liability period is far clearer.

This is why the work done before sign-off matters more than the clause itself. A well-drafted defect liability provision with weak acceptance criteria creates more arguments than it resolves.

Vague definitions of "defect"

The single most common mistake is leaving the term "defect" undefined in the contract. When the clause simply says the supplier will fix defects for a set period, both sides are left to argue about what qualifies. The contract should reference the specification and acceptance criteria as the benchmark, and it should state explicitly that anything falling outside that benchmark is a change request subject to a separate charging arrangement.

Conflating the liability period with ongoing support

Some businesses assume that the defect liability period means they do not need a support arrangement. In practice, the liability period covers pre-existing faults. It does not cover new questions from users, minor adjustments to wording, new integrations, performance tuning under increased load, or upgrades to keep the software compatible with changing browser versions or API updates from third parties. Once the period ends, the business is entirely on its own unless a support agreement is in place.

A related mistake is assuming the supplier will monitor the system proactively during the liability period. Most defect liability clauses are reactive — the client reports a problem, the supplier investigates. If the business wants active monitoring, error logging review and performance checks, that needs to be specified and usually paid for separately.

Signing off too early

If the client accepts the work before thoroughly testing it, the defect liability period becomes the only safety net. That is a weaker position than catching problems before sign-off, because acceptance may carry legal weight — the client has confirmed the work meets the agreed criteria. A defect reported during the liability period that was clearly testable at the acceptance stage might be disputed by the supplier on the basis that the client should have caught it earlier.

Thorough user acceptance testing before sign-off is always preferable to relying on the defect liability period as a backstop.

No cap on liability period work

Some contracts impose no limit on the number of defects that can be raised during the period. In theory, a client could raise hundreds of minor issues and consume the supplier's capacity indefinitely. In practice, this leads to friction and delayed responses. A balanced approach is to allow unlimited critical and moderate defects but to cap minor or cosmetic items at a reasonable number, with anything beyond that treated as a separate piece of work.

No plan for what happens after the period

The defect liability period has a fixed end date. When it expires, the supplier's obligation to fix pre-existing defects ends with it. If the business has not arranged ongoing support by that point, any remaining or newly discovered issues will need to be scoped and quoted as new work — often at a higher rate than the original project because the supplier is no longer in an active delivery context.

The practical step is to start discussing post-liability support well before the period ends, not the week after it expires.

Key contract clauses to check

  • Definition of defect. Does it reference the specification and acceptance criteria, or is it left open to interpretation?
  • Trigger mechanism. What event starts the clock, and is that event clearly documented?
  • Duration. Is the length appropriate for the system's complexity and the time needed for real-world issues to emerge?
  • Exclusions. Are third-party failures, environment changes and client modifications explicitly excluded?
  • Reporting process. Is there a defined channel, format and severity classification for raising defects?
  • Response and resolution times. Are they tied to severity, and are they realistic?
  • Caps. Is there any limit on the volume of minor defects, or an overall effort cap?
  • Transition. What happens to unresolved defects if the period ends before they are fixed?
  • Relationship to support. Is it clearly stated that the liability period is separate from any ongoing support arrangement?

Keep the result reproducible

Contracts are matters requiring current specialist review. The points above indicate what to look for, but the final wording should be checked by someone qualified to advise on the specific agreement and circumstances.