Warranty Periods for Web Development: Bugs vs New Work

A web development warranty is a fixed window after delivery in which you fix defects in the work you delivered, at no extra charge. A 30-day period starting at launch or acceptance is the most common default for freelancers and small agencies, with 60 and 90 days showing up on bigger builds. It covers things that were wrong when you handed the site over: a form that doesn't submit, a layout that breaks on a browser you agreed to support, a calculation that returns the wrong number. It does not cover new features, changes the client asks for, edits made by someone else, or breakage caused by a third party after launch. Anything outside that line gets quoted or billed as its own work.

The hard part isn't picking a number of days. It's that "can you just fix this quick?" arrives on day 12 and the client believes everything on the site is covered. If you've never defined what the warranty is, every message becomes a negotiation, and you either eat the cost or have an awkward conversation with someone who has already paid you.

This post gives you the definitions, a triage table you can run any reported issue through, a clause you can adapt for your own contract, and the invoicing that follows once the window closes. It's general information about how freelance and agency work is commonly structured, not legal advice. Contract law varies by country and state, so have a lawyer review anything you're going to rely on.

What should a web development warranty cover?

A warranty covers defects: places where the delivered work doesn't do what the agreement said it would. The key word is agreement. If your statement of work says "contact form sends an email to the client's address," then a form that sends nothing is a defect. If the statement of work never mentioned a contact form, a client asking for one on day 20 is asking for new work, no matter how obvious it seems to them.

That's why a warranty is only as clear as the scope behind it. A short list of what's normally covered:

Functionality listed in the scope that doesn't work as described
Layout or display problems on the browsers and devices you named as supported
Errors introduced by your own code during the build, including regressions from your last deploy
Wrong data, wrong calculations, or broken links in work you produced

And what a warranty normally leaves out:

New features, design preferences, or business rules requested after acceptance
Content or configuration changed by the client or another contractor
Failures in third-party services, plugins, or accounts you don't control
Browsers, devices, or usage you excluded in the scope
Security problems caused by shared or compromised credentials
Platform, legal, or API changes that happen after you deliver

Bothmade, a studio that publishes a buyer guide to website warranties, describes the same split: a warranty corrects faults present in the delivered work, while maintenance manages the changing environment around it, such as dependency updates, monitoring, backups and platform changes. Naming those two things separately is what stops every post-launch request from turning into an argument.

Excluding something from the warranty doesn't mean you refuse to help. It means the work gets priced instead of absorbed. You can still diagnose a problem for free as a courtesy and tell the client what it is, then quote the fix.

How long should the warranty period be?

For freelancers and small shops, 30 days is the safe default, and the reasoning is worth knowing so you can explain it to a client who asks. Paper Leaf, a software agency, calls 30 days the generally accepted default for functionality guarantees and explains why: a modern site sits on top of browsers, frameworks, hosting runtimes and the end user's devices, all of which update on their own schedules. Past a month it becomes impossible to promise that something you didn't touch won't conflict with something that changed. They also note that 45, 60, or longer warranties exist, and that asking for a longer one is a request to shift risk to the developer, which is reasonable to price in.

Longer periods are normal at the other end of the market. JMR, a custom software house, writes that warranties on bespoke software typically run 90 days to a year, and that the length affects the price. That tracks: a long warranty on a large, complex system is a bigger commitment than 30 days on a brochure site, and it should be reflected in the fee.

A practical way to choose:

Project type	Reasonable starting point
Brochure site, landing page	30 days
Site with forms, integrations, or a CMS	30 to 60 days
Custom web app or e-commerce build	60 to 90 days, priced in
Anything longer	Priced as a separate support line, not folded into the build fee

Two decisions matter more than the number itself:

When does the clock start? Pick one trigger and write it down. Launch date is clean when you control the deploy. Acceptance date is cleaner when the client sits on a staging site for weeks. Do not tie it to final payment, or a late payer gets a free warranty extension for every day they delay.

Does the clock pause? If the client takes nine days to answer your question about an issue, the issue shouldn't use up nine days of your window, and it shouldn't leave you fixing it on day 31 for free either. A simple rule works: a defect reported inside the window gets fixed even if the fix lands after it closes.

How do you tell a bug from a change request?

Use one test: did the delivered work fail to do something the agreement said it would do? If yes, it's a defect. If the agreement was silent or the client simply wants something different, it's a change.

Most disputes aren't about that test. They're about the gray area between "this should obviously work" and "this was never discussed." The triage table below handles the common cases. Run each reported issue through it before you reply.

Reported issue	Classification	Covered or billable
Contact form in scope stops sending emails	Bug	Covered
Menu overlaps the logo on a supported mobile browser	Bug	Covered
Checkout total is wrong when a coupon is applied	Bug	Covered
"Can the button be green instead?"	Change request	Billable
"Can we add a second contact form?"	Change request	Billable
New page or section not in the scope	Change request	Billable
Layout breaks on a browser you excluded in the scope	Out of scope	Billable, or quote a fix
Site broke after the client installed a plugin themselves	Client change	Billable
Site broke after a developer they hired edited the theme	Client change	Billable
Embedded third-party widget stopped loading after the vendor changed its API	Third-party break	Billable
Hosting provider updated PHP and a function was removed	Third-party break	Billable, or covered under a maintenance plan
Typo in copy the client supplied	Content	Billable, or a courtesy fix
Typo in copy you wrote	Bug	Covered

Some of these are judgment calls and you may decide to fix a small one for free to keep goodwill. That's your call to make. The point of the table is that you decide deliberately, and that you know which fixes are a gift and which are an obligation. If you give away a gift, say so: "Happy to fix this one as a courtesy. Going forward, changes like this are quoted separately."

For the change request side, the same discipline applies as on any scope-creep situation. Write down what's being asked, what it costs, and get a yes before starting. Scope creep and change orders walks through the paperwork for that.

What happens when a plugin or API update breaks the site?

This is where most warranty arguments start, and it's the reason the exclusion exists. A third-party break is a failure caused by something outside your delivered work: a plugin auto-updated, an API provider changed a response format, a payment gateway deprecated an endpoint, the host upgraded a runtime. Nothing you wrote changed, but the site stopped working.

From the client's side, it doesn't matter. The site is broken and you built it. That's a fair feeling, which is why this needs to be handled in the contract and the conversation, not in the heat of the moment.

Ways to deal with it:

Say it in the clause. Name third-party services and platform changes as excluded events, so nobody is surprised.
Diagnose before classifying. Spend fifteen minutes finding the cause. "The payment provider changed their API on Tuesday" is a fact you can show the client. "It's not covered" without evidence sounds like an excuse.
Offer a path. Quote the fix, or point to a maintenance plan where this kind of work is covered. Fixes for outside changes are exactly what website maintenance retainers exist for.
Pin versions where you can. If you deliver a site with locked dependency versions and a documented update process, you reduce the number of third-party breaks inside the warranty window to nearly none.

A fix that's quick and cheap to do is a good candidate for a goodwill gesture inside the window. A fix that takes three hours because a vendor rewrote their API is not. The line between them is your own tolerance.

What does a 30-day warranty clause look like?

Here is a starting-point clause for a services agreement. Adapt the wording to your own contract, jurisdiction, and the way you work, and have a qualified lawyer check it before you depend on it. This is an example of common structure, not legal advice.

Warranty. For thirty (30) days after the Warranty Start Date
(the date the Deliverables are launched to the live site, or the
date the Client accepts them, whichever is earlier), the Developer
will correct, at no additional charge, any Defect reported in
writing during that period.

A "Defect" is a failure of the Deliverables to perform as
described in the Statement of Work, on the browsers and devices
listed there.

The warranty does not cover: (a) new features or changes to the
Statement of Work; (b) content, code, or configuration modified
by the Client or any third party; (c) failures of third-party
services, plugins, hosting, or platforms; (d) browsers, devices,
or uses not listed in the Statement of Work; (e) problems caused
by lost or shared credentials.

A Defect reported within the warranty period will be corrected
even if the correction is completed after the period ends. Work
outside this warranty is billed at the Developer's then-current
rate or under a separate maintenance agreement.

A few notes on that clause:

"Reported in writing" gives you a record. Email or a ticket is fine. A phone call isn't.
"Whichever is earlier" stops the clock from being held hostage by a slow review.
The correction sentence stops the "it's day 31 now" argument for anything reported in time.
The last sentence points to your rate, which is the hinge for the next section.

If your contract has a section on payment, put the warranty after it and keep the two separate. Freelance contract payment terms covers the payment side so the warranty doesn't get tangled up with when the final invoice is due.

How do you bill fixes after the warranty ends?

Once the window closes, any fix is billable work. There are three ways to handle it, and the right one depends on how often you expect to hear from this client.

Hourly, with a minimum. Quote a rate and a small minimum, such as thirty minutes, so a five-minute change doesn't cost you the context switch. Put it on the invoice as its own line, with a clear description: "Fix: contact form notification email, 0.75 hr." Keep the description specific enough that the client can see what the charge was for.

A fixed price per fix. For small, well-understood problems, tell the client the price before you start. "That's $120 and it'll be live today." No surprises, and an easy yes.

A maintenance retainer. If the client keeps writing, a monthly plan with a set number of hours is usually better for both sides. They get predictable cost and fast response. You get recurring revenue and a defined scope.

Whichever you choose, bill each fix as its own line, and don't bury it in a lump sum. A line that says "Post-warranty fix, checkout coupon bug, 1.5 hr at the agreed rate" is easy to approve and easy to remember later. If you built the original site and an unrelated post-warranty fix comes through, keep it on a separate invoice so it doesn't muddy the original project's paper trail.

A short email works well when the window is about to close:

Hi Sam, the 30-day warranty on the site ends on [date]. If you've noticed anything that isn't working as described in the scope, send it over before then and I'll fix it. After that date, fixes and changes are billed at my standard rate, or we can set up a monthly maintenance plan if you'd rather have a fixed cost. Let me know which you'd prefer.

It's friendly, it creates a deadline for defect reports (which you actually want), and it opens the maintenance conversation without pressure.

Does the warranty belong on the invoice?

Terms of the warranty should live in the contract, not on the invoice. But a one-line reference on the final invoice is useful, because it's the document the client opens when they pay and is the one they're likely to look back at. Something like "30-day warranty on delivered work begins on [date]; terms in Section 8 of the agreement" reminds them when the window opens and closes.

Don't put a warranty in the invoice that isn't in your contract. If the contract says one thing and the invoice says another, the mismatch helps nobody. For help with what to include on a final invoice, see what belongs on a software development invoice.

A short checklist before you hand the project over

Scope document names the features, browsers, and devices that are covered
Contract defines "Defect," the warranty period, and the start trigger
Exclusions name third-party services, client changes, and new features
A written reporting route is agreed (an email address or ticket form)
Handover notes document hosting, versions, and anything fragile
Final invoice states when the warranty window opens and closes
A maintenance option is ready to offer when the window closes

Spending twenty minutes on this at handover saves hours of back-and-forth over the following months.

FAQ

Is a 30-day warranty standard?

It's the most commonly cited default for small web projects. Paper Leaf, a software agency, describes 30 days as the generally accepted default, while custom software houses often offer 90 days to a year on larger builds, usually reflected in the price. There's no legal rule that sets it, so choose a period that matches the size and risk of the project and write it down.

Do I owe free fixes if the client edited the code?

Not under a typical warranty. Changes made by the client or another contractor are usually listed as an exclusion, because you can't be responsible for code you didn't write or can't verify. Diagnose the problem, show the client what changed if you can, and quote the repair. If your contract doesn't mention this exclusion, add it for next time.

Does the warranty start at launch or at final payment?

Start it at launch or acceptance, whichever happens first, and write that into the contract. Tying it to final payment means a client who pays late also gets their warranty later, which rewards the wrong behavior. Keeping it tied to delivery keeps the two issues separate: you deliver, the clock starts, and payment is handled by its own terms.

Should warranty terms appear on the invoice?

The terms belong in the contract. A single reference line on the final invoice, with the start and end dates of the window, is helpful as a reminder. Don't restate or change the terms on the invoice, since conflicting documents create disputes.

When the warranty ends and the fix request arrives, bill it as its own line so the work and the price are easy to see. Generate the invoice free at billable.dev, with no account and nothing leaving your browser. Pro ($4/mo billed as $24 every 6 months, or $79 once) adds saved clients and invoice history if you invoice the same people repeatedly. The free invoice template for developers is a good place to start if you want a layout to work from.