How to Choose a Website Developer: 12 Questions

Judge a developer on three things: evidence they've shipped comparable work that's still live, a written fixed scope you can hold them to, and clear ownership terms giving you the domain, the code and the hosting. Portfolio screenshots, team size and a polished sales deck predict very little.

This post is the checklist — the specific things to open, run and ask, in order. If what you want instead is how to read the conversation when you don't know how to code, how to hire a web developer covers the judgement side and pairs with this one.

Step 1 — Write down what the site has to do, in business terms

Not "modern and professional". Specifics somebody could measure:

• "Generate at least 10 qualified enquiries a month from Auckland and Waikato"
• "Let customers book a service slot without phoning us"
• "Let our office manager add a service page without calling a developer"

This one page is the most valuable thing you'll produce in the whole process. It's how you compare quotes, how you spot someone selling you a bigger project than you need, and what a good developer will push back on before quoting. If nobody asks to see it, that tells you something.

Step 2 — Freelancer, small studio, or agency

The price gap is mostly structural rather than a quality difference. One Auckland studio publishing its own numbers is direct about it: CBD agencies typically quote $15,000–$30,000+ for projects lower-overhead providers deliver for $4,000–$8,000, and the difference is offices and account layers rather than capability. Pay agency rates when you genuinely need agency breadth.

Step 3 — Audit their live work, not their portfolio images

Ten minutes of this eliminates most of the field, and none of it requires technical knowledge.

1. Ask for three live URLs

From the last two years, in a category like yours. Mockups only, or links that 404? That's your answer, and it arrived cheaply.

2. Open each one on your phone, on mobile data

Not on wifi. Mobile data is how a real customer arrives, and it's where a heavy site stops being an abstract complaint.

3. Run each through PageSpeed Insights

Use PageSpeed Insights and read the mobile field data. You aren't looking for perfect scores — you're checking they don't ship 4MB homepages to people on a phone.

4. View source and look for three things

You don't need to read code. Look for alt text on images, and a title and meta description that aren't the theme's defaults. A well-built page's head is short and specific:

<!-- Specific to this page. If every page shares one title, nobody set them. -->
<title>Emergency Plumber in Hamilton — On Site Today</title>
<meta name="description" content="24/7 emergency plumbing across Hamilton and Waikato. Fixed prices quoted before we start." />
<link rel="canonical" href="https://example.co.nz/services/emergency-plumbing" />

<!-- Real alt text describes the image. "image1.jpg" is a tell. -->
<img src="/img/team-van.webp" width="1200" height="675"
     alt="Two plumbers unloading equipment from a branded van" />

5. Tab through with your keyboard

Press Tab repeatedly from the top of the page. If you can't reach the navigation and the contact form with the keyboard alone, they don't build accessibly — whatever the proposal claims.

6. Ask for one client reference you can phone

Then ask that client exactly one question: what went wrong, and how was it handled? Every project has a problem. The handling is the signal, and a reference who can answer it specifically is worth more than five written testimonials.

If they build applications rather than brochure sites, ask for a public repository or a code sample as well. A developer who can't show code in any form is a strange thing to hire for a coding job.

Step 4 — Send these 12 questions in writing

In writing, so you can compare answers side by side. The wording of a bad answer is usually more revealing than its content.

On scope and money

• What exactly is included, itemised — design, build, content, migration, testing? A single-line total can't be compared with anything.
• What is explicitly not included? Good providers answer this fast and specifically. Vagueness here is where variation invoices are born.
• What happens when I ask for something outside scope mid-project? Absorbed, quoted as a variation, or billed hourly — there's no wrong answer, only knowing in advance.
• What's the payment schedule? Halves or thirds against milestones is normal. Payment in full up front, to someone you've never worked with, is not.

On ownership — the ones people forget

• Who owns the domain, and whose name is on the registration? It must be yours. Domains registered in a provider's name are the most common hostage situation in this industry.
• Who owns the code and the repository when we're finished? Full access to source control, not a zip file emailed at handover.
• If we part ways, what do I walk away with? Get the specific list: domain, hosting credentials, repository, CMS admin, analytics property, design files.

On what happens after launch

• Who fixes it if something breaks in week three? Is there a warranty period? Most reasonable providers include 30 days of bug fixes on their own work.
• What are the ongoing costs, all of them? NZ ranges run roughly $20–$100/month for hosting and $50–$300/month for maintenance — the full picture is in annual website maintenance costs in NZ.
• Can my team edit content without you? Ask for a demo of the actual editing interface before you sign. "Yes, it's easy" is not a demo.

On process

• What do you need from me, and by when? The right answer names content, images, brand assets and feedback deadlines. Projects run late waiting on client content far more often than on developer capacity.
• What's your communication rhythm? A weekly update, a named channel, an expected response time. Three weeks of silence mid-project is the most common complaint about web work, and the most preventable.

Step 5 — Read the proposal for what's missing

Cheap quotes usually aren't cheap because someone is being generous with you. Scan specifically for:

• Redirect mapping — 301s from old URLs to new ones. Omitting this can cost years of accumulated search visibility on launch day.
• Testing — which browsers and which devices, stated explicitly?
• Accessibility — is WCAG 2.1 AA named, or is it assumed you won't ask?
• Performance targets — "fast" is not a target. Core Web Vitals thresholds are.
• Content responsibility — who writes it, page by page.
• Training and handover — a recorded walkthrough of your CMS is worth more than a PDF nobody opens.

Two quotes with identical totals can differ by weeks of work in those six lines alone. For what the totals themselves should look like, website redesign cost in New Zealand has the current bands.

Step 6 — The red flags

Any one of these is a conversation. Two or more, walk away.

• Guarantees a #1 Google ranking. Nobody can promise this. It signals either dishonesty or inexperience, and both are expensive.
• Won't put scope in writing. "We'll figure it out as we go" means you'll pay for it as you go.
• Registers the domain in their own name. Non-negotiable. It's yours.
• Their own site is slow, broken, or three years stale. It's the one piece of work they controlled completely.
• Quotes five figures without asking about your business. They're quoting a template, and you're the one who'll discover what it doesn't cover.
• Can't name the platform they'd use, or why. "Whatever you prefer" is an absence of opinion, not flexibility.
• Pressure tactics — a price expiring Friday on a three-month project.
• No contract. Even a single page covering scope, price, timeline, ownership and payment protects you both.

What good actually looks like

The developer worth hiring does things that feel slightly uncomfortable at the sales stage. They ask what the site should achieve commercially before they'll quote. They tell you when a cheaper option serves you better, and mean it. They name what they're not good at. They write a scope that constrains them as much as it constrains you. And they ask about content deadlines early, because they've been burned by that before.

Someone who agrees with everything in a sales call will agree with everything during the project too — including the changes that quietly double the scope.

Frequently asked questions

What questions should I ask a web developer before hiring?

Ask for an itemised scope, what's explicitly excluded, how out-of-scope requests are handled, who owns the domain and the code, what happens if something breaks after launch, what all the ongoing costs are, and whether your team can edit content without them. Send them in writing so the answers can be compared side by side.

Should I hire a freelancer or an agency for my website?

Hire a freelancer or small studio for straightforward business sites and mid-complexity applications. NZ providers themselves put the same work at $15,000–$30,000+ agency-side against $4,000–$8,000 from lower-overhead providers, and describe the gap as overhead rather than quality. Choose an agency when you need brand strategy, multi-channel campaigns, or genuine team depth.

Who owns the code when you hire a web developer?

You should, and it has to be stated in writing before work starts. Confirm you'll receive the domain registered in your name, full repository access, hosting credentials, CMS admin and the analytics property. A zip file emailed at handover is not repository access.

How do I know if a web developer is any good?

Check three sites they built recently: load them on mobile data, run them through PageSpeed Insights, and try navigating with only the keyboard. Then phone one past client and ask what went wrong and how it was handled. That's ten minutes and it outperforms any portfolio page.

What are the biggest red flags when hiring a web developer?

A guaranteed #1 Google ranking, no written scope, registering your domain in their name, a slow or outdated site of their own, and quoting a large project without asking anything about your business. Any one warrants a question; two or more warrants walking away.

Where to start

Write the one-page brief from Step 1 first. Everything else in this post gets easier once it exists, and the people worth hiring will ask for it unprompted.

If you're at the quoting stage, bring me that brief and I'll tell you honestly whether the scope makes sense — including if I think you'd be better served elsewhere. When the quotes come back, what should be in a web development quote is the line-by-line checklist to hold them against. Get in touch, or see recent work.