Start with one customer and one decision
Before choosing a design, write a sentence describing who the website serves and what they need to decide. An exporter selling to distributors needs evidence about product fit, supply terms and the next business conversation. A local service business may need to explain coverage, availability and how to request an estimate. These are different content and inquiry requirements. Pick one primary visitor action, then identify the questions that must be answered before that action feels reasonable.
For example, a visitor looking for website development may need to understand the process, what they must supply, how scope affects cost and what happens after launch. A decorative homepage alone cannot answer those questions. Use them to draft a page list rather than starting with a list of visual effects.
Make a page and content inventory
Create a simple table with a row for every proposed page. Record the intended reader, their question, the page’s main action, the person supplying the content and whether that content is ready. Common pages include the homepage, individual services, about, contact and relevant policies. Give meaningfully different services their own pages; do not create multiple pages that repeat the same text with a city or keyword swapped.
Gather approved logos, product details, photography you have permission to use and verified company information. Mark missing material explicitly. If you do not have testimonials or project results you can substantiate, leave them out. Decide who will write and approve copy and whether translation or specialist review is needed. Content delays should be visible in the project plan.
Define what an inquiry really does
Specify how a visitor contacts the business and who receives the message. A form requires more than visible fields: delivery, error handling, spam controls and a suitable privacy notice need an agreed solution. Decide which information is necessary to qualify a request and avoid asking for sensitive information without a reason.
Test a real submission from a visitor’s perspective before describing a form as operational. A confirmation screen proves little if no one receives the inquiry. If backend delivery is still pending, label the form as a demonstration and provide a verified alternative contact route when one is available. Do not invent an email address simply to fill a layout.
Compare quotes using the same scope
Ask each provider to quote against the same page inventory and requirements. Clarify whether writing, migration, custom illustrations, languages, analytics, consent, commerce, booking, maintenance and hosting are included. A page count alone is a poor comparison if one proposal includes bespoke integrations and another uses static content.
Separate one-time implementation costs from recurring subscriptions and support. Ask who owns the domain, repository and provider accounts, what access you receive and how you can move the site later. Avoid selecting a proposal solely on an unexplained headline price. No single price or timeline applies to every small-business website.
Use a review checklist before handover
Review the site on a narrow mobile screen and desktop. Follow navigation with a keyboard, inspect visible focus, check text legibility and make sure controls have understandable labels. Click internal links, review the inquiry workflow and confirm that each important page has a distinct title and description. Check that search engines can reach the intended production pages and that the sitemap uses the correct origin.
Ask for documented build instructions, account ownership, backup or source access and a maintenance responsibility list. Agree who handles future content changes and technical updates. Your next step is a short brief containing audience, objective, page list, content gaps, required integrations and ownership expectations. That brief makes a consultation more useful than an open-ended request to “build a modern site.”