The developer writes “all done,” sends a link, and only the final payment is left. At that moment it is easy to settle for the home page opening and looking like the design. Then in the first week it turns out the form does not work on phones and half the footer links lead nowhere.
Accepting a site needs no technical knowledge. It needs an hour of calm time, a phone, and a list of what to check. Below is that list.
Walk through the site as a visitor
Open the site on a phone, not on the developer’s computer and not via their link, but by typing the address yourself. Follow the path a client will take: from the home page to a request.
- Every page opens, and nothing shifts or overlaps
- The menu opens and closes, and buttons are easy to hit with a finger
- The phone number and messenger links open when tapped
- The site looks fine on a computer and in another browser
Send a real request
Fill in every form on the site and make sure the request reaches where it should: your email, Telegram, or CRM. Try sending a form with a mistake and see whether it is clear what went wrong. Where requests get lost is covered in detail in the note on missing form requests.
Copy, links, and small things
- No placeholder text or test images are left anywhere
- The phone number, address, company details, and opening hours are correct
- Menu and footer links go to the right pages, and social links go to your accounts
- A non-existent address opens a clear 404 page with a link to the home page
- There is a data policy if the site collects contacts
- The browser tab shows the site icon, and a link shared in a messenger gets a proper preview
The admin panel and edits
If you will change things on the site yourself, ask for a live demo. Log in with your own account, change a text, add an image, and look at the result. It is better to discover that it is awkward now, while the developer is still on the project.
What must stay with you
- Access to the domain, hosting, email, analytics, and admin panel on your own accounts
- The code in a repository you have access to
- A short guide: how the site is built, how to make a backup, and where to look if something breaks
- A list of what was included in the work and what was left for later
How to check access with your own hands is covered in the note on domain, hosting, and access.
How to write up the issues
Collect everything you found in one list: what is wrong, on which page, on which device, with a screenshot. Separate bugs that block the launch from wishes that can wait. Then acceptance takes one round of fixes instead of stretching over weeks. How to phrase such notes is described in the note on design feedback.
After acceptance the site’s ordinary life begins, covered in the note on support after launch. If you want us to check a site before the final payment, use the contact form.