How to Hire a WordPress Developer: Rates and Red Flags

Search for how to hire a WordPress developer and you get agency landing pages. They explain their process, show three logos, and put the price behind a contact form. That is a sales page, not an answer, and it leaves you comparing quotes with no idea what a fair one looks like.

So here are the published rate ranges with the source named against each one, the four different jobs the phrase “WordPress developer” covers, a brief template that gets you accurate quotes instead of vague ones, ten vetting questions with the answer you want and the answer that should end the call, and the checks you can run on delivered work without knowing PHP.

One disclosure so you can read the rest without wondering: WPColt sells no development services and takes no referral fees from anyone named here. If your project is a shop, the pricing and vetting logic shifts enough that it needs its own treatment, and that is covered in the guide to hiring a WooCommerce developer. This post stays on general WordPress work.

What does it cost to hire a WordPress developer?

Published hourly rates range from roughly $15 at the bottom of the open marketplaces to about $150 at a small specialist agency, and the route you pick moves the number more than the developer’s skill does. Upwork publishes a typical band of $15 to $28 an hour for WordPress developers with a $20 median, and notes rates run from $15 to $40 and above. Codeable publishes $80 to $120 an hour, plus a fixed 17.5% service fee on top of the estimate. Arc’s freelance rate page puts the average and median for WordPress developers at $61 to $80 an hour.

Route	Hourly range and source	What you actually get	Best fit	Main risk
Open marketplace (Upwork and similar)	$15-$28 typical, $20 median, up to $40+ (Upwork’s published cost page)	A very wide talent spread. Rate says little about ability at this band.	Small, well-specified tasks where you can check the result yourself	You are doing the vetting, and most of the low band is implementer work sold as development
Vetted marketplace (Codeable)	$80-$120 plus a 17.5% service fee (Codeable’s published pricing page)	Pre-screened developers, platform-managed scope and payment, dispute cover	One-off custom work when you have no way to vet a stranger	You pay the fee on every project, and the platform owns the relationship
Independent freelancer, direct	$61-$80 average and median (Arc’s published WordPress rate page)	One person who learns your site and stays reachable	Ongoing work with an established site	Single point of failure: illness, holidays, and a bus factor of one
Boutique agency (3-15 people)	No public rate card. Worked example below lands near $120-$150	A team with a project manager, cover when someone is away, real process	Multi-month builds, integrations, anything with a deadline that matters	Overhead you pay for whether you use it or not
Offshore agency	Sits mostly in the $15-$40 band Upwork publishes	Volume capacity, structured teams, low unit cost	Well-documented, repetitive build work with a clear spec	Timezone and spec drift. Ambiguity in the brief gets resolved without you
Retained maintenance	Usually a monthly plan. See the retainer arithmetic below	Updates, backups, monitoring, a few hours of small fixes	Any live site with customisations you cannot afford to break	Plans that only run updates and call it maintenance

The agency row deserves its working shown, because agencies rarely publish one. The US Bureau of Labor Statistics puts the May 2025 median pay for web developers at $92,650 a year. Over a 2,080 hour year that is about $44.50 an hour in salary alone. Agencies typically bill somewhere between two and a half and three times salary cost to cover payroll tax, benefits, management, sales and the hours nobody bills. That worked example gives roughly $111 to $134 an hour. A small agency quoting $130 is not gouging you. It is doing arithmetic.

Regional variation is real and it is large. The same competence bills differently in Manchester, Warsaw, Manila and San Francisco, and a $30 an hour developer in one market can be more experienced than a $110 an hour one in another. What regional variation does not explain is a quote that undercuts every other quote by 70%. At that point you are almost always being sold an implementer as a developer, and the gap shows up later as work that has to be redone.

For retainers, do the same arithmetic rather than shopping on headline price. Two to four hours a month of a freelancer’s time at the Arc band is roughly $120 to $320 a month before the cost of monitoring and backup tooling. A plan priced well under that is running automated updates on a schedule and nothing else, which is a cron job, not maintenance.

“WordPress developer” is four different jobs

The phrase covers four distinct skill sets, and hiring the wrong one is the most expensive mistake in this entire process. Everyone in all four categories will answer an ad for a WordPress developer, because the title is technically accurate for all of them.

The implementer

Assembles sites from a commercial theme, a page builder and plugins, and writes little or no PHP. This is a real craft: choosing plugins that will still be maintained in three years, keeping the stack small, building layouts that a non-technical person can edit afterwards. For a very large share of small-business work, the implementer is the correct hire and the cheapest one. They can build a brochure site, a blog, a booking flow, a membership area. They cannot debug a fatal error in a plugin, write a REST endpoint, or fix a query that takes four seconds.

The front-end developer

Writes templates, CSS and JavaScript, builds or extends block editor blocks, and knows what an accessible form actually requires. They work in a child theme or a custom block theme rather than editing a purchased parent, and they know how to override parent theme functions without touching the parent’s files. They can rebuild a design pixel-accurately and make it fast. They usually cannot design your database schema or write a payment integration.

The back-end or plugin developer

Writes real PHP against WordPress APIs: hooks and filters, custom post types and taxonomies, the database layer, the REST API, cron, third-party integrations. This is who you need when the requirement is behaviour rather than appearance. They cost the most per hour and they are wasted on assembling a theme, which they will do slowly and resentfully.

The platform or DevOps person

Owns hosting, PHP versions, deployment pipelines, staging environments, migrations, backups and performance at the server layer. They fix the site that is slow for reasons no plugin can address. They are not the person to build your new landing page templates.

Job	Can do	Cannot do	Hire when
Implementer	Theme and plugin assembly, page builder layouts, content structure, basic SEO setup	Custom PHP, debugging fatal errors, performance work below the plugin layer	You need a site built from existing parts, which is most small-business work
Front-end developer	Custom templates, CSS, block editor work, accessibility, child themes	Database design, integrations, server work	A design must be built exactly, or your editor experience is a mess
Back-end developer	Custom plugins, hooks, post types, REST endpoints, third-party APIs	Design decisions, and they will hate doing layout	The requirement is a behaviour WordPress does not have
Platform / DevOps	Hosting, CI and deployment, migrations, caching layers, server performance	Feature work in your theme	The site is slow, fragile, or moving hosts

A $110 an hour back-end developer assembling a theme is more expensive than a $45 an hour implementer doing it well, and the result is worse.

How to write a brief that gets accurate quotes

An accurate quote requires seven things, and most briefs contain two of them. Everything a developer does not know, they price as risk, which is why a vague brief produces either a padded number or a low number that gets revised upward halfway through. This section saves you more money than any other on this page.

• Current stack and hosting. Host name and plan, PHP version, theme name and whether it is a child theme, page builder if any, plugin count, whether staging exists.
• What already exists. A live URL beats any description. Say what was built by whom and when, and what is already custom.
• The business outcome, not your guess at the implementation. “Customers cannot book a second appointment without re-entering everything” is useful. “I need a custom plugin with a wizard” is you doing the developer’s job badly.
• What must not break. Name the forms, the checkout, the integrations, the tracking, the URLs that have rankings. This is where surprise costs live.
• Who supplies content. The single most common cause of a stalled project. Say who writes copy, who supplies images, and when.
• The deadline and the reason for it. A date attached to a trade show is a real constraint. A date attached to nothing gets treated as one, correctly.
• Your budget band. Yes, actually state it.

Withholding the budget feels like protecting your negotiating position. It does the opposite. A developer who does not know the band has to guess which project you are asking for, because “a booking system” can honestly be built for $1,500 or $30,000 and both are the right answer to different questions. Good ones respond to a missing budget by quoting the safe, expensive version or by declining to quote at all. State a band and you get a proposal shaped to it, plus an honest answer about what does not fit inside it.

SITE: example.com (live)
HOST / PLAN: SiteGround GrowBig, PHP 8.2, no staging currently
STACK: Astra child theme, Elementor, 24 active plugins, WP 6.8
BUILT BY: an agency in 2022, no contact since

WHAT WE WANT (outcome, not implementation):
Returning customers can book a repeat appointment in under
60 seconds without re-entering their details.

MUST NOT BREAK:
- Contact form and its Zapier hook
- /services/ URLs (they rank)
- GA4 and Meta pixel events

CONTENT: we supply all copy and images by 14 Sept. No new photography.

DEADLINE: 20 Oct, ahead of our autumn campaign. Hard date.

BUDGET BAND: 4,000 - 6,000 GBP. Tell us if that is unrealistic
and what it would buy instead.

WHAT WE NEED FROM YOU:
Fixed-price milestones, who does the work, and whether the code
lands in a repo we own.

Pay for a small trial task before you sign anything

A paid trial task is the highest-signal step in the whole process, and it costs a few hundred dollars against a project worth thousands. An interview tells you how someone talks about work. A trial task tells you how they do it.

A good trial task is small, real, self-contained and useful whether or not you hire them. Fix a specific bug. Build one custom block. Add a filtered archive template. Migrate one section. Three to five hours of work, paid at their full rate, delivered on a staging copy with a commit history you can look at.

What you learn from it that no conversation reveals: whether they ask clarifying questions before starting or guess; whether they put the change in a child theme or a small plugin rather than editing something that will be overwritten; whether commits are readable increments or one blob called “updates”; whether they set up staging without being asked; how they behave when the task turns out to be slightly different from the description, which it always does; and whether the estimate they gave for five hours of work bore any relationship to reality.

Ten vetting questions, the answer you want, and the red-flag answer

These ten questions separate a maintainable build from one you will pay to rebuild, and you do not need to write code to score the answers. You are listening for whether the developer keeps custom work outside anything that gets updated, and whether they can tell you how they know something works.

Ask	Answer you want	Red-flag answer
Do you ever edit WordPress core or the parent theme directly?	Never. Core stays untouched; customisation goes in a child theme or a site-specific plugin	“Only small changes, we keep notes.” Those changes vanish on the next update
How do you add functionality without touching the theme?	Hooks and filters in a small custom plugin, so behaviour survives a theme change	“I add it to functions.php” with no mention of which theme’s functions.php
How do you handle updates on a site with customisations?	Update on staging, run a smoke test of critical flows, then push live. Customisations live outside updatable code	“We turn updates off,” or updates applied straight to live
What do you do with WP_DEBUG and Query Monitor?	WP_DEBUG on locally and on staging, logging to file with display off, targeting zero notices. Query Monitor to inspect queries, hooks and slow calls	Has not used either, or claims debugging “slows the site down” as a reason never to enable it
Do you use version control, and where does the repo live?	Git, in a repository owned by your organisation, with you added from day one	No repo. Zip files by email. Or a private repo on their personal account “for now”
How do you test before deploying?	A staging clone, a written checklist of critical user flows, a deployment method that can be rolled back	“I test on live at night” or FTP uploads with no rollback
Walk me through diagnosing a plugin conflict	Reproduce on staging, deactivate everything, reactivate one at a time (or use Site Health’s troubleshooting mode), isolate, then fix or report upstream	“Reinstall WordPress,” or deleting the plugin and swapping in a different one as the first move
How do you handle data coming in from a form and data going back out to a page?	Sanitise and validate on input, escape on output, nonces and capability checks on anything that writes	“WordPress handles that automatically.” It does not, in custom code
A site has got slower. What do you check first?	Measure before changing anything: server response time versus render time, query count, whether the cache is being hit, what changed recently	“Install a caching plugin,” offered as both the first step and the whole answer
If we stop working together, what happens to the code?	It is yours. Repo, documentation and deployment access hand over, and IP assigns on final payment	“My framework stays with me,” licence-locked code, or anything obfuscated

Two of these have published references you can hold work against. The WordPress PHP coding standards define what conventional WordPress PHP looks like, and the plugin handbook’s security section sets out sanitising, escaping, nonces and capability checks as the baseline rather than an optional extra. A developer who has not read either is not disqualified, but a developer who argues with either is.

Code-quality checks a non-developer can actually run

Six checks on a staging copy will tell you most of what you need to know about delivered work, and none of them require reading PHP. Run them on staging, never on the live site, and run them before the final payment clears rather than after.

1. Is there a child theme or a custom plugin? Look in Appearance and in Plugins. Custom work should live in something named for your site, not inside a purchased theme’s folder and never inside core files.
2. Does the site throw notices with debugging on? Turn WP_DEBUG on in the staging copy’s wp-config.php, browse the pages that were built, then read the log. A handful of notices from third-party plugins is normal. Pages of warnings from the new code is not.
3. Is there a repository with real commits? Open it. You are looking for many small commits with messages that describe changes, not three commits called “update” made on the last day.
4. Does Query Monitor show a sane query count? Install it on staging and load a normal page. A typical WordPress page runs tens of queries. Several hundred on a simple template means something is querying inside a loop.
5. Are there hard-coded credentials or API keys in theme files? Keys belong in wp-config.php or environment variables, not in a template that ends up in a repository or a theme export.
6. Is anything loading from an unfamiliar external domain? Open the browser’s network tab on a delivered page and read the list of hostnames. You should recognise every one, or be able to get a straight answer about it.

# On the STAGING copy only, in wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

# Then browse the site and read the log:
tail -n 200 wp-content/debug.log

# Look for credentials committed into the theme:
grep -rIn "api_key\|secret\|password\|Bearer " wp-content/themes/your-child-theme/

# Sanity-check the commit history:
git log --oneline | head -30

Access, accounts and what goes in the contract

Every account and licence involved in your site should be registered to you, with the developer added as a revocable user, and this is the part small businesses get wrong most often. It is not about distrust. It is about what happens when the engagement ends, amicably or otherwise, and you discover the domain renewal notice goes to someone else’s inbox.

Access hygiene

• Domain, hosting, DNS and every plugin licence bought on your accounts with your billing details. Reimburse the developer for licences rather than letting them buy on their own account.
• One admin account per human being, named. Never a shared “admin” login, because a shared login means the audit log tells you nothing about who did what.
• A separate account for the developer that you can delete in ten seconds on the last day. Same for hosting, repository and any third-party service.
• Development and testing on staging, not on live. If the host has no staging, that is a reason to change host, not a reason to work on live.
• No shared password documents, no credentials in email or chat. Use a password manager with per-user access, and enforce decent credentials with a password policy on the WordPress side. The wider account hardening checklist is in the ten steps to secure a WordPress website.

Contract and handover checklist

• IP assignment on final payment. Written, unambiguous, covering custom code and design files. Third-party GPL and commercial components stay under their own licences, which is fine and normal.
• Repository and deployment access. Named as a deliverable, not a favour, and transferred before the final invoice is paid.
• Documentation of custom code. A README covering what was built, which hooks it uses, what breaks if a given plugin is removed, and how to deploy. One page is enough. Zero pages is not.
• A defined warranty window. Thirty to ninety days in which bugs in delivered work are fixed free. Define a bug as delivered work not doing what the spec said, so it does not become a channel for new requests.
• Milestone payments. Typically a deposit, one or more middle milestones tied to demonstrable output, and a final payment on acceptance. Never the whole amount up front.
• A written definition of done. The specific things that must be true for the project to be complete, agreed before work starts. Without it, “done” is whoever gets tired first.

Red flags that should end the conversation

Some signals are worth pausing over and some are worth walking away from immediately, and the difference is whether the behaviour is a habit or a business model.

Red flag	What it usually means	Do this instead
A firm quote arrives within an hour, with no questions asked	They have not read the brief, or they intend to revise the number later	Treat a few sharp clarifying questions as the strongest positive signal there is
Staging is never mentioned	They work on live. Your outage is a matter of time	Ask directly where the work will be done before you ask anything else
They ask for your hosting or admin password by email or chat	No process, and no habit of thinking about credentials	Create them a named account with the access the job needs
“We build on our own proprietary framework”	Portability is being removed on purpose	Require standard WordPress APIs and an exit path in writing
Repository access is refused or deferred until the end	The code is not in a state they want you to see	Repo access from day one, in your organisation
The quote is 70% below every other quote	An implementer is being sold to you as a developer	Ask which of the four roles they actually are, and price the honest answer
Premium plugins offered “free” or via an unlimited licence they hold	Nulled software or licence abuse, and no update path for you	Buy licences yourself, on your account
No warranty window offered, or full payment demanded up front	They expect to be gone before the bugs surface	Milestones, and a written warranty period
Everything happens in chat with no written scope	Scope disputes later will be unresolvable	A one-page written scope and definition of done, even for small jobs
They cannot name a single thing that could go wrong	Inexperience, or a sales script	Ask what usually goes wrong on projects like yours and listen for specifics

Before you sign off, confirm the caching is real

Verify that the caching your developer configured is actually serving cached responses, rather than accepting that a plugin is installed and its settings page looks green. Configured and working are different states, and the gap between them is where most disappointing launch-day performance lives.

Two things to establish at handover. First, that pages are being served from cache for logged-out visitors, which you can check with the free Cache Inspector in the WPColt toolbox: it reports on page cache, server cache and CDN layers rather than trusting a plugin’s own dashboard. Second, that nothing the developer installed duplicates a layer your host already runs. Managed hosts frequently run a server-level cache, and stacking a page-caching plugin on top of it produces stale pages and confusing invalidation, which is the failure mode described in the notes on running Varnish alongside WP Rocket.

Verdict: what to hire, by project and budget

Match the role to the work and the route to the budget, in that order, because getting the role wrong cannot be fixed by paying more.

Brochure site, blog or small business site, under $3,000. Hire an implementer, direct, at the lower freelance band. You do not need custom PHP and paying for it is money set on fire. Insist on a child theme, a plugin count you can justify, and a handover document.

A specific feature WordPress does not have, $1,500 to $8,000. Hire a back-end developer, and use a vetted marketplace if you have no way to judge one yourself. Codeable’s fee is a real cost, and it is cheaper than commissioning a custom plugin from the wrong person. Run the paid trial task first regardless of route.

A design that must be built exactly, with a real editing experience behind it. Hire a front-end developer. Ask to see a site they built where a non-technical client edits the pages, and ask that client how it went.

The site is slow, fragile, or moving hosts. Hire the platform person, not a general developer. This is the one case where the cheapest useful engagement is often a few paid hours of diagnosis before any work is commissioned.

A multi-month build with a deadline that costs you money if it slips. Hire a boutique agency and accept the $120 to $150 an hour band. You are buying cover for illness, a project manager, and someone accountable when a milestone moves. A single freelancer at half the rate is genuinely cheaper right up to the week they are unreachable.

Budget under $500 and a live site with problems. Do not hire a developer yet. Spend the money on a paid diagnostic hour and a written list of what is wrong, then decide. Commissioning fixes for a problem nobody has diagnosed is how a $500 budget becomes a $5,000 one.

Frequently asked questions