Before You Approve a Website, Test These Five Things

A website can look finished and still be hard to use, difficult to update or unreliable when someone tries to get in touch. Before you approve the final build, test it like a customer and run it like the person who will have to maintain it.

1. Can a new visitor work out what to do?

Open the homepage on your phone. Without scrolling, can you tell what the business offers, who it serves and what the next step is?

You already know your business, so you are not the best judge of this. Ask someone who has not seen the project to find a service, check whether it suits them and start an enquiry. Give them a task, not instructions on where to click.

Watch where they hesitate. A button labelled “Explore” may look tidy, but “See installation options” gives people a clearer reason to press it. Navigation built around internal department names may make sense to staff and confuse everyone else.

Check the pages people will actually land on, too. A visitor arriving from search may never see the homepage. Every important service page needs enough context to stand on its own, plus a clear route forward.

Avoid approving a design solely from screenshots. Screenshots show appearance, not whether someone can complete a useful task.

2. Does the enquiry reach the right place?

Submit a real test enquiry through every form. Then follow it all the way through: confirmation on screen, notification to the business and any record created in your CRM.

A message saying “Thanks, we’ll be in touch” proves only that the website displayed a message. It does not prove anyone received the details.

Try a missing required field, an invalid email address and a longer message. Check that errors explain what to fix without wiping out everything the visitor already typed. On a phone, make sure the keyboard does not hide the submit button or make the form awkward to finish.

Ask where submissions are stored and what happens if notification emails fail. If email is the only record, a delivery problem could leave the business unaware of an enquiry. A stored submission gives staff another place to check, with appropriate access controls and a clear retention policy.

Also check spam protection. It should reduce junk without turning a straightforward enquiry into an obstacle course.

Agree who will check enquiries after launch. A working form still needs a working process behind it.

3. Does it work beyond the designer’s laptop?

Test the main customer journey on a real phone using mobile data, not just a desktop browser resized to look narrow. Large images, background video and third-party widgets can feel very different away from a fast office connection.

You do not need to understand every performance score. Ask the builder to explain what is slowing down important pages, what they have tested and what trade-offs remain. A score alone is not an acceptance test; people still need to read, navigate and submit forms comfortably.

Check basic accessibility yourself. Can you move through links and form fields using the keyboard? Can you see which item has focus? Does text remain readable when you zoom in? Are form fields clearly labelled?

These checks do not replace a proper accessibility review, but they can expose obvious problems before launch.

Avoid accepting “it works on my machine” as the end of the conversation. Agree which browsers and devices the build supports, then have the key tasks tested on that basis. Record any known issues rather than leaving them as vague promises to fix later.

4. Can your team make ordinary changes?

Ask for a live demonstration using the actual editing system. Better still, take the controls yourself.

Change an opening time, replace an image and update a service description. Preview the changes before publishing. Check that an unusually long heading or a different-shaped photo does not break the layout.

Not every website needs an elaborate content management system. It does need a sensible way to handle the changes your business makes regularly. If each small edit requires a developer, that is an ongoing cost and scheduling dependency you should understand before signing off.

The opposite extreme is not ideal either. An editor with dozens of unrestricted layout controls can make simple updates harder and let staff accidentally damage a page. Useful flexibility means control over the content you need, with guardrails around the design.

Ask which roles can edit, publish and manage users. Request a short handover guide based on your website, not just a link to a platform’s general documentation.

5. Is the full cost clear after launch?

A build quote is only part of the cost. Before approving it, ask for a written breakdown of the initial work, recurring charges and anything billed separately.

That should cover hosting, domain renewal, paid software, maintenance and support. Where services charge by usage, ask what drives the bill: submissions, storage, email volume or something else. Check whose account holds each subscription and who receives renewal notices.

A fixed price is useful when the scope is clear. Confirm which pages, integrations, content work and tests are included, along with how additional requests are priced. A low headline figure is not a bargain if essential work sits outside it.

For care plans, ask what “maintenance” means. Backups, updates, monitoring and content edits are different services. Find out who handles a broken integration, what support hours apply and how a backup would be restored.

Finally, request access to the accounts and files you are entitled to under the agreement. Handover should be a planned part of delivery, not a negotiation when you want to change suppliers.

At PrimeVibers, we build custom websites on a fixed-price scope, with launches planned in weeks rather than months. If you want help defining what your website needs to do—and how you will know it works—contact us.