Warranty Boundary

The line is simple: our defects are warranty; new requests and changes are billable. Drawing it clearly at intake protects both the relationship and the margin.

Go-live to paid support

timeline
  title Warranty timeline
  Go-live : Handover on final payment
  Day 0 to 30 : 30-day bug-fix warranty : our defects fixed free
  After Day 30 : Paid support retainer : business-hours SLA

Warranty vs. billable

It is warranty when…	It is billable when…
A delivered feature doesn’t meet its agreed acceptance criteria.	The client wants new behavior not in the signed SOW.
A defect in our code, within 30 days of go-live.	A change to already-accepted, working behavior.
A regression we introduced.	Environment, third-party, or client-side changes outside our build.

Caution

Warranty covers our defects, not new scope. “It would be better if…” is a change request, not a bug — route it as billable even inside the 30 days.

Handover is tied to final payment

Code and credentials (repo access, Key Vault secrets, deployment keys) hand over on final payment, not before. The 30-day warranty clock starts at go-live/handover. For where this sits in the sequence, see The Whole Picture (SDLC).

How to log and route

flowchart LR
  Req["Incoming request"] --> Tri{"Our defect<br/>within 30 days?"}
  Tri -- Yes --> Bug["Bug — warranty<br/>expedite lane, free"]
  Tri -- No --> Bill["Change request<br/>billable, estimate + backlog"]

• Warranty defect → bug work item, expedite lane, no charge. See Support Model.
• Billable change → change request; estimated, added to the backlog, scheduled under the retainer or a new SOW.