Website Custom Development Midway Through, You Discovered the Requirements Were Wrong—How to Calculate Rework Costs in 2026?

Discovering midway through a custom website development project that the requirements were wrong does not mean rework costs are an open-ended hole. Based on 2026 project delivery habits, the cost increase caused by requirement changes typically ranges from 15% to 40% of the contract amount (experience range), and the later the change, the higher the cost—changing the interface at the prototype stage might only add a few days of work, while changing the data structure late in development could mean starting over. Based on experience in website building and design implementation, this article provides a verification method for requirement changes, an acceptance checklist, and applicable boundaries.

Why Do You Discover the Requirements Are Wrong Only Halfway Through?

Most requirement changes midway through are not deliberate trouble-making by the client, but rather because the source was not locked down. There are three common reasons: the requirements document was not detailed enough, covering only functions but not conditions; multiple decision-makers on the client side were involved without unified opinions; or the developer proceeded directly based on their own understanding without confirming each point.

• The requirements document only states "supports login" without specifying whether third-party authorization or password retrieval is needed;
• The client says "anything is fine" during the review, but later rejects it based on another person's opinion during acceptance;
• The developer jumps into code without even reviewing the prototype, only to realize the direction is off after completion.

These situations remain common in 2026 because although website building tools and collaboration methods have changed, the granularity of requirement exchange has not. A qualified requirements review should at least answer "which scenarios should not occur" and "how the system should prompt in abnormal situations," rather than just confirming the feature list. If the developer only asks "what do you want" during the review and does not ask "what do you not want," the project has already laid the groundwork for trouble.

How Exactly Should Rework Costs Be Calculated? Use Three Steps to Verify

Rework costs are not a shot in the dark; they should be estimated based on the "stage of the change + the scope of impact." A common method we use is the "Three-Step Verification Method":

1. Define the scope of the change: Is it interface copy, page layout, or data structure and business process? Copy and layout changes are usually billed by the hour, while data structure changes may involve database migration and API rewriting.
2. Verify the stage of the change: Changes at the prototype stage have lower costs, followed by the development stage; changes during testing and after launch are more expensive. The same change, if requested after development is complete, may cost twice as much.
3. Re-estimate the workload: Have developers and testers provide their respective hours, then add integration and regression time. Reserve at least one day of buffer because rework is often not just about making the change and being done.

Why divide it this way? Because each step determines whether the rework is "changing the style" or "changing the foundation." A common situation in projects is the client requesting to replace "phone number login" with "QR code login" midway through development. If the backend is already hardcoded, the rework cost may exceed 30% of the original budget (experience range). If it is just changing a button color, billing for half a day to one day of work is sufficient.

Comparing two typical changes side by side makes the difference clearer:

• Changing interface copy: Adjusting a few lines of text on the front end, usually 0.5–2 hours, no API involvement, almost zero risk.
• Changing the login method: Involves backend logic, database fields, third-party SDK integration, security verification, typically 3–10 working days based on the experience range, and may affect other modules.

So, before discussing rework costs, first clarify whether you are changing the "skin" or the "bone."

What Is the Cost Range Difference for Changes at Different Stages?

To more intuitively judge whether rework is expensive, we list common cost ranges by project stage (all are experience ranges; actual amounts are subject to contract terms):

• Prototype stage: Changing interface layout or copy, recommended at 0.5–2 days; low risk because no code has been written yet.
• Development stage: Involving backend logic or data structures, typically 3–10 days, with additional adaptation of related modules.
• Testing stage: After changes, test cases need to be rerun; costs may increase by 20%–50% (experience range) on top of the development stage estimate.
• Post-launch: Besides development, consider data migration, legacy version compatibility, and online troubleshooting; costs may reach 1.5–2 times (experience range) the development stage.

These ranges still apply in 2026 because costs mainly come from manual labor hours and communication, not the technology itself. If a developer quotes labor costs significantly below these ranges, be wary of missing items or plans to add items later.

How to Minimize the Cost of Requirement Changes?

A more reliable approach is not to bargain after changes occur, but to plug the loopholes from the requirements stage. Common practices in 2026 include: the requirements review meeting must pass a "negative case list," where for each function you write out "which cases are not handled" and "how exceptions are handled"; when confirming the prototype, interaction details should be clearly written, such as button states, empty data prompts, and behavior under slow network conditions; the contract should separately stipulate that "changes beyond the original scope of requirements will be billed separately based on workload."

The change clause in the contract should include at least three things: the change process, billing rate, and free allowance. Without these, disputes are likely later. Based on 2026 enterprise project delivery habits, we typically write in the contract: any changes beyond the scope of the "Requirements Confirmation Document" must be proposed by the client in writing or by email; the developer evaluates the hours and quotes a price; implementation proceeds after both parties confirm; the daily rate is calculated according to the contractually agreed X yuan; if a single change is less than 2 hours, the labor fee is waived.

At delivery, first verify one thing: whether the change has been confirmed in writing by the client. Saying "just start working on it" verbally is a major source of rework disputes. According to project delivery habits, any change must be recorded via email or project management tools; otherwise, later revision and delay issues cannot be clarified.

Here is an on-site example: For a corporate website project, when development had already passed 60%, the client requested changing the news list to image-text cards and adding two filter conditions. On the surface, this was just a style change, but the filter conditions involved backend query logic and required re-adaptation. Because the contract did not stipulate change costs, the parties had to compromise: the client paid an additional 8,000 yuan (approximately 20% of the original contract amount), and the schedule was extended by 5 days. If change billing rules had been agreed upon from the start, this price could have been calculated directly by work hours without dispute.

Applicable Scenarios and Boundaries

This rework cost logic is more suitable for websites with clear business differentiation and custom functionality needs. For example, medical device displays, complex appointment processes, and internal management systems. These are worth investing in custom development, and the cost of changes can be absorbed more patiently.

However, if your requirements are only brand display, news publishing, or product listing, and the budget is within several tens of thousands of yuan with tight launch time, then a template website or SaaS website builder is more suitable. Such projects have limited space for changes, and repeatedly adjusting requirements can easily turn a simple page into a half-finished mess. There is also another situation not recommended: when requirements are completely unclear and no one on the team can make a decision. In this case, custom development is likely to fall into a "change requirements—rework—change again" loop, with costs far exceeding expectations.

Frequently Asked Questions

If requirements change midway through a custom website development project, how much extra should generally be paid?

The experience range is 15%–40% of the contract amount, depending on the scope and stage of the change; simply changing copy may cost nothing, while changing data structures and APIs is billed by work hours.

Which changes should not incur additional fees?

Minor adjustments that do not affect the overall structure and interaction, such as typos, colors, and spacing, are usually included in the modifications before acceptance; however, redesigns that overturn already confirmed decisions are not included.

How should the cost of requirement changes be stipulated in the contract?

A common approach is to write "changes beyond the original scope of requirements are billed at a daily rate, with the daily rate being X yuan," and to stipulate that implementation requires written confirmation from the client.

If a requirement change causes a launch delay, who bears responsibility?

If the change is proposed and confirmed by the client, the schedule is extended accordingly; if the developer implements it without notifying the client of the impact, the responsibility lies with the developer. It is recommended to keep records in project management tools.

If requirements keep changing, should we pause or continue?

It is recommended to pause first, consolidate the change requests into a list, evaluate the total work hours and costs, and then decide whether to continue; otherwise, you may end up changing things while it is already messy, leading to a pile-up of engineering defects.

Before taking action, ask yourself three questions: Does the requirements document clearly state conditions and negative cases? Has the client provided written confirmation? Does the contract have a change billing rule? If all three answers are no, it is recommended to stop and supplement the agreement first, rather than rushing to work. This method is suitable for projects with custom functionality needs and relatively ample budgets and timelines; if it is just a simple display website, choosing a template website is more worry-free.