7 questions to ask before hiring a web developer (and the answers you should hear)
Hiring a web developer is a trust purchase: you can't fully evaluate the work until months after you've paid for it. But the right questions, asked up front, reveal almost everything about how a provider works. Here are seven — and the answers that should make you comfortable.
1. "Once we launch, can my team change things without you?"
You should hear an unambiguous yes, with specifics: what you'll be able to edit, what tool you'll use, and whether training is included. If updating a headline requires a support ticket and an invoice, you don't own your website — you rent it.
2. "What will the site be built with — and why that choice?"
You don't need to understand the answer technically — you need to hear a reason. "Because it's what we always use" is a red flag. A good answer connects the choice to your needs: speed, security, ease of editing, room to grow.
3. "Which SEO tasks are part of the base price?"
On-page SEO belongs in the base scope, itemised in writing: descriptive title tags, meta descriptions, a single H1 with logical heading structure, image alt text, canonical tags, an XML sitemap, a correctly configured robots.txt, and Google Search Console connected before handover. If any of that appears as a paid add-on, ask why.
4. "Who sets up SPF, DKIM and DMARC on my domain?"
This one catches almost everyone. Without those three DNS records, mail sent from your domain gets treated as suspicious — filtered to junk, delayed, or silently dropped before it reaches the customer.
| Record | What it does |
|---|---|
| SPF | Declares which mail servers may send email for your domain |
| DKIM | Digitally signs each email to prove it wasn't tampered with |
| DMARC | Tells providers what to do when SPF or DKIM checks fail |
It's a small job at launch and a painful mystery to debug later. A professional handles it as standard.
5. "How will the site plug into my existing tools?"
Your CRM, booking system, email platform, payments, analytics — map these during planning, because retrofitting connections after launch always costs more and works worse. Listen for questions back: a good developer will ask what's in your stack before quoting.
6. "What happens after launch?"
Websites decay. An update quietly kills a form; images pile up and slow the site; a page gets renamed and links break. Ask what maintenance is offered, what it covers, and — crucially — whether you'll receive a quarterly report of what was checked, fixed and flagged.
7. "Who owns everything?"
The domain, the hosting account, the code, the content, the analytics. The answer should be: you. Get it in writing. Businesses lose their own websites more often than you'd think, usually when a relationship with a provider ends badly.
The pattern to look for
Notice that none of these questions is really about design. Anyone can show you a pretty portfolio. These questions test whether a provider thinks about your website as a business asset — found in search, delivering email, connected to your tools, maintained over time. The ones who do will welcome the questions. The ones who don't will get vague. That's your answer.