A launch can pass every acceptance test and still develop a problem a week later: a mailbox filter changes, a calendar link expires, a plugin is updated, or a key page begins returning an error. The handover question is not simply “Is there a warranty?” It is “Who will notice, report, and investigate a broken customer path after the project team leaves?”
The answer should be agreed before launch. A one-time site build and an ongoing monitoring service are different commitments. Do not assume that a developer, agency, host, or owner is checking daily unless the scope says so.
Name the critical paths
List the journeys that would hurt the business if they failed: primary contact form, booking link, product inquiry, checkout handoff, mobile navigation, and top paid-ad destinations. For each, record a test method, frequency, owner, and escalation route. Keep the list small enough that someone will actually use it. A full crawl may detect broken links but not a missing form email; a human test may catch confusing wording but miss intermittent failures.
For a contact form, check three receipts: the browser confirmation, stored submission, and delivered notification. Google Workspace’s contact-form troubleshooting explains why the web submission and mailbox delivery can fail separately. Use test entries clearly marked as tests and keep any customer data out of the monitoring log.
Define the issue route
What counts as a defect in the delivered site? Who receives a report? What evidence is needed—URL, device, time, screenshots, and a test submission ID? Which problems belong to a hosting provider, email administrator, payment processor, or marketing team? A good handover document can route an issue without promising that every third-party failure is included in website support.
If the supplier offers a correction period, write its duration and scope in the agreement. Do not imply that a universal 14-day warranty exists. Monitoring can be performed by the owner, the agency under a separate agreement, or a specialist service. The choice depends on business impact and operational capacity.
Run a first-month cadence
Test the critical paths immediately after DNS and deployment changes, again after third-party configuration changes, and at an agreed interval during the first month. Record the date, result, and who resolved any issue. Review the cadence after observing actual problems. Avoid collecting a dashboard of green ticks while no one tests whether inquiries reach the right person.
ARCHV can scope launch QA and a documented handover for agreed pages and contact actions. Ongoing monitoring, third-party integrations, email administration, and support response commitments require explicit separate terms. Request a website estimate with your current site, critical customer paths, and the level of follow-up you need.
Related reading: ARCHV on comparing web-design quotes covers how to put deliverables and post-launch terms in writing. This article focuses on the operational check owner after handover.
If a monitoring task is delegated, make sure the person can actually see its result. A form test sent to an inbox they cannot access is incomplete. A checkout test that cannot be refunded or marked as test data creates accounting work. The handover should include access, test accounts, and a safe way to report failures without exposing customer information.