Which post-launch website issues are free bug fixes and which are paid changes?

A bug is the site failing to do what was agreed. A change is the site doing what was agreed and someone now wanting something else. The approved designs, scope and support list settle the difference. How annoying an item feels does not.

A growing snag list is normal during the first two weeks after launch. The site is now handling real visitors, production systems and content that may differ from the approved version. People who were not involved in the redesign also start reviewing it.

Technical bugs tend to surface in the first ten days because normal use exposes them quickly. Opinions arrive later and can keep arriving without a firm close date. Volume alone does not tell you which items should be fixed free.

Run each complaint through the same four questions before anyone estimates the work. Keep the approved design, sitemap, scope and browser support list beside the snag list.

If the evidence shows that an agreed feature is broken, record the item as a bug. If the site matches the approval and the request introduces a new result, record it as a change. If neither side documented the case, move it into a separate grey list.

1. Was the result specified in the scope or shown in an approved design? If yes, compare the live site with that evidence.
2. Does the same component work as designed elsewhere on the site? If yes, the inconsistent instance is usually a bug.
3. Is something broken, or is it merely different from what a reviewer expected? An unmet private expectation is not an agreed requirement.
4. Did the copy, media, integration or other input change after sign-off? If the new input caused the problem, the remedy is usually a paid change.

The studio should normally fix an item free when the live site fails to match an approved design, documented requirement or agreed technical standard. A deadline for reporting bugs may apply, but that does not turn defective agreed work into a new request.

Production failures are especially clear. If a form delivered messages during staging but stops delivering after launch, the client did not request a new feature. The agreed feature failed during deployment or configuration.

• Broken behaviour on a browser or device named in the agreed support list.
• A shared component that behaves differently on two pages using the same approved design.
• Forms that submit without delivering, redirects that miss their destination, or old-site links that were agreed for migration but now break.
• Accessibility failures against the standard named in the contract.
• Anything that worked in the approved staging site but fails in production.

A request is a paid change when the live site matches the approval but the desired result has changed. These requests are not dishonest. They often appear because launch gives people their first chance to see the site under real conditions.

For example, an approved card may fit a 40-word description but look cramped after the final copy grows to 80 words. The component has not necessarily failed. The input changed, so the team must shorten the copy or pay to adapt the design.

• A layout looks cramped because the final copy is twice the length used at sign-off. Real content exposed a new requirement.
• The site needs to support a browser or device that nobody included at the start. A visitor may still need it, but it was not part of the tested support list.
• The team wants a new page type that was absent from the approved sitemap. The need may be valid even though it expands the build.
• A third-party tool bought after launch changes the layout or needs a new integration. Neither side could test a tool that had not been selected.
• A senior colleague first saw the site after launch and prefers another direction. Their authority does not make their new preference part of the earlier approval.

Some items are neither clear bugs nor clear changes because nobody specified the situation. Common examples include loading states, empty search results, very long account names and the mobile behaviour of a wide table.

Suppose an approved desktop table has eight columns, but no design shows what happens on a phone. The client may assume the columns collapse. The studio may assume the table scrolls sideways. Both solutions are reasonable, but neither assumption was approved.

Split the cost, trade the work against remaining scope or choose the smallest acceptable fix. Arguing over who silently assumed what often costs more than resolving the item. A studio that declares every grey item billable also has to accept that it wrote a thin specification.

A snag process should turn reports into decisions, not preserve every comment forever. Use one list with one owner and a named person who decides matters of taste.

1. Collect every item in one place. Do not divide the evidence between email and several Slack threads.
2. Require a URL, screenshot, browser and device for each report. Return incomplete reports because nobody can reproduce or close them.
3. Sort each item into broken, different or wanted before asking for an estimate. Broken means the agreement is not met. Different means the result needs checking. Wanted means a new outcome is being requested.
4. Set a close date for the free correction window. Batch valid later requests into a scheduled paid round instead of reopening the project each day.
5. Remove duplicate opinions and send taste decisions to one named approver. Five comments about the same design gap are one item, not five changes.

You should not pay to correct behaviour that fails on a browser named in your contract, however late you notice it. A reporting deadline helps both teams close the project, but it should not excuse a failure to deliver an agreed requirement.

Ask for the warranty period in writing before signing. Thirty days is common, while ninety days gives more time for low-traffic pages and less frequent workflows to be tested. A studio offering no correction period is passing its delivery risk to you.

A warranty is not a retainer. You do not need an ongoing support contract merely to have launch defects corrected. Ongoing updates and new requests can be priced separately.

Not every valid snag deserves work. A one-pixel difference on a page receiving forty visits a month may cost more to discuss and test than it is worth. Record the decision to leave it, then close the item.

Sort each item against the signed-off work, resolve the undocumented middle fairly, and give the list a close date. That leaves the studio responsible for defects and the client responsible for new decisions.