How to Hire a WordPress Developer Without Getting Burned

Most people who hire a web developer do it once every three or four years, which means they never get good at it. The developer does this every week. That asymmetry is where bad outcomes come from.

I have been on both sides of this — as the freelancer being hired, and as the agency developer inheriting sites built by whoever came before. This is what I would want to know if I were in your chair.

First: work out what you’re actually buying

“I need a website” covers at least four different jobs with very different price tags.

• A template implementation. A good off-the-shelf theme, your content, your branding. Fast, cheap, perfectly adequate for a lot of businesses.
• A custom design and build. Designed for you, built from scratch, unique. Several times the price and worth it when your site is a primary sales channel.
• A repair or rescue job. Something exists and is broken, slow, insecure or unmaintainable. Scoping this is harder than building new.
• An application. Logins, dashboards, calculations, integrations, data. This is software development that happens to live on the web, and it is priced accordingly.

If you cannot tell which one you need, say so. A good developer will tell you — and quite often the honest answer is the cheaper one.

Questions worth asking

Skip “how many years have you been doing this”. Ask these instead.

“Can I see something you built that you did not design?”

Anyone can show you a beautiful site where they controlled everything. The real test is working inside someone else’s constraints — an existing brand, a legacy codebase, a client who changed their mind twice.

“What will I be able to edit myself, and what will need you?”

This is the question that prevents the most pain later. Some developers build sites where changing a phone number requires a developer. Get the boundary stated explicitly, in writing, before you start.

“What happens if you get hit by a bus?”

Phrased more politely, but ask it. You want to hear: code in a repository you have access to, a written handover document, standard technology choices, no proprietary lock-in. If the answer is vague, you are buying a dependency, not a website.

“Who owns the code and the accounts?”

The answer should be “you do, completely.” Your domain should be registered in your name. Your hosting account should be yours. Your code should transfer. Developers who hold domains hostage are not rare, and the leverage only becomes visible at the worst moment.

“How many plugins will this site need, and why each one?”

A developer who cannot answer this is going to solve every problem by installing something. Each plugin is a recurring cost, a security surface and a performance tax.

“Will it meet WCAG 2.1 AA?”

If you are a US business, this matters legally. A developer who does not know what WCAG 2.1 AA is should not be building a site for a US-facing business in 2026. Ask how they test it — the right answer involves keyboard navigation and a screen reader, not just an automated scanner.

“What does the handover include?”

Documentation, credentials, a walkthrough, a support window. Get it specified.

Red flags

• A quote without questions. Anyone who prices your project from a two-line email either does not understand it or is planning to charge you for the gap later.
• “Unlimited revisions.” This is either a lie or priced for the worst case, which means you are subsidising someone else’s indecisive client.
• Guaranteed #1 on Google. Nobody can promise this. Anyone who does is telling you how the rest of the relationship will go.
• No contract. Even a one-page scope with deliverables, timeline and payment terms protects both of you.
• Vague timelines. “A few weeks” is not a timeline. Milestones with dates are.
• Dismissive about maintenance. A developer who says the site will not need maintenance is either inexperienced or planning not to be around.
• Cannot explain things in plain English. If the technical explanation is incomprehensible now, it will be incomprehensible when something goes wrong and you need to understand a decision.

On price

The cheapest quote is almost never the cheapest outcome. I have spent a large share of my career fixing sites built cheaply, and the repair plus the original build routinely exceeds what a competent build would have cost in the first place.

That said, the most expensive quote is not automatically the best either. What you are looking for is a quote that demonstrates understanding — one that reflects back what you said, identifies something you had not thought of, and is specific about what is and is not included.

Fixed price works well for well-defined projects. Hourly works better for exploratory work, maintenance and anything where the scope will genuinely move. Be suspicious of fixed price on a vague scope — someone is going to lose on that deal, and there are only two candidates.

Working with developers in other countries

Since I am one, let me be direct about it rather than pretend the question does not come up.

The real risks of hiring offshore are time zones, communication and accountability — not skill. Skill is distributed evenly; opportunity is not.

What to check:

• Working hours. Will there be live overlap with your day, or are you on a 24-hour round-trip for every question? I deliberately run my day on US hours; plenty of others do not. Ask.
• Written English. You will communicate in writing far more than on calls. Judge it from their emails, not their portfolio.
• Payment protection. Platforms like Upwork provide escrow and a dispute process. For a first engagement with someone new, that is worth the platform fee.
• Verifiable track record. Public job history, reviews, a GitHub profile, references you can actually contact.
• Start small. Give a new developer a contained paid task before the big project. You learn more from one real week than from ten calls.

How to be a good client

This part is rarely written down, and it has an enormous effect on what you get.

• Have your content ready, or admit you do not. “Waiting on client content” is the number one cause of overrunning projects, by a distance.
• Consolidate feedback. One organised list beats fourteen separate messages over three days.
• Be specific. “Make it pop” is not actionable. “The heading feels too small next to the image” is.
• Decide who decides. If four people need to approve, agree who has the final word before the first review round.
• Pay on time. Obvious, frequently ignored, and the fastest way to be the client someone makes time for.
• Say what the business goal is. Not “I want a new site” but “our enquiry form gets three submissions a month and we need thirty.” That changes what gets built.

After launch

A website is not a purchase, it is an asset with ongoing costs. Budget for:

• Hosting — $25–50/month for anything that matters commercially.
• Updates and security — either your time or someone else’s, monthly.
• Backups, verified by someone actually restoring one.
• Small changes, which always come up.

Either put this on a care plan or deliberately decide to handle it in-house. What does not work is assuming it will take care of itself, which is how sites end up three years out of date and compromised.

---

If you are in the middle of hiring and want a second opinion on a quote or a scope you have been sent, send it over. I will tell you honestly whether it looks reasonable — including when the answer is “that is a good price, take it.”