Three proposals arrive. All three portfolios look good. All three promise quality, communication and results, and the prices differ by a factor of four with no visible explanation.
The problem is that the things that distinguish a good build from a bad one are almost all invisible in a portfolio. A screenshot cannot tell you what the site weighs, whether it is accessible, whether the code can be handed to someone else, or whether anything will still be maintainable in two years. So ask about those directly.
1. "Can I see a site you built and run it through PageSpeed Insights with you?"
Do it live on the call, on a real client site, on mobile. This is the single most revealing question available to you, because it is objective and unpreparable.
You are not looking for a perfect score real sites carry marketing tags and third-party embeds a developer does not control. You are listening to the explanation. A good answer sounds like: "That LCP is the hero image; we set it to load eagerly and the client later replaced it through the CMS without dimensions." A bad answer dismisses the tool.
2. "What happens if we stop working together in six months?"
You want: the repository is yours and always has been, the hosting is in your account, the domain is registered to you, and there is documentation good enough for someone else to continue.
The warning signs are a proprietary platform you would have to keep licensing, hosting only they can access, a domain registered in their name, or a build process that lives on one person's laptop. Some of this is deliberate lock-in. Some is just sloppiness. Both leave you stuck.
3. "Who specifically will write the code?"
Ask whether the people in the meeting are the people building it. Agencies that sell with seniors and deliver with juniors are common and not automatically wrong but you should know, and a junior team needs review, which costs time somebody has to have budgeted.
4. "How do you approach accessibility?"
A good answer is specific and slightly unglamorous: semantic HTML, keyboard operability, visible focus states, contrast checked against a standard, real form labels, and testing with a screen reader on the important flows. It may include "here is where we would push back on a design".
A weak answer is "we follow best practices", or a promise of full WCAG AAA compliance which almost nothing achieves and which suggests the standard has not been read.
5. "What is your performance budget, and where is it enforced?"
The word you want is enforced. A target that lives in a proposal is a wish. A target checked in the deployment pipeline is a constraint, and it is the only version that survives contact with the third month of a project.
6. "How will I edit content?"
There is no universally right answer, but there is a right process: they should ask what you actually intend to change and how often before recommending anything. A CMS you never use is cost and attack surface; no CMS when you publish weekly is a bottleneck that turns into a retainer.
7. "What does this cost to run per year?"
Hosting, domain, certificates, any services or licences, and maintenance. A partner who has thought about the whole lifecycle answers immediately. One who quotes only the build has told you something about how they think about the relationship afterwards.
8. "Tell me about a project that went badly."
Everyone has one. The answer you want takes some responsibility a mis-scope, a bad technology choice, a late discovery and describes what changed as a result. An answer where the client was entirely at fault tells you how the post-mortem on your project will read.
9. "What would you tell us not to do?"
A partner with judgement will have opinions: the CMS is unnecessary, the animation will hurt more than help, the timeline is optimistic, this should be an off-the-shelf product rather than a build. Someone who agrees with everything in a first meeting will keep agreeing right up until the invoice.
On price
Wide price ranges for apparently identical scope usually mean the scopes are not identical. Before comparing numbers, check each proposal for: whether design is included or assumed, how many revision rounds, who writes the copy, whether responsive means tested on real devices, what accessibility work is included, whether there is a testing phase, what the support window is, and who owns the result.
Cheap proposals are often cheap because half of that list is absent, and each missing item comes back later as a change request. The most expensive proposal is not automatically the most thorough either but a proposal that itemises what it excludes has usually been thought about.
The underlying signal
You are looking for someone who asks you more questions than you ask them. A partner who wants to know what the site is for, who reaches it, what happens after they convert, and what has failed before is thinking about your outcome. One who wants a page count and a deadline is thinking about a deliverable.