Web Design Warranty: What Bug-Fix Periods Cover

Most website owners discover what their warranty covers at the worst moment: a contact form stops sending, the designer says it is “not a bug”, and a small invoice appears. The argument is rarely about the fix itself. It is about a warranty that was never clearly defined.

This guide from IZI Digital Marketing explains what a web design warranty should cover and how to tell a bug from a change request. It also shows how to use the bug-fix period so fewer problems reach your paid maintenance bill. For how the warranty fits into a full build budget, see our guide to website design price in Malaysia.

The short video below walks through a typical web design process from brief to launch. The warranty sits right at the end of it, and that is where we pick up.

PART 1 · DIAGNOSE

What Does a Web Design Warranty Cover?

IN BRIEFA web design warranty covers defects in the work that was agreed and delivered: features that do not work as specified, layouts that break against the approved design, and errors introduced during launch. It does not cover new work. The warranty is only as clear as the scope behind it, so check what a website design package should include.

The simplest test is this: did the site ever work the way the brief said it would? If it never did, that is a defect. If it works as agreed but you now want it to work differently, that is a change. The table shows where most items fall.

Two things decide how useful your warranty is. A written scope gives both sides something to test against. A clear start date stops the period from quietly expiring before you have actually used the site.

BENCHMARK BRIEFING 1 OF 4

How Long Should a Website Warranty Period Be?

IN BRIEFA fair warranty period grows with complexity. In our model, a simple brochure site needs about 30 days, a corporate site 30 to 60 days, an online store 60 to 90 days, and a custom web app 90 days or more. More moving parts means more time for defects to surface. Our guide to website cost factors that move a quote explains why complexity changes the price too.

The table sets out a reasonable warranty range for each project type, along with the features that usually need that time to be tested properly.

Length matters less than when the clock starts. A 60-day warranty that starts on the day files are uploaded to a hidden staging server is worth far less than 30 days that start on public launch. Ask for “from go-live date” in writing.

PART 2 · DIAGNOSE

Bug or Change Request: How Do You Tell the Difference?

IN BRIEFA bug is something that does not match what was agreed. A change request is something that matches what was agreed, but you now want different. Most warranty disputes come from items in between, like a design detail nobody wrote down. The fix is the approved design itself, so settle how many revision rounds are normal before launch.

Run each issue through three questions before you report it. The answers usually decide the argument for you:

BENCHMARK BRIEFING 2 OF 4

When Do Most Post-Launch Bugs Show Up?

IN BRIEFIn our model of an actively used site, about 45% of launch defects appear in week one and about 75% by week four. The rest show up slowly, often in rarely used pages or seasonal flows. A site nobody tests finds bugs much later. Our website maintenance checklist covers the checks that continue after the warranty.

The table tracks the cumulative share of launch defects found by week, comparing a site that is actively tested with one left alone after launch.

The gap is the whole point. If you wait for customers to find bugs, less than half surface before a 30-day warranty ends. The rest become paid fixes, even though they were there on launch day.

PART 3 · DESIGN

What Do Website Warranties Usually Exclude?

IN BRIEFWarranties exclude anything the designer does not control: plugin and CMS updates, hosting changes, third-party services, and edits made by your team. These exclusions are fair, but they leave a gap that only a maintenance plan fills. Our guide to website hidden costs quotes leave out shows what that gap can cost.

Most exclusions fall into four groups. Read each one against how your site is actually built:

• Software updates. WordPress core, themes and plugins release updates all the time. An update that breaks something is maintenance, not a defect in the original build.
• Server environment. Hosts upgrade PHP and server settings. The PHP supported versions page shows each branch gets two years of active support, then two years of security fixes only. Your site’s environment keeps moving long after its warranty ends.
• Third-party services. Payment gateways, booking tools, map embeds and social feeds change on their own schedule.
• Your own edits. Content uploads, new pages and settings changed by your team after handover.

The PHP point is easy to miss. According to that same php.net page, PHP 8.2 reaches the end of security support on 31 December 2026. A site launched this month on 8.2 will need attention within months, and no bug-fix period will cover it. Ask which version your site runs on before launch.

Downtime from these causes is costly in its own right, as our breakdown of what downtime costs a Malaysian business website shows. Hosting choices matter too; see our web hosting buyer’s guide for Malaysia.

BENCHMARK BRIEFING 3 OF 4

Where Does the Warranty End and Maintenance Begin?

IN BRIEFIn our model, launch defects make up about 50% of support requests in months one to three but only 10% in months four to twelve. After that, updates, third-party changes and content help dominate. The warranty handles the first wave; maintenance handles everything after. Our guide to the yearly cost of running a website budgets for the second wave.

Each bar splits support requests into launch defects, change requests, updates and third-party issues, and content and how-to help.

Only the rust segment is warranty work. Everything else needs a budget line, either a maintenance plan or an agreed hourly rate. Deciding which before launch avoids a rushed choice when something breaks.

PART 4 · DEPLOY

How to Test Your Website During the Bug-Fix Period

IN BRIEFTreat the first two weeks after launch as a test sprint. Submit every form, click every button, try every page on the phones your customers use, and report issues in one list with screenshots. This is also the time to confirm you hold every login, as our website handover checklist explains.

Work through these steps in order. Each one targets a type of defect that customers find first if you do not:

1. Test every conversion path. Submit each form, tap each WhatsApp and call button, and confirm the enquiry actually arrives.
2. Check on real phones. Use at least one Android and one iPhone, in portrait and landscape.
3. Walk the less-visited pages. Thank-you pages, 404 page, privacy policy and any language versions.
4. Confirm tracking works. Check that form submissions show up as conversions in your analytics and ad accounts.
5. Test payments end to end. For online stores, run a real low-value order, then refund it.
6. Log issues in one shared list. Page, device, what happened, what should happen, plus a screenshot.

A single dated list does two jobs. It speeds up fixes, and it proves an issue was reported inside the warranty even if the fix lands a few days after it ends. Also check you hold the domain, hosting and CMS logins, as covered in what you should own at website handover.

BENCHMARK BRIEFING 4 OF 4

How Much Work Is a Bug Fixed After the Warranty?

IN BRIEFIn our model, common post-launch fixes take from about 1.5 developer hours for a broken form to about 6 hours for a checkout fault. Inside the warranty, that work costs you nothing. Outside it, you pay for the hours, often with a minimum charge. Our guide to website design explains how we plan builds to reduce these faults.

The bars show typical developer effort to diagnose and fix each issue, which is what you pay for once the warranty has ended.

Notice that the costliest faults sit in the money paths: checkout, tracking and forms. These are the exact items to test hardest while the warranty is running, because they are both expensive to fix later and expensive to leave broken.

PART 5 · DRIVE

What Should a Web Design Warranty Clause Say?

IN BRIEFA good warranty clause states the period, the start date, what counts as a defect, what is excluded, how to report issues and how fast fixes happen. It also says what happens when the period ends. Put it in the quote, not an email. Our guide to web design payment terms shows how to link it to the final payment.

Use this list when you compare quotes or write your brief. A quote that answers all seven is easy to hold to account:

1. Period and start date. Number of days, counted from public go-live.
2. Definition of a defect. Anything that does not work as described in the signed scope and approved design.
3. Named exclusions. Updates, hosting, third-party services and client edits, listed plainly.
4. Reporting method. One email address or ticket system, with issues logged by date.
5. Response and fix times. Separate targets for “site down” and minor issues.
6. Reported-in-time rule. Issues reported before the end date are fixed free, even if the fix lands later.
7. What comes next. The maintenance option or hourly rate that applies after the warranty.

Our guide to writing a digital marketing RFP shows how to turn these into requirements vendors must answer. For wider contract terms, see digital marketing contract terms to negotiate.

THE VERDICT

Judge a Warranty by Its Wording, Not Its Length

A longer web design warranty looks better on a quote, but the wording decides whether it protects you. For most businesses, the decision comes down to five steps:

1. Match the period to the site’s complexity, using Briefing 1 as a guide.
2. Start the clock at public launch, never at staging upload.
3. Test hard in the first two weeks, focusing on forms, tracking and payments.
4. Log every issue in one dated list so nothing expires unreported.
5. Decide your maintenance route before the warranty ends.

To see how the warranty and maintenance fit into a complete website budget, read our guide to website design pricing in Malaysia.

FAQ

Frequently Asked Questions

1. What is a web design warranty?

It is a free bug-fix period after launch. It depends on the contract, but it usually means the designer fixes defects in the agreed work at no charge for a set number of days.

2. How long is a typical website warranty?

Usually 30 to 90 days. It depends on complexity, but simple brochure sites tend to get about 30 days, while online stores and custom builds justify 60 to 90 days or more.

3. Does a website warranty cover plugin updates?

Usually not. It depends on the wording, but updates released after launch are normally treated as maintenance, because they change the site after the agreed work was delivered.

4. Is a design change covered under warranty?

No, if you approved the original design. It depends on what was signed off, but changing an approved layout, colour or section is a change request, not a defect.

5. When does a web design warranty period start?

Ideally at public launch. It depends on the contract, so ask for “from go-live date” in writing, because some quotes start the clock at staging or final file delivery.

6. What happens if I find a bug after the warranty ends?

You usually pay for the fix. It depends on your arrangement, but most designers charge an hourly rate or cover it under a maintenance plan if you have one.

7. Can I extend a website warranty?

Often, yes. It depends on the designer, but many offer a longer period for complex builds or roll ongoing fixes into a paid maintenance plan after launch.