Websites can fail in ways that only appear on the live domain: a form sends to the wrong inbox, a redirect points to an old staging page, or a mobile menu misbehaves on a particular device. A postlaunch defect window gives the buyer a route to report agreed functionality that does not work. Its duration and terms belong in the signed proposal; there is no universal correction period.
Define a defect against the accepted scope
A defect is generally a failure of an agreed deliverable or acceptance test. Examples might include a contracted form that does not deliver, an approved page missing from launch, a broken link the provider agreed to check, or an agreed mobile layout that cannot be used. Document the expected behavior, actual behavior, URL, device/browser, and evidence. The provider can then reproduce and prioritize the issue.
A change in preference is different. After launch, a buyer may decide to rewrite the offer, replace the hero concept, add a location, or route leads to a new CRM. Those may be valuable changes, but they are not automatically corrections to the original build. Compare each request with the approved scope before classifying it.
Name third-party boundaries
The site may depend on hosting, a payment service, an email provider, a booking system, or a licensed plugin. The proposal should say who diagnoses a failure, who contacts the vendor, and whether work caused by a vendor change is included. A buyer should not be left guessing during an outage. Equally, a website provider cannot guarantee a third party’s service availability unless that obligation is specifically contracted.
For urgent issues, define the reporting channel and triage rules. A broken lead form is different from a minor spacing issue. Ask whether the provider will acknowledge an issue by a stated time, whether a temporary workaround is possible, and what counts as resolved. Do not read a guaranteed fix time into a generic “support” promise.
Keep launch acceptance and later maintenance separate
Record the launch date, accepted deliverables, open issues, and the correction window’s start and end. If a known issue remains open at launch, give it an owner and specific resolution plan. Do not treat final payment as proof that every item was tested unless the agreement makes that relationship explicit.
An ongoing maintenance plan may cover updates and content changes after the correction period; it should be priced and described separately. A clean handover gives the buyer account access and enough documentation to report a problem accurately even if the original builder is unavailable.
ARCHV’s website service page asks buyers to define defect correction, handover, ongoing support, and recurring costs in the proposal. It does not promise one fixed window for every direct-client project. If you are comparing offers, use the website quote comparison to put each provider’s correction and maintenance terms side by side. Before final payment, test the agreed pages, forms, links, mobile layouts, and access, then record any open issues in writing.
For a reported form defect, the W3C forms tutorial gives independent checks for labels and error feedback. Delivery to the specified recipient must be tested as a separate operational step. A visual form check alone cannot establish that an inquiry arrived.