New requirements are normal during a website build. The risk is not the request itself; it is starting work before anyone agrees what the request replaces, adds, costs, or delays. A small change order can keep the project moving if it preserves a clear baseline and an explicit decision.
Write the request as an outcome
Instead of “make the website more interactive,” state the user behavior: “Visitors can filter case studies by service, and the business can add a case study without developer help.” That description lets the provider identify design, content-model, testing, and training work. If you only want a visual adjustment to an approved component, say which component and which acceptance issue it fixes.
Attach the original requirement and the reason for change. A provider may have missed a signed deliverable; in that case the work may be a correction. Or the business may be adding a feature after approval; in that case it may be new scope. The signed agreement decides who bears the cost, so make the comparison visible.
Require five fields in the order
The change order should name the deliverable and exclusions, one-time and recurring cost, owner of required content or credentials, effect on already approved work, and effect on milestones. Include the acceptance test. A new booking widget, for example, may require a vendor subscription, privacy-copy review, mobile QA, and a confirmation-email check. Those are part of the change, not surprises to discover at launch.
Give the buyer three choices: approve now with a revised schedule, substitute for another item of comparable effort, or defer to a later phase. Deferral is often the cleanest way to protect a fixed launch date, but only if the deferred feature is genuinely optional and the remaining site still fulfills its purpose.
Preserve the launch path
The project lead should show the critical path after the decision: next reviewable page, content deadline, testing, and release approval. Do not allow an unapproved feature to enter production because someone mentioned it in a call. Conversely, do not let a signed correction get reclassified as paid scope merely because it was discovered late. Put the final decision and revised plan in a shared record.
Where the change affects URLs, forms, or account ownership, update the acceptance checklist and handover notes. A change that is “done” but undocumented can create postlaunch failure.
ARCHV’s website process says added work is agreed in writing, and project price follows a reviewed scope. It does not promise that every new request fits the original schedule. If you are assessing a proposal before signing, use the quote comparison to check for change-order terms. A public web-design scope discussion offers qualitative examples of why both sides need that record; it does not set a contract standard.
At the end of each review meeting, list decisions that are final and requests still awaiting a change order. This prevents a tentative idea from being treated as approved work. Where a request is deferred, name the future phase and any technical preparation needed now, so deferral does not create an avoidable rebuild after launch.