A launch is not the end of quality control. Forms, links, responsive layouts, and integrations can reveal problems after real users arrive. The contract should say how an agreed defect is reported and handled, without relying on an invented universal warranty period.
Check the real path
- Specify the pages, browsers, devices, forms, and integrations included in acceptance testing.
- Record how defects are submitted, their severity, and who investigates third-party failures.
- Agree the correction period and exclusions before signing, including any ongoing maintenance option.
- Keep access, backups, and a handover record so the business can operate the site after launch.
Decide what to change
A correction period should match the project and contract. It cannot promise a sales result or search ranking. A new feature request is distinct from fixing a deliverable that fails the agreed test.
Put it in the project brief
Before paying for a fix, ask the provider to name the affected page or workflow, the change they will make, how they will test it, and which dependencies or exclusions could change the estimate. Keep the baseline and the completed test so both sides can see what improved.
How ARCHV can help
ARCHV's proposal should state handover and after-launch support; exact defect terms are set in the signed project agreement. Share the current page and the problem through ARCHV's website estimate form. If you are an agency seeking delivery support, see the partner route.