Hiring a web developer is a trust exercise. You’re paying someone to build something you probably don’t fully understand, using technology you can’t evaluate, with terms you might not have negotiated properly.
And if it goes wrong, you’re stuck with a broken website, wasted money, and possibly no access to your own domain.
The good news: asking the right questions upfront reveals almost everything you need to know about whether this person is competent and trustworthy.
The Ownership Questions (Most Important)
These questions determine whether you’re buying a website or renting access to one.
1. “Who will own the domain name?”
Why this matters: Your domain (yourbusiness.co.uk) is your online identity. If the developer owns it, they can hold it hostage.
Good answer: “You’ll own it. I’ll help you register it in your name, or you can register it yourself and give me access to point it to your new site.”
Red flag answer:
- “I’ll register it for you” (doesn’t confirm ownership)
- “It’s easier if I handle the domain” (translation: easier to control you)
- “We include domain registration in the package” (but who owns it?)
Follow-up question: “Can you show me where I’ll access the domain control panel, and will the account be in my business name with my email?“
2. “Who will own the hosting account?”
Why this matters: Hosting is where your website files live. If you don’t control the hosting, you don’t control your site.
Good answer: “You’ll have the hosting account in your name. I’ll help you set it up, or I can set it up initially and transfer ownership to you before launch.”
Red flag answer:
- “I provide hosting as part of the service” (you’re renting, not owning)
- “You don’t need to worry about hosting, I’ll manage it” (you should worry)
- “The website is on my server” (it’s not your website then)
Follow-up question: “What hosting company will we use, and will I be able to log in and see the account details?”
3. “Will I own the source code and all files?”
Why this matters: The code is what makes your website work. You should own it outright.
Good answer: “Yes, you’ll own everything. At the end of the project, you’ll get all source files, and the code will be in a repository you control.”
Red flag answer:
- “The code is proprietary” (it’s your website, you paid for it)
- “You’ll have access to the site, but not the source code” (you don’t really own it)
- “You get the files, but they won’t work without my platform” (vendor lock-in)
Follow-up question: “If we part ways, can I hire another developer to maintain and update the site using the code you’ve written?”
The Process Questions
These reveal how the developer works and whether they’ll actually finish.
4. “What’s your development process?”
Why this matters: A clear process suggests experience. Vague handwaving suggests they’re making it up as they go.
Good answer: Something structured like:
- “Discovery and planning phase (1 week)”
- “Design mockups for approval (1-2 weeks)”
- “Development and build (2-3 weeks)”
- “Review, revisions, and testing (1 week)”
- “Launch and handover”
Red flag answer:
- “I just start building and we’ll figure it out” (no plan = missed deadlines)
- “It depends” without any structure (they don’t know)
- Overly complicated processes with endless phases (justifying high cost)
Follow-up question: “At what point will I see something I can review, and how many revision rounds are included?“
5. “How will we communicate, and how quickly will you respond?”
Why this matters: Ghost developers are common. Set expectations now.
Good answer: “I respond to emails within 24 hours on weekdays. For urgent issues during the project, you can text me. After launch, I monitor support tickets and respond within 48 hours.”
Red flag answer:
- “I’ll get back to you when I can” (you’ll be chasing them)
- Gives only one contact method with no backup (what if they ignore it?)
- No mention of response times (because they won’t commit)
Follow-up question: “If I don’t hear back within your stated timeframe, what should I do?“
6. “What happens if the project takes longer than expected?”
Why this matters: Projects run late. Who pays for delays?
Good answer: “If delays are on my end, you don’t pay extra. If you need significant changes to the original scope, we’ll discuss timeline and cost adjustments.”
Red flag answer:
- “Any delays mean additional charges” (even their delays?)
- “Projects take as long as they take” (no accountability)
- No clear answer (they haven’t thought about it)
Follow-up question: “What’s considered a scope change versus part of the original agreement?”
The Technical Questions
You don’t need to understand the answers fully, but you should hear confidence and clarity.
7. “What platform or technology will you use, and why?”
Why this matters: The technology choice affects long-term maintenance, costs, and whether you’re locked in.
Good answer: “I recommend WordPress because it’s widely supported, easy for you to update, and any developer can work on it if needed. Alternatively, [Astro/Next.js/etc.] because [specific reasons relevant to your needs].”
Red flag answer:
- “I use my own proprietary system” (lock-in)
- “I build everything custom from scratch” (unnecessarily expensive)
- Names a platform that’s obscure or dying
- Can’t explain why they chose it
Follow-up question: “If I need updates in two years, will I be able to find other developers who can work with this platform?“
8. “How will the site perform on mobile devices?”
Why this matters: More than half of web traffic is mobile. If your site doesn’t work on phones, you’re losing customers.
Good answer: “The site will be fully responsive, tested on iPhone and Android devices. I design mobile-first, so it will work perfectly on all screen sizes.”
Red flag answer:
- “It should work on mobile” (should?)
- “Mobile optimization costs extra” (it’s standard in 2026)
- Doesn’t mention testing
Follow-up question: “Can you show me examples of sites you’ve built and how they look on mobile?“
9. “How will you handle SEO?”
Why this matters: A website that doesn’t show up in Google is a waste of money.
Good answer: “I’ll implement basic technical SEO: proper page titles, meta descriptions, image optimization, fast loading, mobile-friendly, XML sitemap. You’ll need to handle content SEO and ongoing optimization, or I can do that as an additional service.”
Red flag answer:
- “I guarantee first-page Google rankings” (no one can guarantee that)
- “SEO is a separate service that costs £X,000 more” (basic SEO should be included)
- “SEO isn’t part of web development” (wrong, technical SEO is foundational)
Follow-up question: “Will I be able to edit page titles and descriptions myself, or do I need to hire you for every change?”
The Money Questions
Get crystal clear on costs before signing anything.
10. “What exactly is included in the quoted price?”
Why this matters: Hidden costs are how a £3,000 quote becomes a £7,000 invoice.
Good answer: A detailed breakdown:
- Design and development
- X pages
- Contact form
- Basic SEO setup
- Mobile responsive
- Y revision rounds
- Training on how to update content
- 30 days of post-launch support
Red flag answer:
- “A website” (too vague)
- “Everything you need” (what does that mean?)
- Long list of technical jargon without explaining what it means
Follow-up question: “What’s specifically not included that I might need later?“
11. “What’s your payment structure?”
Why this matters: Protects both of you. Never pay 100% upfront.
Good answer: Something like:
- 30% deposit to start
- 40% when you approve the design
- 30% on completion and handover
Red flag answer:
- “Payment in full before I start” (huge risk)
- “We’ll figure it out as we go” (no structure)
- “Monthly retainer forever” (for a basic site?)
Follow-up question: “What happens if I’m not happy with the work at each milestone? Can I pause or cancel?”
12. “Are there ongoing costs after launch?”
Why this matters: Domain, hosting, maintenance, updates. These add up.
Good answer: “You’ll pay for domain registration (£10-15/year) and hosting (£10-50/month depending on your choice). If you want me to maintain and update the site, that’s £X/month, but you can also do it yourself or hire anyone else.”
Red flag answer:
- Doesn’t mention ongoing costs (they exist, you need to know)
- Requires monthly payments to them or the site stops working (hostage situation)
- Vague about what ongoing costs cover
Follow-up question: “If I want to cancel hosting or maintenance with you, can I easily move to another provider or developer?”
The Support Questions
What happens after launch matters as much as the build.
13. “What training and documentation will you provide?”
Why this matters: A site you can’t update yourself costs you money every time you need a change.
Good answer: “I’ll provide a training session showing you how to update content, add pages, and manage basic settings. You’ll also get written documentation and video recordings you can refer back to.”
Red flag answer:
- “You’ll need to contact me for all updates” (dependency)
- “It’s intuitive, you’ll figure it out” (it won’t be and you won’t)
- No training offered
Follow-up question: “After training, what’s the typical thing clients struggle with, and how do you support them?“
14. “What support do you offer after launch?”
Why this matters: Bugs happen. Things break. You need to know who fixes it.
Good answer: “30 days of included support for any bugs or issues. After that, you can purchase ongoing maintenance, hire me hourly, or manage it yourself.”
Red flag answer:
- “All support costs extra from day one” (even fixing their mistakes?)
- “Unlimited lifetime support” (sounds good but likely meaningless)
- No clear support terms
Follow-up question: “If the site breaks due to something you built incorrectly, is that covered as a bug fix or do I pay extra?”
The Warning Sign Questions
These questions reveal character and reliability.
15. “Can you provide references from recent clients?”
Why this matters: Past behavior predicts future behavior.
Good answer: “Yes, here are three clients from the past 6 months. I’ll send you their contact information with their permission.”
Red flag answer:
- “All my clients are confidential” (convenient excuse)
- Provides references but won’t let you contact them directly
- References are all from years ago
- Refuses outright
Follow-up question: “Can I see examples of live sites you’ve built for similar businesses?“
16. “What happens if you get hit by a bus tomorrow?”
Why this matters: Solo developers disappear. Have a backup plan.
Good answer: “All your code is in a repository you control. Your domain and hosting are in your name. Any competent developer could take over. Here’s my business continuity plan / partner who can step in.”
Red flag answer:
- Laughs it off without a real answer
- “That won’t happen” (but what if it does?)
- “My proprietary system means only I can work on it” (bad sign)
Follow-up question: “If you’re unavailable for a month, how do I make urgent changes?”
Red Flag Answers to Watch For
If you hear any of these, proceed with extreme caution or walk away:
“Trust me” or “Don’t worry about it” - You should worry. Good developers explain things clearly.
“That’s not how it works” - Maybe, but they should explain how it does work.
“You don’t need to understand the technical details” - You don’t need to be an expert, but you deserve clear answers.
“I’m really busy, so I need payment upfront” - Busy professionals still follow standard business practices.
“My way or no deal” - Inflexible developers cause problems during the project.
“Everyone else does it this way” - If they’re doing something sketchy, this is the justification they’ll use.
Green Flag Answers to Look For
These responses suggest you’re talking to someone professional:
Clear, jargon-free explanations - They can translate technical concepts into plain English.
Written proposals and contracts - Everything documented, nothing verbal-only.
Questions about your business - They want to understand your goals, not just build a site.
Honest about limitations - “I don’t typically do that, but I can recommend someone who does.”
Proactive about ownership - They bring up domain/hosting ownership before you ask.
Portfolio of similar work - They’ve built sites for businesses like yours.
The Contract Checklist
Before you sign or pay anything, the contract should clearly specify:
- Exactly what’s being delivered (pages, features, functionality)
- Timeline with milestones
- Payment schedule tied to milestones
- Who owns what (domain, hosting, code, content, designs)
- Revision policy (how many rounds, what counts as a revision)
- Support terms (duration, what’s covered)
- Cancellation terms (for both parties)
- What happens if deadlines are missed
- Dispute resolution process
If there’s no written contract, don’t proceed. A contract protects both of you.
The Bottom Line
Hiring a web developer doesn’t have to be a gamble. Ask these questions, listen carefully to the answers, and trust your instincts.
Good developers welcome these questions. They understand you’re protecting your business and they respect that.
Dodgy developers get defensive, vague, or pushy. That’s your signal to walk away.
The difference between a good hire and a disaster often comes down to asking the right questions before you commit. If you’re looking for a developer who guarantees ownership and access, check out our business website service where transparency is built into the process.
