For the person doing the hiring. Writing a brief that attracts bids you can actually compare, arriving at a budget when you have no reference point, filtering a pile of proposals down to a shortlist in an afternoon, and interviewing someone whose craft you cannot assess yourself. Practical, and written on the assumption that hiring a freelancer is not your full-time job.
Hiring a developer when you cannot run a technical interview is a solvable problem. Decide whether you are buying a build, a fix or maintenance; learn the four role shapes and which one your job needs; specify hosting, domain and code access before anyone quotes; and agree the handover checklist on day one, not at the end.
“What does a website cost?” has no answer, and any figure you read online was invented for someone else's project. Here is a method instead: three budget models and when each one fits, how to turn scope into a range you can defend, and why the cheapest bid is usually the most expensive outcome.
A pile of proposals is not a problem of judgement, it is a problem of process. A two-pass filter that gets you from twenty proposals to four serious candidates in an afternoon, the four questions that separate people who do the work from people who describe it, and a 20-minute call agenda that actually decides something.
Twenty proposals and not one you can compare? The problem is usually upstream, in the brief. Here are the six things every project brief must state — outcome, scope boundary, what you supply, budget range, timeline and how you will judge “done” — plus the same job posted badly and posted well.