Website Maintenance: Bug Fix or New Requirement?

The sentence most likely to cause conflict after launch is, “Wasn't this supposed to be included?” The client sees a bug while the vendor sees a new request. Both may have a point because the original scope was never clear.

Reducing conflict takes more than a contract promising “one year of free maintenance.” Define what counts as a defect, what counts as change, and which version and environment provide the basis for judgment.

01 Establish a Traceable Project Baseline

Approved requirements, prototypes, visual designs, feature lists, technical notes, test cases, and acceptance records jointly form the baseline. Ideas mentioned informally in chat but never confirmed create the greatest room for conflicting interpretations.

Record the version, reason, and impact of every post-launch change. Do not continue relying on one obsolete document from the project's beginning.

Typical Bug and New-Requirement Classifications

02 A Bug Requires Three Conditions

First, there is a clear expected result. Second, the issue can be reproduced reliably. Third, it occurs within the agreed environment and data scope. When expectations are missing, confirm the product rule before simply asking engineering to “fix it.”

An issue report should include page, account, device, steps, expected result, actual result, and a screenshot or log—never only “This is wrong.”

03 Environment Changes Should Not Automatically Belong to Either Party

Browser updates, server migration, third-party APIs, plugin versions, and security-policy changes can break an existing function. The contract should define which changes maintenance covers and which require evaluation.

The vendor should communicate risks promptly. The client should not change code, configuration, or plugins without coordination and still expect unlimited free remediation.

04 Small Changes Can Still Create Scope Creep

Replacing a sentence is usually small, but “add one filter” or “include an admin tool while you're there” can affect data, permissions, design, development, and testing. Judge impact, not the length of the request.

A prepaid maintenance allowance can cover minor adjustments. Work beyond an agreed threshold moves into a change request, balancing speed with clear boundaries.

05 Define Maintenance Response and Scheduling in the Contract

Free bug fixing does not mean immediate 24/7 support. Define severity, response time, reproduction confirmation, repair window, release method, and emergency rollback.

New requirements need confirmed scope, cost, schedule, acceptance, and impact on the existing plan.

06 Turn Disputes Into Verifiable Questions

When the situation is ambiguous, reproduce it together, review the documentation, and confirm business impact before choosing free repair, paid change, or shared responsibility.

In a long-term partnership, transparency matters more than assigning blame for one small issue. Clear rules actually make flexible handling easier.

Frequently Asked Questions

Is a typo discovered after launch a bug?

If the vendor entered content differently from the approved copy, it is usually a correction. If the client changes the copy later, it is a content update.

Is a rendering issue after a browser update a bug?

It depends on the maintenance scope and compatibility commitment. It may be covered maintenance or new work caused by an environment change.

Does free maintenance include new pages?

Usually not unless the contract says so. A new page involves design, development, content, and testing.

How should we handle an issue that is hard to reproduce?

Collect logs, device, account, time, and action path. Improve reproducibility before assigning responsibility.

What if the client changed the code and then a problem appeared?

First isolate the impact of the change. Contracts commonly exclude problems caused by third-party modifications from free maintenance.