Choosing a web developer is difficult because you are being asked to judge technical quality you cannot assess directly. The usual result is that people pick on price or on how nice the portfolio looks, and both are weak signals. This guide covers what actually predicts a good outcome.
Key takeaways
- A good developer asks about your business before quoting. One who quotes immediately is guessing.
- Test the portfolio, do not just look at it - open the sites on your phone and time them.
- Ownership of domain, hosting, code, and content should be explicit and in writing.
- Ask what happens after launch. Most disappointment lives in the support gap, not the build.
- The cheapest quote and the most expensive quote both need the same scrutiny.
Start by knowing what you are buying
Before you approach anyone, get clear on what the site is for. "We need a new website" is not a brief, and it produces quotes that cannot be compared with each other.
- What should a visitor do on this site - call, book, buy, request a quote?
- Roughly how many pages, and who writes the words?
- Do you need to edit it yourself, or is once-a-year updating fine?
- What must it connect to - booking, invoicing, CRM, payments?
- What is one new customer worth to you? This sets a sensible budget better than anything else.
Check the portfolio properly
Screenshots on an agency site prove very little. Twenty minutes of real checking tells you more than any sales call.
- Open three of their sites on your phone, on mobile data. This is how most of your customers will arrive.
- Time the load. If you are waiting and wondering, so is a customer.
- Run one through Google PageSpeed Insights and check the mobile score. You do not need to interpret the details; the number is informative on its own.
- Check the sites are still live. Portfolios full of dead links suggest clients who left.
- Try to complete the main action - submit a contact form, start a booking. Broken forms in a portfolio are remarkably common.
- Ask for a reference in a similar industry and actually make the call.
The questions worth asking
You are not testing their technical knowledge. You are testing whether they think about your business, and whether they are straight with you when the answer is inconvenient.
Ask these, and listen to how they answer
"What would you not build for us?"
A good developer will talk you out of something. One who agrees with every idea is selling hours, not outcomes.
"Who owns the code and the content?"
The answer should be "you", instantly and without qualification.
"What happens if we want to leave in two years?"
Watch for hesitation. Lock-in is usually built in early and discovered late.
"What is not included in this quote?"
The exclusions tell you more than the inclusions. Content, photography, and post-launch changes are common surprises.
"How do you handle changes mid-project?"
You want a defined process, not "we'll sort it out", which reliably becomes an awkward invoice.
"What does support look like after launch?"
Ask about response times, who does backups, and who applies security updates.
Red flags
| Signal | Why it matters |
|---|---|
| Quotes before asking about your business | They are pricing a template, not solving your problem |
| Guarantees a #1 Google ranking | Nobody can guarantee this. It is a reliable marker of a bad-faith pitch |
| Will not put scope in writing | Every disagreement later becomes your word against theirs |
| Registers the domain in their own name | Your business identity becomes their asset |
| Vague about hosting access | Often means you cannot leave without a rebuild |
| Pressure to sign quickly | Discount deadlines on custom work are a sales tactic |
| No written support terms | Predicts the most common source of post-launch frustration |
Freelancer, studio, or agency?
The labels matter less than people assume. A good freelancer beats a bad agency comfortably, and the reverse is equally true. What actually differs is capacity and risk profile.
A freelancer or small studio typically gives you direct access to the person doing the work, faster decisions, and lower overhead. The risk is availability: one person gets sick, gets busy, or moves on. A larger agency offers continuity and a broader skill set, at higher cost, and often with a more junior person on your actual project than the one who pitched.
Ask directly: who will do the work, and what happens if that person becomes unavailable? A straight answer either way is a good sign.
What should be in the agreement
- Deliverables, listed specifically, with explicit exclusions.
- Milestones and payment schedule tied to those milestones.
- Number of revision rounds included, and the rate beyond that.
- Ownership: domain, code, content, images, and all account access transfer to you.
- What happens if the project stalls on either side.
- Post-launch support: what is covered, response times, and cost.
- Who is responsible for hosting, backups, and security updates after launch.
That last line is the one most often left undefined, and it is where a surprising amount of trouble originates. If nobody is contractually responsible for updates and backups, the practical answer is that nobody is doing them.
Frequently Asked Questions
Enough variation exists that any single number would be misleading. What protects you is comparing like with like: same page count, same content responsibility, same support terms.
Want a straight assessment before you commit?
A Lead-Ready Website Audit looks at your current site, your enquiry flow, and your follow-up, then tells you what is actually worth fixing - including when the answer is that you do not need a rebuild.
Review Pricing