Most people hire a WordPress developer badly, and it’s not because they ask too few questions. It’s because they ask the wrong ones. “How much?” and “how long?” get answered confidently by everybody, including the people who will disappoint you, so the answers separate nobody.
The questions that do separate candidates are the boring operational ones. Where does the work happen before it goes live? Who owns the licenses? What’s explicitly not included? Good developers answer these immediately because they’ve thought about them. Weak ones improvise, and you can hear it.
This is the list I’d use, including the questions that would rule me out for certain projects — a developer who can’t tell you what they’re bad at is guessing about the rest too.
Before you talk to anyone

Two things to sort out first, because they change every conversation that follows.
Write down what you need in plain language. Not a technical spec — a description. Roughly how many pages, which need unique layouts, what happens when someone fills in a form, what other systems it connects to, whether content and design are ready, and whether this is a new build, a rebuild, or a fix.
Set a real budget range. Small business WordPress sites run $1,500–$5,000, custom and WooCommerce builds $3,000–$12,000+, and redesigns of existing sites $2,000–$8,000. The WordPress website cost guide breaks down where those numbers come from.
Send every candidate the same written description and you get comparable quotes. Describe it differently to each of them and you get five prices for five different projects. Most confusing quote spreads are caused by this.
Questions about their process
“Walk me through how a project runs from the first call to launch.”
The single most useful question. Let them talk. You’re listening for defined stages: discovery, written scope, staging build, structured review rounds, QA, launch, handover. A developer who has run projects describes this without effort.
Weak answer: “You send me the content and I build it and then we launch.” That’s not a process, it’s an intention.
“Where does the work happen before it goes live?”
The answer is “on a staging site.” There is no other acceptable answer for anything beyond a text edit. Ask whether you’ll have access to the staging URL during the build — you should, and you shouldn’t have to ask twice.
“What’s your revision policy?”
Look for a defined number of rounds at a defined stage, with a clear line between a revision and a change of scope. “Unlimited revisions” is usually either heavily qualified in the contract or a project that never ends. Two rounds at template level is normal and works.
“How do you handle scope changes mid-project?”
Correct answer: we agree the change and the cost in writing before I build it. “Don’t worry, I’ll fit it in” means they’ll either resent you later or have padded the price. “I’ll bill it at the end” means an invoice you didn’t expect.
“What do you need from me, and when?”
A developer who’s been burned before answers precisely: content by this date, brand assets at kickoff, feedback within 48 hours in one consolidated list, approvals at these two points. “Just whatever you have” means they haven’t watched a project stall for three weeks waiting on copy — the most common cause of overruns, ahead of any technical factor.
“How do you communicate, and how fast do you reply?”
You want a stated norm — same business day, or within 24 hours — and a preferred channel. Ask directly whether you’re talking to the person building it or to someone who relays messages. Both answers can be fine. Not knowing which is not.
Questions about the technical approach
“Page builder or custom templates for my site, and why?”
The reasoning matters more than the answer. A good developer asks who edits the site and how often before answering. If a non-technical team publishes weekly and needs visual control, a page builder or well-designed Gutenberg blocks earns its performance cost. If content changes rarely and speed matters, custom templates win.
Red flag: a developer who only ever builds one way, regardless of your situation. That’s a preference sold as a recommendation.
“How do you decide when to install a plugin versus write code?”
You want to hear that plugins are treated as a cost rather than a free feature. Every plugin is code you’re trusting, a potential conflict, and a maintenance obligation forever. Well-maintained plugins for genuinely complex problems — custom fields, caching, forms, WooCommerce extensions — are sensible. Fifteen plugins for things a small function would handle is not.
Follow up: “Roughly how many plugins will my site end up with?” A number under 20, with reasoning, is a good sign.
“How will my team add a new page after launch?”
The question that predicts whether you’ll be happy in a year. If the answer is “you’d send it to me,” you’re buying a dependency. You want reusable components or patterns so your team can assemble a routine page without a developer.
“How do you handle performance?”
Listen for it being part of the build rather than an add-on: image sizing and formats, font loading, deferred scripts, minimal plugin footprint, caching configured, Core Web Vitals checked on real templates before launch. A developer who treats speed as a separate purchase after delivering a slow site is selling you the same work twice.
“What happens to my existing URLs?”
Only relevant for rebuilds and redesigns, and the highest-stakes question in that category. You want to hear about a URL map, 301 redirects for every changed URL, metadata carried across, internal links rebuilt, and a post-launch crawl. Botched migrations lose traffic that takes months to recover.
“How do you test before launch?”
Cross-browser, real mobile widths, actual form submissions to the real inbox, checkout flow if there’s a store, broken link scan, redirect verification, and a speed pass. “I check it looks right” is not QA.
“Is WordPress definitely the right choice here?”
A developer who says yes instantly to every project isn’t giving you an assessment. WordPress is a strong fit for content-driven business sites where non-technical people publish, and a weaker fit for app-like interfaces. Someone willing to say “this might belong on a different stack” is someone whose recommendations you can trust.
Questions about ownership and what happens after
“Who owns the code, the hosting, and the licenses?”
You do, all three. The hosting account should be in your name with your card, premium plugin licenses in your name, and the code yours outright, written to standard WordPress conventions so any competent developer can pick it up.
Red flags: hosting held in the developer’s reseller account, licenses in their agency bundle, or a proprietary framework you’d have to pay to leave. Vendor lock-in is a business model, not a service.
“What documentation do I get?”
At minimum: a written record of how the site is put together, credentials, and a walkthrough of how to edit content. A recorded video beats a document nobody reads. It’s the cheapest insurance against the developer becoming unavailable.
“What’s included after launch?”
Look for a defined bug-fix window — 30 days is standard — and a clear line between bugs (fixed free) and new features (a new small scope). Ask what happens on day 31. There should be an answer, and it shouldn’t be a mandatory retainer.
“Do you offer maintenance, and is it required?”
Optional is the right answer. Maintenance is genuinely valuable for lead-generating sites and stores — typically $75–$300/mo — but it should be a decision, not a condition. See WordPress maintenance for what a plan covers.
“What if I want to work with someone else next year?”
The correct response is essentially a shrug: everything’s documented, everything’s in your name, take it. Any hesitation here is worth taking seriously.
Questions about them
“Show me two sites like mine and tell me what you’d change.”
Portfolios show finished work. This asks for judgment. A developer who can look at their own past project and say “the mobile nav was a compromise” or “I’d structure the content differently now” has learned things. Someone who thinks everything they’ve built is perfect either hasn’t built much or isn’t paying attention.
Then check the sites yourself. Open two on your phone, run one through PageSpeed Insights. Four minutes, and it tells you more than any answer will.
“What kind of project are you not a good fit for?”
The best filtering question in the list. Mine: I’m a developer first, not a designer, so projects needing original brand and visual identity work go better with a designer hired separately. I take a limited number of projects at once, so immediate start dates aren’t always possible. And I don’t take multi-page custom builds under roughly $1,000, because I can’t do them properly at that price.
Anyone who claims to fit everything is either a large agency with actual specialists, or telling you what you want to hear.
“Who is actually doing the work?”
Ask plainly. Solo, subcontracted, or a team are all legitimate — being misled about which is not. If work is subcontracted, ask who reviews it and who you contact when something’s wrong.
“Can I speak to a past client?”
Most developers can arrange it. Ask the reference two things: how did they handle it when something went wrong, and did the final invoice match the quote. Those answers are worth more than a testimonial.
Red flags
Quotes a price before understanding the scope. A number in the first five minutes means either a template being resold or a figure that will change once real requirements surface.
No written scope document. The strongest single predictor of a project going badly. If nothing lists what’s included, everything is arguable later.
“Unlimited” anything. Either qualified out of existence in the fine print, or a promise nobody can keep.
Guaranteed rankings or a promised conversion percentage. Nobody can guarantee search rankings or predict a conversion lift for your specific site. A guarantee here means either ignorance or a script.
Won’t discuss what happens after launch. People who plan to disappear are vague about the future.
Wants the full fee up front. 50/50 is standard and milestone splits are fine on larger projects. 100% up front is you carrying all the risk.
Nulled plugins. If a proposal includes premium plugins “provided free,” ask whether the license is yours. Pirated plugins don’t get security updates and sometimes ship injected code.
Can’t explain a technical decision in plain English. Deliberate jargon usually covers uncertainty or a decision that doesn’t survive scrutiny.
Dismisses your questions. If asking about staging gets a condescending answer during the sales conversation, consider how it’ll go when you’re reporting a bug.
Wildly cheap compared to everyone else. If four quotes cluster near $4,000 and one is $900, the cheap one is solving a different problem. Ask what’s excluded. Usually it’s most of the work.
What good process looks like
For reference, here’s the shape of a healthy engagement — roughly the one I run.
- Short discovery call. You describe the problem; they ask what you’re trying to accomplish, who edits the site, and what the deadline is. If it isn’t a fit, they say so on that call.
- Written scope and fixed quote. What’s included, what’s excluded, the price, the timeline, and what they need from you and when.
- Deposit and kickoff. Typically 50%, with access collected: hosting, registrar, admin, brand assets, content.
- Staging build with visibility. You have the link. Updates at meaningful milestones rather than daily noise.
- Structured review rounds. Two rounds, batched feedback, template-level approval rather than page by page.
- QA. Cross-browser, real mobile widths, form submissions, checkout, broken links, redirects, performance pass.
- Launch at a low-traffic window. DNS, SSL, caching, sitemap submitted, redirects verified in a single hop, analytics confirmed firing.
- Handover and a bug-fix window. Documentation, a walkthrough video, and 30 days of fixes at no charge.
If a proposal contains most of that, you’re probably in good hands. If it contains none of it, the price is not the thing to negotiate.
Frequently asked questions
Should I hire a freelancer or an agency?
A freelancer gives you direct contact with the person writing the code and no coordination overhead, which suits most small business sites. An agency gives you designers, project management, and QA staff, which matters when you need original brand work or several stakeholders coordinated. Expect agencies to run roughly three to five times the freelance price for equivalent build scope.
How much should I expect to pay?
Small business WordPress sites are typically $1,500–$5,000, custom or WooCommerce builds $3,000–$12,000+, and redesigns $2,000–$8,000. Hourly rates vary enormously by region, and rate alone tells you little — someone at $120/hour who finishes in 30 hours is cheaper than someone at $40/hour who takes 140.
Does location matter?
Less than time zone overlap and communication quality. Plenty of excellent developers work outside the US and Western Europe at lower rates. What matters is whether you get a response the same working day and whether the process is solid. Judge those directly rather than using location as a proxy.
How do I check a portfolio properly?
Open the sites on your phone, not your desktop. Run one through PageSpeed Insights. Check the mobile navigation, image sizing, and whether the contact form actually submits. Then ask which parts of the project they personally did — plenty of portfolio pieces are team efforts or configured themes.
What should the contract include?
Scope with explicit exclusions, price and payment schedule, timeline with dependencies, revision policy, IP ownership transferring to you on final payment, who holds hosting and licenses, the post-launch support window, and what happens if either side walks away. It doesn’t need to be long. It needs to exist.
Is it a bad sign if a developer turns down my project?
The opposite. Someone who declines work that isn’t a fit — wrong budget, wrong specialty, no capacity — would rather lose a project than deliver a bad one. That’s the same judgment you want applied to yours if they take it.
What if I already have a site and just need it fixed?
Say so explicitly, because it’s a different engagement. Rescue and cleanup work is usually scoped small rather than as a full build. If the problem is speed, that’s a targeted WordPress speed optimization job at $250–$1,500. If the structure is the problem, it’s a website redesign. Getting the category right saves you from being quoted for a rebuild you don’t need.
Book a free 15-minute project call
If you’re vetting developers, ask me these questions — all of them, including the ones designed to disqualify people. I’d rather tell you on the first call that your project belongs with someone else than take it and disappoint you.
You’ll get a straight read on scope, a realistic budget range, and an honest answer about fit. Details of how I work are on the WordPress development services page.
Book a free 15-minute project call — no pitch deck, no pressure.