Start with the outcome, not the estimate
Two website proposals can show very different prices while describing very different jobs. Before comparing them, write down what the website needs to help people do. A small community organization, for example, might need visitors to understand its services, find eligibility information and submit an enquiry. Those goals are more useful than a vague request for a modern-looking site.
Give each vendor the same short brief: intended audiences, essential tasks, existing content, required features, decision-makers and a realistic launch window. Then ask how their proposal addresses those points. If one estimate includes help organizing service pages and another assumes your team will deliver finished copy, the difference is not simply a cheaper way to build the same website.
Turn each proposal into a comparable scope
Make a comparison sheet with a column for each vendor and rows for the work that matters: discovery, site structure, design, content, development, testing, training and launch. Record what is included, what your team must provide and what is excluded. Look for concrete deliverables rather than broad phrases such as “custom design” or “SEO ready.” How many page layouts will be designed? Who will enter content? Which devices and browsers will be tested?
Pay close attention to assumptions and change requests. A proposal may cover ten pages, but your existing site may have thirty pages that need review or relocation. Ask what happens if the final page count grows, feedback arrives late or an additional form is needed. A clear process for approving changes protects both sides; it also makes the likely total cost easier to understand.
Check how the vendor handles the visitor experience
A useful website should work for the people it serves, not just look convincing in a presentation. Ask vendors how they will plan navigation, make important tasks easy to find and review designs with real content. For the community organization, a service page should explain who the service is for and what to do next. An attractive template cannot make up for missing or confusing information.
Accessibility deserves specific questions. Ask how the vendor approaches readable text, keyboard use, form labels, image descriptions and testing. No brief proposal can guarantee that every future page will be accessible, especially if staff will add content later. It can, however, explain what the vendor will build and test, what training your team will receive and who will fix issues found before launch.
Understand ownership, measurement and everyday upkeep
The launch price is only part of the commitment. Identify recurring charges for hosting, software, domains and support, along with who pays each bill and controls each account. Ask whether your organization will own its content and have access to the website, analytics and domain settings. Find out how staff will edit common pages, what training is included and what it would take to move to another provider later.
Measurement should connect to the goals in your brief. Rather than accepting a promise to “install analytics,” ask which useful actions will be tracked, such as completed enquiry forms, and who will check that tracking works. Ask about routine upkeep too: software updates, backups, account permissions and how problems are reported. A vendor may handle these tasks, or your team may need to arrange them separately; either approach should be explicit.
Choose with a short decision process
Once you have clarified the proposals, score each one against a small set of priorities. You might give the most weight to fit with your goals, clarity of scope, accessibility approach, your team’s ability to manage the site and total ongoing cost. Note unanswered questions beside each score rather than treating an omission as a promise. Send the same follow-up questions to every shortlisted vendor.
Finally, ask each vendor to walk through a realistic workflow: from receiving your draft service information to publishing a finished page, then correcting an issue after launch. This reveals who does what, when your team must respond and where extra costs might arise. The best choice is not automatically the lowest quote or the longest feature list. It is the proposal that gives your organization a workable site and a clear understanding of how to run it.
