Two website proposals can describe the same five-page business site and still represent completely different products. One includes customer research, original copy, responsive design, accessibility review, search foundations, analytics, security, training, and a clean handover. The other includes a theme, five empty page layouts, and a list of extras that appears after the deposit is paid.
The screenshots may look equally polished. The difference appears later: when Google cannot understand a service page, a contact form sends personal information somewhere nobody reviewed, the owner cannot access the domain account, a mobile button is difficult to use, or every small text change becomes a new invoice.
For a Toronto contractor, an Ontario professional practice, or a Canadian online service, the website is usually a sales and trust system—not a digital brochure that is finished when the colours look right. The provider should understand who needs the service, what those people must learn, which action they should take, and how the business will operate the site after launch.
Prepare a one-page brief before contacting designers
You will receive better proposals if every company starts with the same facts. Write down the business goal, primary customer, main services, service area, required pages, important integrations, examples you like, target launch window, available content, decision maker, and realistic budget range. Include what success should look like six months after launch.
- Primary outcome: qualified enquiries, appointments, sales, applications, donations, downloads, or credibility.
- Priority customer: who they are, what problem brings them to the site, and what makes them hesitate.
- Required functions: forms, booking, payments, multilingual pages, customer portal, CRM, newsletter, or inventory.
- Content reality: what copy, photography, video, branding, testimonials, policies, and service details already exist.
- Constraints: accessibility, privacy, regulatory, security, procurement, hosting, or internal approval requirements.
- Measurement: the actions and business results that will indicate whether the project is working.
Do not force the provider to quote a solution before sharing the problem. At the same time, avoid a vague request for a modern website. Without an agreed outcome and scope, the lowest price often reflects the most optimistic assumptions rather than the best value.
1. What business outcome will you design for?
Listen for a specific answer tied to customer behaviour. A useful response might describe how service pages will answer buying questions, how calls and forms will be tracked, how trust evidence will be placed, or how the path from local search to quote request will be shortened. A vague promise to make the brand stand out does not define a measurable result.
Ask the company to name the primary conversion and two or three supporting signals. For a service business, these could be qualified quote requests, phone calls from service-area customers, booking completions, or downloads that lead to a sales conversation. Traffic can be useful, but more visitors are not automatically better if they are looking for something the business does not sell.
2. Can you explain the results and constraints behind relevant work?
A portfolio should start a conversation, not end one. Ask which parts the company actually delivered, what the client needed, what limitations existed, how the solution was tested, and what changed after launch. A team may show a beautiful site while another agency wrote the copy, built the application, or managed search visibility.
Relevant does not mean identical. A provider does not need three plumbing sites to understand a plumber. Look for evidence that it can learn a business, organize complex information, communicate trust, and solve similar conversion, integration, accessibility, or operational problems. Ask permission before expecting confidential analytics or client details.
3. Exactly what is included—and who supplies each input?
Request a page and deliverable list. It should identify discovery, information architecture, wireframes, design rounds, development, copywriting, editing, images, forms, integrations, analytics, SEO setup, accessibility work, testing, redirects, training, launch, warranty, and ongoing support. If an item is excluded, that is not automatically a problem; it becomes a problem when nobody notices until launch week.
| Deliverable | Question to settle | Evidence in the proposal |
|---|---|---|
| Copy | Who researches, writes, approves, and enters it? | Page list, revision count, and word or scope assumptions |
| Images | Are photography, stock licences, editing, and alt text included? | Source, licence responsibility, format, and optimization |
| Forms | Where do submissions go and how are failures handled? | Fields, routing, spam control, consent text, and testing |
| SEO | Which technical and on-page tasks are delivered? | Titles, descriptions, headings, canonicals, sitemap, redirects, and indexing checks |
| Launch | Who changes DNS, verifies production, and can roll back? | Launch plan, responsibilities, acceptance checks, and warranty |
4. Which platform do you recommend, and why does it fit this business?
WordPress, Shopify, Squarespace, Webflow, a static site generator, and a custom application can all be reasonable choices. The answer should connect the platform to editing needs, integrations, security, accessibility, performance, ownership, team skills, expected change, and total operating cost.
Ask what happens when the site grows. Can the business add a service, location, language, campaign page, or integration without rebuilding everything? Also ask what the platform cannot do well. A provider that explains a limitation and offers an alternative is more useful than one that presents its familiar tool as the answer to every problem.
5. How will you test mobile usability and accessibility?
Responsive does not mean a desktop layout shrinks without breaking. Ask which real devices, screen widths, browsers, keyboard interactions, zoom levels, and assistive checks are included. Forms, menus, popups, cookie controls, booking widgets, and payment flows deserve special attention because third-party components can undermine an otherwise careful design.
W3C's WCAG 2.2 guidance covers text alternatives, keyboard access, focus behaviour, contrast, labels, errors, structure, and other requirements that make content usable by more people. Ontario's legal requirements depend on organization type and employee count; the province states that designated public-sector organizations and businesses or nonprofits with 50 or more employees must make public websites accessible. Smaller organizations still benefit from building accessibility into the project instead of treating it as a late repair.
6. What search foundations are included at launch?
Google says there is no guarantee that a site will be indexed or rank, and a trustworthy website company should say the same. Search work should focus on helping people and search systems understand useful content: clear page purpose, descriptive titles and headings, crawlable links, canonical URLs, a sitemap, helpful copy, image text alternatives, and correct handling of moved or removed pages.
Ask who selects the primary search intent for each page and how pages will avoid competing with one another. A homepage cannot realistically target website design, every service, every city, every industry, and every question. A sensible information architecture gives important services their own useful pages and connects them with descriptive internal links.
7. How will the website support local discovery?
A local strategy should reflect where the business genuinely operates. Useful work may include consistent contact and service-area information, a complete Google Business Profile, relevant local service pages, original project evidence, customer questions, and links between the website and business profile. Repeating a city name in every heading is not a local strategy.
Google advises businesses to keep Business Profile information accurate and complete. Ask whether the website company will align the business name, category, contact details, service description, hours, photos, and destination pages without creating misleading locations. For a service-area business, confirm that the plan follows Google's representation rules rather than inventing offices to target more cities.
8. What performance standard will the finished site meet?
Request measurable launch targets and the conditions under which they are tested. Google's current Core Web Vitals guidance defines good experiences as Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less, evaluated at the 75th percentile of visits. A pre-launch lab test cannot guarantee field results, but it can reveal oversized media, blocking scripts, unstable layouts, and slow server responses.
Ask how fonts, video, tracking tags, chat widgets, maps, third-party booking, and content-management plugins affect the result. A fast empty template is not evidence that the populated production site will remain fast. The proposal should state who optimizes final images and content and whether performance monitoring continues after launch.
9. How will the site be secured, backed up, and monitored?
The Canadian Centre for Cyber Security recommends integrating security into website design and ongoing management. Ask about HTTPS, administrator MFA, least privilege, software updates, dependency review, secure forms, spam and abuse controls, vulnerability response, logging, monitoring, backups, restore testing, and incident contacts.
Clarify the boundary between host, platform, developer, managed provider, and business owner. A managed platform may patch its infrastructure while the business remains responsible for compromised administrator accounts, unsafe plugins, exposed API keys, misleading form permissions, or unreviewed integrations. Request a schedule for updates and proof that a representative backup can be restored.
10. How are privacy, forms, analytics, and consent handled?
List every place the site collects or receives information: contact forms, newsletter forms, bookings, payments, analytics, advertising pixels, chat, embedded video, maps, applicant forms, and customer portals. Ask what data is collected, why it is needed, where it is sent, who can access it, how long it is kept, and how it is deleted.
The Office of the Privacy Commissioner of Canada advises businesses to make privacy information specific to their actual practices rather than copying boilerplate. It also emphasizes meaningful consent for collecting, using, and disclosing personal information. The web company can implement technical controls and explain integrations, but the business should obtain appropriate privacy or legal advice for its activities and jurisdiction.
11. Who owns the domain, accounts, code, content, and design files?
The business should normally be the registered holder of its domain and have direct access to the registrar, DNS, hosting, analytics, Search Console, Business Profile, content system, source repository, media, and paid licences it funds. The provider can receive delegated access. Avoid arrangements in which a former freelancer's personal email is the only recovery path for the domain or hosting account.
ICANN states that registrants have rights to information about registering, managing, renewing, restoring, and transferring domain registrations. Confirm whose legal details appear on the account, who receives renewal notices, whether MFA and recovery contacts are configured, and how credentials will be handed over. The contract should also identify ownership and licensing for copy, photography, stock media, fonts, themes, plugins, custom code, and source design files.
12. What will be tested before acceptance?
Ask for a written acceptance checklist. It should cover supported devices and browsers, navigation, forms, emails, links, downloads, search, accessibility, performance, security, analytics, metadata, structured data, privacy controls, redirects, 404 behaviour, favicons, social sharing, and backup. Test with realistic content and customer journeys, not lorem ipsum.
Clarify who fixes defects found during acceptance, what counts as a new request, and when the warranty begins. A short review window is reasonable only when the business receives a stable staging site, enough time, and clear instructions. Final payment should align with agreed deliverables rather than a subjective feeling that the site looks finished.
13. What is the launch, migration, and rollback plan?
Replacing an existing site requires more than publishing new files. The team should inventory valuable URLs, map redirects, preserve useful content, transfer analytics and search verification, lower DNS time-to-live when appropriate, back up the old site, schedule the change, monitor errors, and retain a rollback path.
Ask who has authority to change DNS and what happens to email records. An incorrect DNS change can affect business email even when the website itself is working. After launch, verify forms, certificates, redirects, canonicals, robots rules, sitemap submission, analytics, key searches, and real mobile journeys from outside the provider's network.
14. What training, maintenance, and support are included?
Identify what the business can edit, who receives training, what documentation is delivered, and how support requests are prioritized. Ask for response targets for a typo, broken form, security incident, site outage, and new feature. These are different services and should not share one vague promise of ongoing support.
Request the recurring maintenance list: platform updates, plugin or dependency updates, backups, restore tests, uptime checks, security monitoring, licence renewals, content changes, accessibility checks, performance review, analytics reporting, and strategic recommendations. Confirm what is proactive and what happens only after the client opens a ticket.
15. What is the total cost, change process, and exit path?
Compare more than the build price. Include discovery, copy, photography, integrations, licences, domain, hosting, email, maintenance, support, analytics, accessibility work, security, taxes, and likely change requests over two years. A low initial quote can be appropriate for a simple site, but only if the business understands what it must supply and what future work costs.
The contract should define payment milestones, revision limits, approval delays, scope changes, cancellation, warranty, liability, account transfer, data export, source delivery, credential handover, and deletion of provider copies. Ask the company to describe a normal exit. A confident partner should not need to trap a client through control of the domain or missing files.
Use a scorecard instead of choosing from memory
| Category | Suggested weight | Evidence to review |
|---|---|---|
| Business understanding and conversion plan | 20% | Brief response, customer journey, measurement plan |
| Scope and content process | 15% | Deliverable list, responsibilities, milestones, revisions |
| Technical quality | 20% | Accessibility, performance, SEO, security, privacy, testing |
| Ownership and maintainability | 15% | Account model, documentation, editing, licences, handover |
| Relevant delivery evidence | 10% | Explained case studies, references, working examples |
| Support and communication | 10% | Named contacts, response targets, maintenance scope |
| Total value and contract clarity | 10% | Two-year cost, assumptions, changes, warranty, exit |
Adjust the weights to match the project. An online store may place more weight on integrations, security, and operations. A campaign site may emphasize launch date and conversion measurement. A public organization may have strict accessibility, procurement, privacy, and hosting requirements. Score the written evidence, then use interviews to resolve uncertainty.
Warning signs worth investigating
- Guaranteed first-place Google rankings or guaranteed AI recommendations.
- A quote produced without questions about customers, goals, content, integrations, or ownership.
- A portfolio with no explanation of the provider's role, constraints, testing, or outcome.
- The provider insists on owning the domain or keeping essential business accounts under a personal login.
- Accessibility, mobile testing, privacy, security, backups, and redirects are dismissed as unnecessary details.
- The proposal uses unlimited, fully optimized, or custom without defining what those words include.
- Recurring fees, licences, support boundaries, and exit costs are missing.
- The provider cannot explain how to restore the site, transfer it, or continue if a team member becomes unavailable.
A practical 30-day selection process
| Week | Action | Output |
|---|---|---|
| 1 | Define goals, customers, scope, content, constraints, budget, and success measures | One-page project brief |
| 2 | Shortlist three providers and send the same brief and questions | Comparable proposals and evidence |
| 3 | Interview delivery leads, check references, test account ownership and support assumptions | Completed weighted scorecard |
| 4 | Clarify scope, milestones, acceptance, costs, ownership, support, and exit terms | Signed agreement and kickoff plan |
The best choice is not necessarily the largest agency, the cheapest freelancer, or the provider with the most dramatic homepage. It is the team that understands the business, makes responsibilities visible, can deliver the required quality, and leaves the owner with a site that can be measured, maintained, secured, and improved.