developer.law / Knowledge
"What happens if it breaks after you deliver it?" The honest answer depends entirely on what your contract says.
A software warranty is a written promise by the developer that the delivered software will perform as described for a defined period of time. It is not a promise that the software will be perfect, uninterrupted, or error-free forever — it is a narrower commitment: the code will conform to the agreed specifications and was delivered with workmanlike skill. If a covered defect surfaces within the warranty window, the developer remedies it at no additional charge. After the window closes, ongoing support becomes a separate, billable engagement.
Developers and clients often conflate the warranty with broader support obligations, but they're legally distinct. The warranty is a finite, post-delivery promise tied directly to the original build. A support or maintenance agreement is a separate, typically paid arrangement that begins when the warranty ends — getting that distinction in writing is one of the most protective moves a small dev agency can make.
Clients are more legally sophisticated about software contracts than they were five years ago. Procurement teams at even mid-sized companies push for longer warranty windows, broader defect definitions, and vague language that can be stretched to cover feature requests or scope changes months after delivery. For independent developers without in-house counsel, a loosely worded warranty clause is one of the most common sources of post-project disputes.
At the same time, the technical environment around any piece of software changes faster than ever. Browser updates, API deprecations, OS patches, and third-party outages can all affect how software performs, even when the code itself is flawless. A warranty written without clear exclusions can make the developer responsible for every downstream breakage — even the ones caused entirely by changes outside the codebase.
Most warranty disputes don't start as legal disputes. They start as an email that says "the feature isn't working" six months after delivery. Without a precise clause, there's no documented basis for saying whether fixing it is covered, billable, or even the developer's responsibility at all.
A limited warranty should make two core promises and nothing more: that the software conforms to the written specifications the parties agreed on, and that the work was performed in a workmanlike and professional manner. Scoped, objective, documentable commitments that tie the warranty directly to what the developer actually agreed to build.
The market range for custom software warranty periods runs 30 to 90 days from delivery or acceptance. 30 days is the most common standard for projects with a defined acceptance phase, where the client has had formal opportunity to test and sign off before the warranty clock starts. 60 days is a reasonable compromise for more complex deployments or enterprise clients who need additional runway. 90 days is at the upper end of what most agreements offer without moving into paid support territory.
The logic behind the 30-day floor is straightforward: if a defect exists in the delivered code, it will almost certainly surface within 30 days of active use. Defects that only appear months later are frequently caused not by the original code but by environmental changes, third-party integrations, or client-side modifications. A 30-day window is long enough to catch genuine defects and short enough to prevent the warranty from becoming an indefinite support obligation masquerading as a free service.
Government procurement contracts sometimes run warranty periods as long as 180 days, and enterprise agreements occasionally reach 12 months — but those are outliers backed by higher contract values, formal acceptance testing regimes, and staffed support operations. For a small or mid-size agency, 30 to 90 days is commercially standard and legally defensible.
Exclusions are the half of the clause most developers either skip entirely or write too vaguely. Without them, the warranty's time limit means very little, because the client can still argue any performance issue falls within scope.
One of the most important structural decisions in a software contract is defining what happens after the warranty period ends. The warranty is what the client gets as part of the original project fee — a finite window of defect remediation. A paid support or maintenance retainer is the separate, ongoing arrangement that governs everything after that window closes.
The two serve different purposes. The warranty asks a narrow question: did the developer deliver what they agreed to deliver? Support and maintenance ask a broader one: how do we keep this software running as the technical environment around it evolves? A warranty isn't a substitute for support, and a support agreement isn't a substitute for a warranty — both belong in the contract if ongoing support is expected.
For agencies that want to offer post-warranty support, a separate SLA retainer is the right mechanism — response time commitments, escalation paths, scope of covered work, and a fee structure, typically a monthly retainer or a percentage of project cost per year. Keeping it entirely separate from the warranty section prevents support obligations from being read back into the warranty period as unlimited free work.
The following is representative clause language illustrating how a limited warranty, disclaimer, and sole-remedy provision can be structured in a custom software development agreement. It is for illustrative purposes only and should be reviewed in the context of your specific project and jurisdiction.
The reference table below maps each element of that clause back to what it does and why it's there.
| Clause Element | What It Does | Why It Matters |
|---|---|---|
| Limited warranty scope | Promises conformance to written specs and workmanlike performance | Anchors the warranty to the agreed deliverable, not to expectations |
| Warranty period (30-90 days) | Sets the clock from delivery or acceptance | Creates a finite obligation and prevents indefinite free support |
| Defect definition | Defines a defect as a failure to conform to specs | Excludes feature requests and undocumented expectations |
| Exclusions | Carves out third-party services, client modifications, environment changes | Removes liability for failures outside the developer's control |
| Disclaimer of implied warranties (ALL CAPS) | Expressly waives implied warranties of merchantability and fitness | Required to be legally effective under the UCC; must be conspicuous |
| Sole-remedy language | Limits the client's remedy to repair or re-performance | Prevents a warranty breach from becoming a damages claim |
| Warranty-to-support transition | Defines what happens after the warranty ends | Separates the free warranty period from paid ongoing support |
developer.law generates software development agreements with all of the provisions in this guide already built in: a limited warranty tied to written specifications, a defined 30-to-90-day window, precise exclusions, an all-caps implied warranty disclaimer, and sole-remedy language that limits the client's recourse to repair or re-performance.
A: A written promise that the delivered software will conform to the agreed specifications for a defined period after delivery or acceptance. It is a finite, scoped commitment, not an open-ended support obligation. developer.law builds limited warranty clauses into its agreements that specify the warranty period, the defect standard, the exclusions, and the sole remedy available if a covered defect is found.
A: Yes — 30 days is the recognized industry standard for custom software projects with a formal acceptance phase. Genuine defects in delivered code almost always surface within 30 days of active use; issues that appear later are typically caused by environment changes, third-party updates, or client modifications rather than defects in the original build.
A: A warranty disclaimer expressly waives the implied warranties that would otherwise attach to a software contract by default under the UCC, including merchantability and fitness for a particular purpose. To be legally effective, the disclaimer must be conspicuous — meaning it visually stands out from the surrounding text — and all-capital letters are the standard, court-recognized way to satisfy that requirement.
A: A warranty is a finite, no-cost obligation tied to the original build: you fix defects that trace back to the delivered work during the defined window. A support or SLA retainer is a separate, paid, ongoing arrangement covering defect remediation, adaptive maintenance, and environment changes after the warranty ends. The warranty answers whether you delivered what you promised; the support agreement answers how the software gets kept running after that.
A: Client modifications to the codebase, failures caused by third-party services or integrations outside the developer's control, changes to the client's operating environment after delivery, new feature requests not in the original specifications, misuse or unauthorized use, and force majeure events. These are standard in commercial software agreements and enforceable when the contract language is precise.
A: A provision limiting the client's remedy for a warranty breach to repair or re-performance of the defective work. Without it, a client who successfully claims a breach may argue for damages beyond the cost of fixing the defect — lost profits, business interruption, other consequential losses. Combined with a limitation of liability clause, it's one of the most important financial protections a development agency can include.
We're lawyers, remember? Please read this important note:
Story LLP is a law firm, and Story's lawyers built Aegis to deliver better, standard legal services at scale so founders can choose between top-tier specialized lawyers and standardized process automations that replicate those lawyers according to their needs and budget. By definition, a standardized process may not be perfect for you. Please review our Policies page to better understand the difference, as well as how we use AI and how we manage conflicts, privilege, etc.
As a law firm, we must screen clients for conflicts of interest, and we treat all correspondence with clients seeking legal advice as privileged and confidential to the maximum extent possible in consideration of any conflicts. However, Story's law firm or our Attorney Allies do not represent you or your company as your lawyer, do not have an attorney-client relationship with you or your company, and do not provide you with legal advice absent a formal Engagement Letter signed between you and the Story LLP law firm. Please don't confuse the free knowledge we offer on this site with legal advice for you.