Warranty and support terms to require from a dev agency
Before you sign with a dev shop, pin down the 2026 warranty window, support terms, and escrow. Story.law walks a founder through each clause to negotiate.
Most founders focus on scope, price, and launch dates when they hire a development agency. Warranty and support terms typically get skimmed or accepted as-is. That is a mistake. The warranty clause governs what happens after delivery, which is exactly when you are most exposed: the agency has been paid, your team is heads-down on the next sprint, and the first production bugs are surfacing. This guide walks you through what a dev agency warranty actually covers, where its limits are, and what to negotiate before you sign. It also covers support retainers, SLA terms, source code escrow, and knowledge transfer, the pieces that protect you when the relationship eventually ends. Story.law works with founders and growing companies to draft and negotiate development agreements that hold up in the real world, not just on paper.
What a Dev Agency Warranty Actually Covers
A warranty in a software development agreement is a formal promise by the agency that the delivered code will perform as specified for a defined period after acceptance. The practical scope of that promise is almost always narrower than founders expect. Understanding the boundaries before you sign determines whether you negotiate more protection or pay for it separately through a support retainer.
What the Warranty Promises and What It Does Not
The standard warranty in most agency contracts promises that the software will perform according to the agreed specifications and be free from material defects for a limited window after delivery. What it does not promise: that the software will do everything you wished it did, that it will perform flawlessly under unanticipated load, that third-party integrations will stay compatible, or that new browser versions or operating system releases will not break functionality. Those failure modes fall outside the defect warranty. If you want coverage for environmental drift or compatibility maintenance, that belongs in a separate support or maintenance retainer, not the warranty clause.
The remedy offered under most agency warranties is also narrow: repair. The agency agrees to fix code that fails to meet the agreed spec. Replacement of deliverables is unusual. Refunds tied to warranty failure are rare, and courts in most jurisdictions will not imply a right to a refund when the contract specifies repair as the sole remedy. That limitation is enforceable. If your deployment timeline or business continuity requires a stronger remedy, negotiate it explicitly before signing, not after a bug causes downtime.
Why Acceptance Criteria Are Your Real Protection
The warranty clause is not your first line of defense against a bad build. Acceptance criteria are. If your contract lacks precise, testable acceptance criteria, the warranty starts from an ambiguous baseline, and every post-launch dispute becomes an argument about whether the software ever conformed to the spec in the first place.
Acceptance is where contract theory meets project reality. It determines when the developer has earned payment, when you can reject work, and whether a defect gets fixed within scope or turned into a new paid request. Good acceptance language sets a review window giving you a defined number of business days to test and respond, requires written rejection reasons citing unmet requirements or failed test cases, creates deemed acceptance if you stay silent beyond the window, and separates defects from changes. Failure to meet the agreed spec is a remediation obligation. A new capability you want added is a change order.
Define severity categories in your acceptance testing framework: Critical defects that cause system crashes or data loss justify rejection of a milestone. Low-severity issues like cosmetic inconsistencies should not block acceptance or consume warranty hours. Link those severity levels to cure timelines in the warranty clause, and you have a mechanism that is both enforceable and operationally sensible.
Negotiating the Warranty Window
The industry norm for a free bug-fix period after software delivery is 30 to 90 days post-acceptance. That range reflects typical agency practice, not what you actually need to discover the defects that matter. The first 30 days after launch are often quiet ones: usage is low, edge cases have not been triggered, and integration failures have not yet surfaced under real load.
What the Market Offers vs. What You Should Ask For
Most agency contracts offer 30 to 90 days as the default warranty period, framed as a standard term rather than a negotiated one. Treat it as a starting point. A 90-day window tied to acceptance date (not launch date) is a reasonable minimum ask for a project of meaningful scope. Some founders negotiate 120 to 180 days when the launch is phased or the user base ramps slowly. The agency's counter-argument will be that a longer window creates open-ended liability for bugs you could have caught earlier. That is a legitimate position. The right response is to pair a longer window with a clear process: defects must be reported in writing, must be reproducible, and must be traceable to the original specifications. That structure gives you a longer window without creating an indefinite repair obligation.
One critical detail that frequently gets missed: confirm whether the warranty clock starts at delivery or at acceptance. If the agency delivers on day one and your acceptance testing takes three weeks, a 60-day warranty that starts at delivery gives you roughly 39 usable days after you formally accept the build. Negotiate the start date explicitly.
Clauses That Can Void Your Warranty
Almost every agency warranty includes exclusions that can void coverage if you trigger them. The most common: unauthorized modifications to the delivered code. If your internal developer or a third party changes the codebase during the warranty period, the agency will argue that any defect could have been introduced by your modification, not their original work. You need a process for emergency patches during the warranty window, ideally one that requires written notice to the agency before you touch production code. Other standard exclusions include defects caused by your infrastructure, data corruption originating outside the application, and failures caused by third-party services the agency did not build or control. Read the exclusions clause carefully. Each one is a gap in your coverage.
Defect vs. Feature Request: Drawing the Line in the Contract
The most common post-launch dispute between a company and its dev agency is not about bugs at all. It is about classification. You call something a defect. The agency calls it a feature request. Without a contractual definition anchored to the original specifications, that argument has no clean resolution.
A defect is any failure of the software to perform a function described in the agreed specifications. A feature request is a capability, behavior, or enhancement not described in those specifications. The distinction sounds clean in theory. In practice, vague scope documents make it genuinely ambiguous. If your spec said "users can upload files" and did not specify a size limit, format restriction, or error handling behavior, the agency has a reasonable argument that any behavior around those parameters is within spec. Your counter-argument is weaker than it should be.
The practical fix is drafting both functional and non-functional requirements into your acceptance criteria before the build begins. Include performance benchmarks, error handling expectations, browser and device compatibility requirements, and security posture requirements. Everything in the spec is a potential defect if not met. Everything outside the spec is a change order. That line, drawn clearly before a line of code is written, is what makes the warranty meaningful.
Implied Warranty Disclaimers: What to Expect and Where to Push
Every professional agency agreement you receive will include a broad disclaimer of implied warranties. You will see language along the lines of "except for the limited warranty set forth herein, the software is provided as-is." This is standard. You should not be surprised by it, and in most B2B contexts it is enforceable.
Implied warranties under the UCC, specifically the implied warranty of merchantability and the implied warranty of fitness for a particular purpose, exist to protect buyers when a seller knows the buyer is relying on the seller's judgment to select something suitable. In a custom development engagement where you have written the spec, hired the agency, and defined the scope, the fitness-for-purpose argument is weaker than in a commercial software purchase. That is why agencies disclaim implied warranties, and why courts in most jurisdictions uphold those disclaimers in B2B contracts where the language is conspicuous and the parties are commercially sophisticated. The enforceability of these disclaimers in software specifically remains somewhat unsettled because courts disagree about whether software fits within the UCC's goods framework, but in practice the disclaimer is treated as enforceable in the overwhelming majority of commercial dev agency relationships.
Where you can push: you can ask the agency to warrant that the software does not infringe third-party intellectual property rights, including open-source license compliance. That is a separate and distinct warranty from the defect warranty, and it is a meaningful one. If the agency used a GPL-licensed library improperly or copied code from a prior client's project, you are the one who owns and deploys the product. The infringement exposure lands on you. A non-infringement warranty, backed by an indemnification obligation for IP claims, is a reasonable ask and not unusual in professionally drafted agreements.
When to Buy a Support Retainer Instead of Arguing for a Longer Free Window
There is a limit to how much free warranty coverage you can negotiate, and pushing too hard on the warranty window can produce a worse outcome than simply paying for a structured support arrangement. A post-launch support retainer gives you something a warranty does not: a defined, ongoing relationship with committed response times, rather than a reactive repair obligation that the agency may deprioritize once they have moved on to the next client.
What a Support Retainer Actually Buys You
A software development retainer is a monthly engagement where you pay a fixed fee for ongoing access to the development team. Rather than commissioning a single project with a defined end date, you retain capacity that covers maintenance, bug fixes, infrastructure improvements, and in some cases feature development. The model exists because most digital products continue evolving after launch, and a fixed-project engagement does not accommodate that reality. A retainer gives that ongoing work a stable, predictable structure instead of forcing you to negotiate a new engagement every time a production issue requires attention.
For a retainer to be worth paying, it needs to include specific SLA commitments tied to issue severity. Response time commitments should be differentiated: a critical bug that takes down core functionality warrants a faster first response than a minor cosmetic inconsistency. Typical tiering looks like a four-hour response window for P1 critical issues affecting core functionality, next-business-day response for P2 issues causing significant degradation without a complete outage, and a 48-to-72-hour window for lower-severity items. Without those tiers written into the retainer agreement, "support" is just a monthly fee for an informal relationship that may or may not produce timely help when you need it.
Covered Work vs. New Development in a Retainer
A support retainer is not a blank check for new features. Corrective and adaptive work, fixing what exists to match its original specification or to remain functional in a changed external environment such as a new API version from a third-party service, falls within maintenance. Expanding functionality, redesigning user flows, or adding integrations not present at launch constitutes new development and should be governed by a separate work order. That line matters for budget predictability and for keeping the retainer from becoming a loosely managed time-and-materials arrangement with no accountability. Require the retainer agreement to define covered work categories explicitly, and require a change-order process for anything that falls outside them.
Clause-by-Clause: What to Review and What to Negotiate
The table below maps the key warranty and support clauses, describes what the standard agency position looks like, and identifies where you have realistic leverage as the buyer.
| Clause | Standard Agency Position | Your Ask (Negotiation) |
|---|---|---|
| Warranty period | 30 to 90 days from delivery | 90 to 180 days from acceptance, not delivery |
| Covered defects | Failures to conform to spec | Define spec attachment as the reference document; include non-functional requirements |
| Sole remedy | Repair only | Repair first; if uncured within a defined period, the right to engage a third party at agency's cost |
| Implied warranty disclaimer | Full AS-IS disclaimer for everything beyond express warranty | Accept disclaimer; push for a carve-out keeping the non-infringement warranty |
| Warranty voiding conditions | Any modification by client voids coverage | Require notice process for emergency patches; limit voiding to modifications that could plausibly cause the reported defect |
| Post-warranty support | Optional paid engagement with no committed terms | Require a retainer option with SLA tiers attached before signing the initial engagement |
| Defect severity tiers | Not defined or informally described | Define P1 through P3 in writing with response and resolution targets |
| IP non-infringement warranty | Often absent or boilerplate | Require express warranty plus indemnification obligation for third-party IP claims |
| Source code escrow | Not offered | Require for any build where the software is operationally critical |
| Knowledge transfer | Not addressed | Require delivery of documentation, build scripts, credentials, and architecture diagrams at project close |
Source Code Escrow and What Happens If Your Agency Disappears
The warranty is useless if the agency closes, is acquired, or simply stops responding after the engagement ends. That risk is not hypothetical: a significant number of boutique development shops change materially within three to five years of any given project. If your business depends on software that only the agency knows how to maintain, a lapsed relationship does not just create inconvenience. It can strand you operationally.
How Source Code Escrow Works
A source code escrow agreement is a three-party contract between you as the beneficiary, the development agency as the depositor, and a neutral third-party escrow agent. The agency deposits the source code, documentation, database schemas, build scripts, and related materials with the escrow agent. If predefined trigger events occur, such as the agency's bankruptcy, a sustained failure to provide agreed support, or dissolution of the company, the escrow agent releases those materials to you. That ensures you can continue operating, maintaining, and updating the software even without the original agency's cooperation.
The deposit materials matter as much as the agreement itself. A well-scoped escrow deposit includes not just the source code but also database schemas, configuration files, build and deployment scripts, third-party dependency lists, and API documentation. A deposit that contains only the raw source code without those supporting materials may be technically complete but operationally useless: another developer receiving the code cannot build and deploy it without the rest of the package. Require a complete deposit specification as an exhibit to the escrow agreement, and require the agency to update the deposit on a defined schedule, typically quarterly or at each major release.
Knowledge Transfer as a Parallel Obligation
Escrow addresses the scenario where the agency is gone and you need the assets. Knowledge transfer addresses the scenario where the agency is still present but the relationship is winding down. The two are complementary protections. If you plan to maintain the software internally or hire a different vendor for ongoing support, your contract should require the agency to provide complete documentation and knowledge transfer. This includes technical documentation, source code comments, architecture diagrams, environment specifications, and training sessions for your team.
When an engagement ends, you need your code, documentation, credentials, and knowledge. Without a transition clause, you are at the vendor's mercy on timeline and completeness. The contract should specify a transition period, typically 30 to 90 days, during which the agency provides access to key personnel who were involved in the build, answers technical questions, and completes documentation handoff. Tie final payment holdbacks or milestone releases to completion of the knowledge transfer obligations. That creates an incentive structure where the agency has a financial reason to complete the handoff properly rather than treating it as an afterthought.
Best Practices and Expert Guidance for Warranty and Support Negotiations
Negotiating warranty and support terms is most effective when you approach it as a systems problem, not a clause-by-clause redline. Story.law advises founders and growing companies to treat the warranty conversation as part of the pre-signature due diligence on the agency, not a last-minute negotiation after you have already committed to the engagement.
Anchor the warranty to a signed specification, not an SOW summary. The warranty is only as strong as the document it references. If your Statement of Work describes features in general terms without testable acceptance criteria, the agency's warranty promises very little. Before you negotiate the window length or the remedy clause, make sure the underlying specification is detailed enough that a defect is objectively identifiable.
Define defect severity tiers before you launch, not after. Severity tiers written into the contract prevent the most common post-launch dispute: whether a given issue is urgent enough to require an emergency response. Agree on the definitions at signing, including what constitutes a P1 issue, what the agency's first-response commitment is, and what escalation looks like if the agency misses it.
Do not sign a support arrangement without written SLA terms. An informal agreement to be available for support after launch is not an SLA. It is a social commitment with no enforcement mechanism. If you are paying for a retainer, require a retainer agreement with response time commitments, covered scope definitions, and a process for handling work that falls outside the scope.
Require the non-infringement warranty and pair it with an indemnification obligation. The agency knows what third-party code went into your build. You do not. If they used improperly licensed open-source components or code from a prior engagement, the exposure lands on you. A non-infringement warranty plus an indemnification obligation for third-party IP claims transfers that exposure back to the party with actual knowledge.
Negotiate a cure window before you can engage third parties. The typical warranty allows only repair by the original agency. If the agency cannot or will not fix a critical defect within a reasonable cure window, you need the right to hire another developer and charge the cost back. That right does not exist by default. It needs to be written in.
Require knowledge transfer obligations to be tied to payment milestones. Documentation, architecture diagrams, and credential handoffs tend to slip to the bottom of the agency's priority list after the project is delivered and final payment is processed. Structure a portion of final payment, or a defined holdback, as contingent on completion of the knowledge transfer deliverables.
Assess whether escrow is warranted based on operational dependency. Source code escrow is not necessary for every project. For software that is not operationally critical or that you could replace within a reasonable timeframe, the cost of a formal escrow arrangement may not be justified. For software that becomes core infrastructure, that processes payments, that stores customer data, or that your product depends on to function, escrow is a basic continuity protection. Make that assessment before signing, not after the agency has delivered.
Advantages of Getting Warranty and Support Terms Right Before Signing
The difference between a well-negotiated warranty and a standard agency warranty is not just legal protection on paper. It produces concrete operational outcomes.
Clarity about what you own. A warranty anchored to a precise specification tells you exactly what the agency promised to deliver. That specificity transfers to your acceptance testing, your bug reports, and your internal documentation. You know what the agency built versus what you asked them to build versus what you still need.
Faster defect resolution. Defined severity tiers and cure windows create accountability that an informal relationship does not. When the agency knows that a P1 defect triggers a four-hour response obligation backed by contract language, the escalation path is clear. Without that structure, every urgent issue becomes a negotiation.
Operational continuity if the relationship ends. A knowledge transfer clause and a source code escrow arrangement mean that a lapsed agency relationship does not strand your product. Another developer can pick up the build, understand the architecture, and maintain the software without starting from scratch.
Budget predictability after launch. A structured support retainer with a defined scope and SLA commitments gives you a predictable post-launch cost. The alternative, negotiating emergency support on a time-and-materials basis each time an issue arises, is almost always more expensive and slower.
Protection from IP exposure. A non-infringement warranty with an indemnification obligation means that if the agency's code carries a third-party IP claim, the financial exposure starts with them, not with you. That is a material protection for any company that intends to raise capital, be acquired, or simply operate without the risk of a copyright or license claim against its core product.
Final Thoughts: What to Do Before You Sign Your Next Dev Agreement
The warranty clause in a dev agency contract is not your primary protection against a bad build. Your acceptance criteria are. The warranty is what happens when something slips through. It is narrow by design, short by default, and limited to repair as the sole remedy unless you negotiate otherwise. The practical value of the warranty depends entirely on the quality of the underlying specification it references.
Before you sign your next development agreement, work through this checklist: confirm the warranty start date is acceptance, not delivery; confirm the covered defects are defined against an attached specification with testable acceptance criteria; check the warranty exclusions for modification-related voiding and negotiate a notice process for emergency patches; require the non-infringement warranty and an indemnification obligation; define defect severity tiers and cure windows in the contract; negotiate either a longer warranty window or a structured support retainer with SLA commitments at signing; and require knowledge transfer obligations tied to a payment milestone.
If the software is operationally critical, require source code escrow as a condition of the engagement. The escrow deposit should include not just source code but all materials another developer would need to build, deploy, and maintain the product without agency assistance.
Story.law can help you generate, review, and negotiate a development agreement that covers all of these terms before you sign.
How Story.law Helps Founders Negotiate Development Agreements That Hold
Story.law was built for exactly the problem this guide addresses. Most founders do not have the time or the legal background to evaluate a warranty clause, identify what is missing from a support retainer, or know whether a knowledge transfer provision is actually enforceable as written. Story.law bridges that gap with lawyers who understand how software is built, what agencies actually deliver, and where the contractual gaps tend to show up.
Story LLP’s approach is practitioner-first: the goal is not to produce a redline that impresses other lawyers but to produce a contract that protects you in the situations that actually arise. That means focusing on the clauses that matter, the warranty scope, the defect definition, the cure window, the escrow trigger conditions, and the knowledge transfer obligations, while accepting standard market terms where they do not create meaningful risk. The Aegis platform allows founders to move quickly on agreement review and generation, backed by lawyers who have negotiated these terms across dozens of development engagements.
For regulated industries, healthcare, fintech, or any product handling personal data, the warranty and support structure intersects with compliance obligations. Organizations with compliance requirements need formal SLA terms because audit documentation must demonstrate that security incidents and vulnerabilities are addressed within defined time windows. Story LLP’s team has the background to structure those agreements in a way that satisfies both the business relationship and the compliance record.
FAQs About Dev Agency Warranty and Support Terms
What is a warranty in a software development agreement?
A warranty in a software development agreement is a formal, time-limited promise that the delivered code will perform according to the agreed specifications and be free from material defects. Most agency warranties are narrow: they cover repair as the sole remedy, run for 30 to 90 days from delivery or acceptance, and exclude defects caused by your modifications, your infrastructure, or third-party services the agency did not build. Story.law helps founders understand exactly what their warranty covers before they sign, not after a post-launch dispute reveals the gaps.
How long should a development agency fix bugs for free?
The industry norm is 30 to 90 days post-acceptance, but the right window depends on your launch timeline and expected ramp. A phased rollout or a slow user ramp may mean material bugs do not surface until well after a 30-day window has closed. Story.law advises negotiating 90 to 180 days from formal acceptance, paired with a clear defect reporting process, rather than simply accepting the agency’s default. The window length matters less than making sure the start date is tied to acceptance, not delivery, and that the covered defects are defined against a precise specification.
Should I pay for a support retainer after a software project ends?
For most software products, a support retainer is a better post-launch structure than arguing for a longer free warranty window. A retainer gives you committed response times, a defined scope of covered work, and a structured relationship rather than a reactive repair obligation the agency may deprioritize once the project is closed. A retainer agreement should include SLA tiers tied to defect severity, a clear definition of covered work versus new development, and a change-order process for feature requests. Story.law can help you structure a retainer agreement that provides real accountability, not just a monthly fee for an informal relationship.
What happens if my dev agency disappears after launch?
If the agency closes, is acquired, or stops responding, a source code escrow arrangement is what protects you. The escrow places your source code, documentation, build scripts, database schemas, and related materials with a neutral third party. If a defined trigger event occurs, such as the agency’s bankruptcy or failure to provide agreed support, the escrow agent releases those materials to you. Without escrow, a lapsed agency relationship can leave you unable to maintain or update software your business depends on. Story.law recommends escrow for any build that becomes operationally critical.
What is the difference between a defect and a feature request in an agency contract?
A defect is any failure of the software to perform a function described in the agreed specifications. A feature request is a capability not described in those specifications. In practice, the distinction depends entirely on how precisely the specification was drafted. Vague scope documents make every post-launch disagreement about whether the software is broken or simply incomplete. Story.law builds acceptance criteria into development agreements that define covered functionality with enough specificity that the defect-versus-feature-request line is objectively traceable to the contract, not subject to post-delivery negotiation.
Are implied warranty disclaimers enforceable in dev agency contracts?
In most B2B software development engagements, yes. Agencies routinely disclaim implied warranties, including the implied warranty of merchantability and the implied warranty of fitness for a particular purpose. Courts in most jurisdictions uphold these disclaimers when they are conspicuous and the parties are commercially sophisticated. The enforceability of implied warranty disclaimers for software specifically has some jurisdictional variation because courts disagree about whether software fits neatly within the UCC’s goods framework. What you should focus on negotiating is not the implied warranty disclaimer, which is standard and broadly enforceable, but a strong express warranty tied to your specification and a non-infringement warranty with an accompanying indemnification obligation.
What should a knowledge transfer clause include?
A knowledge transfer clause should require the agency to deliver complete source code, technical documentation, architecture diagrams, build and deployment scripts, environment specifications, third-party dependency documentation, and credentials for any services or accounts related to the project. It should also require access to key personnel who worked on the build for a defined transition period, typically 30 to 90 days, during which they answer technical questions and complete the handoff. Story.law recommends tying a portion of final payment to completion of the knowledge transfer deliverables to create a financial incentive for thorough and timely handoff.
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.