A bug-free warranty is a promise to fix, at no charge, delivered code that does not work the way the written specification says, for a fixed period that starts on a written date. It does not promise software with no bugs, and it does not pay for new work. Most agencies give 30 to 90 days.
The length gets the attention, but the exclusions decide what you can claim. So do the start date and the rules that void coverage. A 12-month warranty with a vague spec can be worth less than a 90-day one with a tight spec.
We are The Gnar Company, so read our part knowing who wrote it. Here is our guarantee, word for word. Our Build page lists its three commitments. Three commitments on every build engagement: a fixed milestone price with any overage on us, a guaranteed outcome meaning the software works as specified or we fix it, and a twelve-month bug-free warranty. It covers Discovery, Build, Forge and Maintain. It does not cover Embed. On Compass, Immerse and Integrate, ask us. Discovery in it means Gnar Discovery and Design, our planning work before a build.
This guide is for the CEO or COO who was burned by a vendor that walked away after launch, and who now has a warranty clause in front of them. Every fact about another firm comes from that firm's own website, checked in November 2026.
What does a bug-free warranty promise?#
A bug-free warranty promises a repair of delivered code that fails the written spec, and in most agency warranties a repair is the only remedy. It is not a promise that nothing will ever break, and it does not include new feature work.
The law firm Story LLP describes the standard agency warranty this way: the software will perform to the agreed specifications and be free from material defects for a limited window. Its guide to agency warranty terms also lists what that promise leaves out. It does not promise the software will do everything you wished, perform flawlessly under load nobody planned for, stay compatible with outside services, or survive new browser and operating system releases.
Our own guarantee, quoted above, puts the promise as "the software works as specified or we fix it."
The same guide says the remedy is usually narrow. The agency repairs the code. Refunds tied to a warranty failure are rare.
Two terms in a warranty clause need a clear definition:
- Specification. The document the code is measured against. If it is vague, every argument about a bug becomes an argument about what you meant.
- Acceptance. The day you sign off on the delivery, or the day the contract treats it as accepted. Story LLP notes that some agency contracts deem a deliverable accepted after a short review window, often five to ten business days. Windows start at acceptance, at delivery or at launch, so ask which date your contract uses.
Story LLP's guide to dev agency contract terms says that without a warranty clause, the agency's obligation to fix bugs ends the moment you accept the deliverable.
How long do agency warranties last?#
Most agencies offer 30 to 90 days, and Story LLP calls that the industry norm. The firms below publish their terms on their own sites. The range runs from two weeks to twelve months, and the shorter windows are common.
| Firm | Published window | When it starts | What it says it leaves out |
|---|---|---|---|
| Chop Dawg | 30 days, included | At launch or final production build | New feature work, enhancements, redesigns, scope changes, third party platform changes that require new development |
| Codivox | 30 days | After launch | New feature work |
| AnvilEight | Up to 12 months; free tiers of 2 weeks, 1 month over $20,000 and 3 months over $50,000 | Not stated on the page | Anything not stated in writing; code it did not build from scratch; needs full server access |
| VulCode | 90 days standard; 30 on very small orders; 180 or 365 on bigger ones | Final acceptance | Functional changes, your own code changes, hosting |
| Horizon Labs | 6 months fixed price; 6 to 12 months hourly | After delivery | Scope changes, outside services changing their APIs |
| Clean Coders Studio | No window stated on its guarantee page | Not stated | Not stated |
| The Gnar Company | 12 months | Confirm the date in your contract | Feature additions and ongoing operational support |
Sources, each from the firm's own page: Chop Dawg, Codivox, AnvilEight, VulCode, Horizon Labs, Clean Coders Studio. Clean Coders Studio says its engineers fix any bugs they introduce at no cost, which is a different promise: no stated end date, tied to who introduced the bug.
Why the length matters: Story LLP notes that the first 30 days after launch are often quiet ones, because usage is low, edge cases have not been triggered, and integration failures have not yet surfaced under real load.
Think about what runs only once a quarter or once a year. A quarter-end report. A year-end close. A rate table that changes in January. A 30-day window can end before any of them run. Story LLP's suggested minimum ask on a project of real size is a 90-day window tied to the acceptance date. Some buyers negotiate 120 to 180 days when the launch is phased or use ramps slowly.
What should the warranty cover?#
A warranty should cover every way the delivered code can fail to do what the specification says. That includes the integrations and devices named in the scope. Use this checklist against the clause in your contract.
- Defects against the written spec. The clause names the spec document, by title and date, as the measure.
- Integrations in scope. If the scope says the software sends orders to your ERP, a failure in the delivered integration code is covered, but a break caused by the ERP vendor changing its side is not.
- The devices and browsers in the scope. If the scope names iPhone and Chrome, a failure of the delivered code on those devices and browsers is covered. Ask how new browser and operating system releases are handled.
- Security requirements in the spec. If the spec names a security requirement, a hole in the delivered code that breaks it is a defect.
- Data the code gets wrong. A report that adds a column twice is a bug, even if the screen looks fine.
- The fix is deployed. The firm deploys the fix to your production system and says what changed.
- A start date you can check. A start date the contract names in writing (acceptance, delivery or launch), so both sides know when the window ends.
- Coverage that does not depend on a support contract. The warranty should stand on its own if you stop paying for support or bring the work in house. Gnar's 12-month warranty is independent of any ongoing contract.
What does a warranty leave out?#
Warranties usually leave out new work and problems the firm did not cause. That is fair. The trouble starts when the exclusions are vague, because then they swallow the promise. Here is how the usual exclusions sort out, based on the published terms above.
| What happens | Usually covered? | Why |
|---|---|---|
| A screen crashes when a user does what the spec describes | Yes | The code fails the spec |
| An order from the new tool never reaches the ERP, and the integration was in scope | Yes | A scoped integration failed |
| You want a new field on a form | No | New scope; it needs a change order |
| Your own team edits the code and something breaks | Often no | VulCode's terms exclude client changes, and Story LLP says agency paper often voids coverage after any client change |
| The hosting provider goes down | No | Hosting is excluded; it belongs in a paid support plan |
| A payment or shipping service changes its API | No | An outside change; the code did not fail |
| A bug the firm wrote shows up after the window ends | No | The period is over |
VulCode's terms read close to this table. Its warranty page says the warranty does not cover functional changes, defects caused by the client's changes, or hosting and infrastructure issues. Chop Dawg's page says its warranty does not include new feature work, enhancements, redesigns, changes in scope or third party platform changes that require new development.
At Gnar, once the software is live there are two kinds of work: fixes under the warranty, and everything else under Maintain. The warranty covers code that doesn't work as specified. Feature additions and ongoing operational support are handled separately through Maintain, our optional monthly support retainer.
Who decides whether something is a bug?#
The written specification decides it, because it is the main reference both sides use for whether a problem is a bug or new work. If the software does not do what the spec says, it is a bug, and the warranty covers it. If the spec never said it, expect it to be treated as new work. A warranty is only as strong as the spec it is measured against.
AnvilEight's warranty page follows the same rule. Behavior that does not match the specification is a warranty case. Anything not stated in writing is not.
That is the honest rule, and it cuts against the buyer when the spec is thin. A two-page scope with ten bullet points leaves most behavior unwritten. Behavior the spec never wrote down is not a warranty case.
So the spec is written before the build. At Gnar that work is Gnar Discovery and Design. It is published at $15,000, $20,000 or $30,000 for two, four or six weeks, and it ends with a milestone plan and a fixed price for the build.
A good spec also helps you. When a bug report says "the step 4 approval should route to the regional manager, per section 3.2," the argument is short.
Does the warranty survive if you change vendors?#
Not always, because Story LLP notes that agency paper often says any change by the client voids coverage, so a new vendor's changes to the code can end coverage. A good warranty survives a change of vendor, and you should get that in writing.
Ask two questions:
- Does the warranty stand without a support contract? Our answer is written on our maintenance page: the 12-month warranty obligates us to fix non-conforming code, independent of any ongoing contract.
- What changes void it? Story LLP's suggested ask is to void coverage only for changes that could plausibly have caused the reported defect.
Code ownership matters here too. If the code sits in the vendor's account, it is harder to hand to anyone else, and the contract decides whether you can. Gnar's terms are that the codebase is yours, documented so your team can take ownership fast.
Is a warranty the same as a maintenance plan?#
No, a warranty and a maintenance plan pay for different things after launch. A warranty pays for the firm's own mistakes, for a set period. A maintenance plan is paid, ongoing support after launch. Outside changes, such as an outside service changing its API, sit outside the warranty at Horizon Labs and Chop Dawg, so ask how they are handled. You usually need both, and a good contract keeps them apart.
| Warranty | Maintenance plan | |
|---|---|---|
| What it pays for | Code that fails the spec | Ongoing support after launch; at Gnar, hosting, monitoring and support |
| Who pays | The firm | You, monthly |
| How long | A fixed window | As long as you keep it |
| Outside changes, such as a new API version | Not covered | Ask how they are handled |
| New feature work | Not covered | Ask whether it is included |
At Gnar, the plan is Maintain, from $1,000 a month, and it is optional. Our page for fixing AI-built apps describes it as a monthly support plan that covers hosting, monitoring and support. Gnar Forge, our fixed-price build for custom internal tools, includes a month of maintenance.
Whatever plan you buy, get its response times in writing. Story LLP's guide says a support retainer needs response times that differ by severity. Its typical set is four hours for critical issues that affect core functionality, next business day for significant problems that are not a full outage, and 48 to 72 hours for the rest.
What long-term care looks like in practice: after Gnar replatformed the AARP Foundation's Property Tax-Aide tools, Gnar maintained and updated the tools for every subsequent tax year, as the case study describes. For Fitbit, The Gnar Company maintained and improved Fitbit's legacy health coaching platform, Fitbit Plus, while Fitbit's own team built its replacement.
How does Gnar's warranty work?#
Gnar's bug-free warranty lasts twelve months, and it is part of the guarantee. Three commitments on every build engagement: a fixed milestone price with any overage on us, a guaranteed outcome meaning the software works as specified or we fix it, and a twelve-month bug-free warranty. It covers Discovery, Build, Forge and Maintain. It does not cover Embed. On Compass, Immerse and Integrate, ask us.
In practice:
- What the warranty covers. For a full year, we repair any non-conforming code at no charge. The warranty covers code that doesn't work as specified.
- What the warranty does not cover. Feature additions and ongoing operational support, which go through Maintain.
- Ongoing contract. The 12-month warranty obligates us to fix non-conforming code, independent of any ongoing contract.
What should you ask before you sign?#
Ask for the warranty terms in writing before you compare prices. Then put the same questions to every firm on your list, so the answers line up side by side. Get each answer in writing.
- What document is the code measured against, and who writes it?
- When does the window start: acceptance, launch or delivery?
- How long is the window, and does it change with project size?
- What is excluded, in writing?
- What changes by our team void the warranty?
- Does it stay in force if we stop paying for support or move the code?
- What are the response times for a critical bug, a serious one and a minor one?
Gnar's written answers to two of them: the window runs for a full year, and feature additions and ongoing operational support are excluded. On whether it stays in force if you stop paying for support, the warranty holds independent of any ongoing contract.
Bring this list to the first call. Write each firm's answers next to the table above. Keep the written answers with the contract.
