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.
Hiring a web developer is the hiring problem where the gap between the two sides is widest. You know what you want the site to do; you cannot evaluate how it is built, which means you cannot tell a good quote from a bad one, and you will not find out until months later when something needs changing. This guide is written for that position. It covers what to decide before you post, which kind of developer your job actually needs, the details that change a quote, how to assess ability without being technical, and the handover that determines whether you own your website or merely rent it from whoever built it.
First decide what you are actually buying
Three quite different jobs get posted as “need a web developer”, and they want different people, different pricing models and different contracts. Sorting yours into one of the three before you write a word will save you most of the confusion that follows.
- A new build. Something that does not exist yet. Defined scope, a finish line, best run as a fixed price or as staged milestones. This is the one where your brief does the heavy lifting.
- A fix or a change. An existing site with a specific problem or an addition. The main variable is not difficulty, it is how much of somebody else's code the developer has to understand first. Expect an investigation step before a firm quote, and treat anyone who quotes a fix confidently without seeing the code as optimistic.
- Ongoing maintenance. Updates, backups, small changes, the occasional emergency. This is not a project at all — it is a retainer or an hourly arrangement, and pricing it as a project is how both sides end up unhappy.
Many businesses need the first and the third. Those are two engagements, and it is usually worth agreeing the maintenance arrangement while you still have leverage — during the build negotiation, not after handover when your only option is whoever holds the code.
The four role shapes, and which one your job needs
“Web developer” covers work that shares almost nothing day to day. Hiring the wrong shape is expensive in a specific way: the person will usually manage, slowly, and the result will be functional but built at the edge of their competence.
| Role shape | What they build | Your job probably needs this if |
|---|---|---|
| Frontend | Everything the visitor sees and interacts with: layout, responsiveness, speed, accessibility. | Your site is mostly pages and content, or the design matters more than the logic behind it. |
| Backend | The parts nobody sees: data, accounts, business rules, integrations with other systems. | You need logins, records, calculations, or to talk to another company's system. |
| Full-stack | Both, to a working standard in each. | It is a small-to-medium project and you want one person accountable end to end. Most small business builds. |
| WordPress or no-code | Sites assembled on an existing platform, with configuration and theming rather than code from scratch. | You want a content-driven site, cheaper and faster, and you intend to edit it yourself afterwards. |
The fourth row deserves an honest note, because it is the right answer more often than the industry admits. For a brochure site, a blog, a clinic, a restaurant or a small catalogue, an established platform gets you a maintainable site faster and cheaper than custom code, and leaves you able to change your own text without hiring anyone. Custom development earns its cost when you have logic nobody has packaged: an unusual booking flow, an integration with your own inventory system, something the off-the-shelf options genuinely cannot do. If a developer proposes building from scratch what a platform does out of the box, ask them to explain what you gain — there is sometimes a real answer, and sometimes not. You can see the range of disciplines people actually work in on the categories listing before deciding which one to post under.
What to specify before anyone quotes
Most wildly divergent quotes are not disagreements about price. They are disagreements about facts, because each bidder filled in your blanks differently. Six details change a web development quote more than anything else, and all six are things only you know.
- Hosting and domain. Do you already have them, and can you provide access, or is buying and configuring them part of the job? If you do not know what you have, say so — that is a normal situation and a developer can find out, but it is work.
- Existing code, if any. What is the site built on now, who built it, and can you give access to the code and the admin panel? “There is an old site but I have lost the login” is a completely different job from “here is the repository”.
- Content. Who writes the words and supplies the images. This is the single most common cause of both stalled projects and surprise invoices.
- Integrations. Payments, a CRM, an accounting system, WhatsApp notifications, a shipping provider. Name each one, because each is a dependency on somebody else's system and a place a timeline can slip.
- Who edits it afterwards. If you want to change your own prices and text without calling anyone, that is a requirement, and it changes how the site should be built. Say it up front rather than discovering it after launch.
- Data you already have. Products, customers, old blog posts. Migration is real work, and its size depends entirely on how clean the existing data is — which nobody can judge without looking.
Assessing ability when you cannot run a technical interview
You do not need to evaluate code. You need to evaluate judgement, and judgement shows up in how someone talks about constraints and trade-offs. Four questions do most of the work, and the pattern you are listening for is the same in all of them: specifics, trade-offs and honesty about unknowns, rather than reassurance.
- “What would you build this on, and what would you give up by choosing that?” Everyone has a preferred tool. The useful signal is whether they can name its downside. Someone who says their choice has no trade-offs is selling, not advising.
- “What part of this job is least predictable?” For web work the honest answers are usually content, integrations with third parties, and migrating old data. If they name one of those, they have done this before.
- “How will I edit the site after launch, and can you show me?” Ask for a walkthrough of the admin experience on an existing project. This is the question most likely to reveal a build that will make you dependent.
- “What happens if the site breaks three months from now?” You are listening for whether they distinguish between a warranty for their own defects and paid support for new problems. Both are reasonable; leaving it undefined is not.
Beyond the questions, look at evidence you can verify yourself. Ask for two or three live URLs rather than screenshots, open them on your phone, and see whether they load quickly and work properly on a small screen — you are perfectly qualified to judge that. Where a profile carries a skill test badge, treat it as a genuine floor on the fundamentals rather than proof of judgement. And read the profile's rating for what it is — an average over a stated number of reviews, with no review text published behind it — then get the specifics on the call. The general shortlisting process, including a call agenda that fits in twenty minutes, is in how to shortlist and interview freelancers.
The handover checklist: owning your own website
This is the section people skip and later regret. A website you cannot access, change or move is not an asset you own; it is a service you rent from one individual. Agree the handover in writing before work starts, because at the end of a project your negotiating position is whatever the other side chooses to make it.
- Domain registrar account in your name, with you as the registrant and the login in your possession. Not the developer's account with your site in it.
- Hosting account in your name, same principle, with billing on your card or your company's.
- The code, in a repository you own or as a complete archive you have downloaded and opened once to confirm it is not empty.
- Every credential: admin panel, database, hosting control panel, any third-party service created for the project, DNS. Written down somewhere other than a chat thread.
- A short written note of what runs where, what the recurring costs are and when they renew, and anything a future developer would need an hour to work out.
- Intellectual property in writing. Agree that the custom work becomes yours on final payment, and that any third-party components used are properly licensed for your commercial use. This is exactly the clause worth naming in a scope of work — the contract and scope of work checklist covers it from the freelancer's side, which is useful to read before you negotiate it.
Structuring the engagement and narrowing a long list
For a build, use milestones with acceptance criteria you can test yourself: the approved design, the working build on a staging link, and launch with the handover items above delivered. Fund each stage so money is only released against work you have seen. For maintenance, agree a monthly arrangement with a stated scope, a response time for urgent problems, and what falls outside it.
Then narrowing the list is mostly mechanical. Post a scope with the six details above filled in — a brief that does that is described in how to write a project brief that gets good bids — and the quotes you get back will be close enough to compare. Drop the highest and the lowest, open the live sites of the rest on your phone, and take two or three to a call. Or work in the other direction and browse the freelancer directory yourself, shortlisting people whose recent work matches the shape of your job before you invite them to bid. Either way the deciding factor should be fit against your brief rather than who sounded most confident, because over a three-month build the person who asked the better questions is usually the one who finishes.
The takeaway: sort your job into a build, a fix or maintenance before you write a brief, and match it to the right role shape — full-stack for most small business builds, an established platform when your needs are content-driven rather than unusual. Specify hosting, existing code, content, integrations, who edits it afterwards and what data must move, because that is what makes quotes comparable. Assess judgement rather than code by asking what they would give up and what is least predictable. And agree the handover — domain, hosting, code, credentials, documentation and IP, all in your name — before the work starts, not after.