Start with the same brief for everyone
A low quote is attractive, but it is difficult to judge until you know what it covers. Two proposals may both promise a “new website” while describing very different work. One may include help organizing content and testing the finished pages; another may expect you to supply polished copy and handle testing yourself. The better question is not simply “Which costs less?” but “Which proposal offers the right work, responsibilities, and outcome for this site?”
Give each prospective provider the same short brief before asking for a proposal. Describe the site’s purpose, its main audiences, the tasks visitors should be able to complete, and any existing content or systems that must be retained. Note practical constraints, such as who can approve decisions and who will maintain the site. If you do not yet know the number of pages or required features, say so. A provider can then explain how they would define the scope rather than guessing.
Compare deliverables, not labels
Read each proposal as a list of things you will receive. Look for specifics: a sitemap or page plan, design concepts, page templates, content migration, forms, training, testing, and launch support. “Design and development” alone does not tell you whether these tasks are included. Note what is explicitly excluded, too. An exclusion is not necessarily a problem if you can handle that work or budget for it separately.
Pay particular attention to content. Who writes, edits, enters, and checks the text and images? If your team supplies them, when are they needed and in what format? Content delays can affect the rest of a project, even when the technical work is straightforward. Ask how changes to the agreed scope will be identified and priced. This makes it easier to distinguish a well-bounded proposal from one whose price depends on assumptions you have not seen.
Look at how the work will happen
A proposal should give you a workable picture of the process, not just a finished product. Look for stages, review points, and a clear route for feedback. Who is your main contact? How many rounds of review are included? What must your team approve before the next stage begins? A simple process with named responsibilities often serves a small organization better than an elaborate schedule it cannot support.
Check how the provider plans to address accessibility and everyday use. They might describe how they will structure headings and navigation, check forms and keyboard use, and test pages at different screen sizes. Broad promises such as “fully accessible” are less useful than a description of what will be checked and how issues will be handled. Also ask to see how a site editor would update a common page. A site that looks good at launch should remain manageable for the people who will use it.
Understand ownership and life after launch
The handover can affect the site for years. Compare what each proposal says about access to the domain, hosting, content management system, design files, and accounts used by the website. Your organization should know which services it will pay for directly, which recurring charges are expected, and what it would need to move the site or work with another provider later. If the proposal is unclear, ask for a plain-language explanation before making a decision.
Look beyond the launch date as well. Does the price include training, documentation, a short period for fixing defects, or ongoing maintenance? Who handles updates, backups, and support requests afterward? These services do not have to come from the project provider, but someone needs to own them. Comparing these arrangements may reveal that a higher initial price includes useful preparation, or that a lower-priced proposal is a good fit because your team can confidently handle the remaining work.
Make a decision you can explain
Create a comparison sheet with a row for each priority: required deliverables, content responsibilities, process, accessibility approach, editing experience, handover, post-launch support, and total expected cost. Mark each item as clear, unclear, or not included. Send the same follow-up questions to providers where possible, then update the sheet with their answers. This keeps a polished presentation or one striking price from hiding important gaps.
Finally, weigh the trade-offs against your capacity. A small site with an experienced editor may need less content support than a team publishing for the first time. A proposal is a strong fit when you understand what you are buying, what you must contribute, and what you will be able to do after launch. Price still matters, but it becomes one informed part of the decision rather than the only measure.
