Hire WordPress Developers: Rates, Vetting and Common Traps

What a WordPress developer actually does, and where the hire goes wrong

The job title covers two completely different people. One assembles sites in Elementor or Divi, wires up a contact form, and installs plugins. The other writes PHP against the hooks system, registers custom post types and taxonomies, builds blocks with block.json and the @wordpress/scripts toolchain, tunes WP_Query and the meta_query calls behind a slow archive, and knows why esc_html on output matters more than sanitizing on input. Both call themselves WordPress developers. Only one of them can build you software.

The failure pattern is boringly consistent. A founder posts "add a booking feature to our WordPress site" and hires at $18 an hour. Six weeks later the site works, sort of. There are fourteen new plugins. The booking logic lives in a 900 line functions.php inside the parent theme, so the next theme update erases it. The developer needed a different confirmation email, so they edited the booking plugin's own PHP file directly, and an auto update quietly reverted it in month two. There is no git repository, because the work was done through the Appearance to Theme File Editor screen on the live site. Install Query Monitor and the booking archive fires over 400 queries, most of them unindexed lookups against wp_postmeta. The wp_options table has three megabytes of autoloaded rows because two plugins were installed, tested and deleted without cleanup, so every single page load drags that with it.

Nothing here is exotic. It is what happens when you hire a site assembler for an engineering problem, and the rebuild costs more than doing it right would have.

Engagement models: in-house, freelancer, agency, staff augmentation

In-house hire. Right when WordPress is your product surface, not your brochure. If you run a WooCommerce store doing real volume, a membership platform, or a publisher with a custom editorial workflow, you want someone who holds the whole plugin and theme layer in their head and is there when checkout breaks on a Friday. The trade off is that a single WordPress engineer is a lonely role. There is nobody to review their PHP, so their habits become your codebase, and mediocre habits compound in WordPress faster than almost anywhere else.

Freelancer. Right for bounded, describable work. Fix a plugin conflict. Build one Gutenberg block. Migrate to a new host. Convert a classic theme header to a block template part. Freelancers are the fastest and cheapest path to a defined outcome. The trade off is continuity and review. Nobody checks their nonce handling, nobody documents the decision, and when they go quiet you own a codebase you cannot read.

Agency. Right when you want the outcome and not the management. Good agencies bring a project manager, a staging environment, a deploy process and a QA pass. You pay for that. The trade off is that you are one client among many, priority is negotiated rather than assumed, and some agencies quietly hand your build to the cheapest available person once the contract is signed.

Staff augmentation. Right for most companies that need WordPress work continuously but not a headcount. You get a developer embedded in your standups and your Slack, working your board, with an agency behind them handling code review, backfill when they are sick, and escalation to someone senior when WooCommerce HPOS compatibility turns into a real problem. The trade off is you are still managing the work. If you have nobody to say what to build, augmentation will not save you.

What WordPress developers actually cost

These ranges come from Digital Heroes delivery and from the offers we compete against, not from a survey. Rates move sharply with region and with seniority, so treat these as bands, not prices.

• Offshore freelance (South Asia, parts of Eastern Europe, Latin America): roughly $20 to $50 an hour. Below about $15 you are almost always buying plugin assembly.
• Onshore freelance (US, UK, Canada, Australia, Western Europe): roughly $65 to $150 an hour. The top of that band is usually a WooCommerce or performance specialist.
• Delivery managed team or staff augmentation: roughly $45 to $110 an hour blended, because you are paying for review and process alongside the hands.
• Onshore agency: roughly $150 to $250 an hour, higher for enterprise or WordPress VIP work.
• In-house US base salary: the offers we see for a genuine PHP-and-hooks WordPress engineer commonly land between $80,000 and $140,000, with WooCommerce depth at the upper end.

The in-house number is the one founders get wrong. Salary is not cost. Once you add payroll taxes, benefits, equipment, software seats and workspace, the planning rule we use is base multiplied by roughly 1.25 to 1.4. Then add recruiting: the contingency recruiters we have used quote a percentage of first year salary, and doing it yourself is not free either, it is forty or fifty hours of your own time across sourcing, screening and interviewing. Then add ramp. On a mature WordPress codebase with custom post types, a half dozen ACF field groups and inherited plugin decisions, expect four to eight weeks before independent shipping. A $110,000 hire is realistically a $170,000 to $190,000 first year commitment. That math is often what pushes a company toward augmentation for the first year.

How to vet a WordPress developer

Screen for the hooks system first, because everything else follows from it. Ask them to explain, out loud, the last filter they wrote and why it was a filter rather than an action. Someone who genuinely builds on WordPress will talk about return values without hesitating. Someone who assembles sites will describe a plugin setting.

Then ask these, in order:

• "A client wants to change the wording in a plugin's confirmation email. Walk me through it." The right answer reaches for a filter the plugin exposes, or a template override in the theme, or a small must-use plugin in wp-content/mu-plugins. The wrong answer is "I edit the plugin file."
• "Where do you put custom post type registration, and why?" A plugin hooked on init, not the theme, because content should survive a redesign. If they say functions.php, keep probing.
• "This form submits to admin-ajax. What has to be in place before it touches the database?" You want check_ajax_referer or wp_verify_nonce, current_user_can for the capability, sanitize on the way in, $wpdb->prepare for any raw SQL, and escaping late on output with esc_html or esc_attr. If escaping and capabilities never come up unprompted, that is your answer.
• "You are adding a REST endpoint. What is the one argument people forget?" permission_callback. If they say __return_true and do not flinch, stop.
• "An archive page takes six seconds. First move?" Query Monitor, look at query count and the slow queries, suspect an unindexed meta_query, check autoloaded options in wp_options, consider filtering with pre_get_posts instead of a second WP_Query, then transients or the object cache. If their first move is "install WP Rocket," they are papering over it.
• "How do you deploy?" Git, a staging environment, WP-CLI for search-replace on migrations because a raw SQL find and replace corrupts serialized data in wp_options. If the answer is FTP or a file manager, stop.

For portfolio review, do not look at screenshots of finished sites. Ask for a repository containing a plugin or theme they wrote. Open it and look for: an ABSPATH guard at the top of each file, prefixed or namespaced function names so nothing collides, a text domain used consistently, a composer.json, a phpcs.xml pointing at the WordPress Coding Standards ruleset, and block.json if they claim Gutenberg. Look at how they enqueue assets. Loading a stylesheet on every admin page through admin_enqueue_scripts instead of hooking the right screen is a small tell that says a lot.

If you run a take-home, keep it to three or four hours and make it stack-specific: a small plugin that registers a custom post type, exposes one REST route through register_rest_route with a real permission_callback, and ships one custom block with a couple of attributes and a server side render_callback. That single exercise separates the two populations completely, and you can grade it in twenty minutes.

Red flags

• "There is a plugin for that" is the answer to every requirement. Forty plugins is not a stack, it is forty update paths and forty attack surfaces. Ask instead: "Which of these would you write yourself, and why?"
• They talk about page builders when you describe an application. Elementor and Divi are fine for marketing pages. If your problem is booking, pricing logic or member state, a builder will produce a four megabyte page that nobody can maintain. Ask instead: "Where does the business logic live in your answer?"
• No git, no staging. Editing live through the theme editor or FTP means there is no history, no rollback and no review. Ask instead: "Show me the last commit you pushed on a WordPress project."
• They suggest disabling auto updates to stop things breaking. That is not a fix, it is a security posture you will regret when the next plugin CVE lands and Patchstack or Wordfence starts screaming. Ask instead: "How would you make updates safe rather than optional?"
• WooCommerce experience that stops at "I have set up stores." Ask instead about High Performance Order Storage compatibility, or how they would add a field to checkout now that checkout is blocks, or what they do when wp_postmeta order lookups get slow. Vague answers here are expensive later.

When this is the wrong hire, and how Digital Heroes staffs the right one

Be honest about the problem first. If you need a marketing site that loads fast and lets your team publish, you may need a designer and a content person more than an engineer, and a well chosen block theme with theme.json will get you further than custom PHP. If you are building a product with accounts, billing and real application state, ask whether WordPress is the right foundation at all before you hire for it, because forcing an app into wp_posts is a decision you pay for every quarter. If you are running WooCommerce at volume, or you have a plugin layer nobody understands, or your Core Web Vitals are sinking under inherited bloat, that is when a real WordPress engineer pays for themselves.

At Digital Heroes we staff WordPress as a small pod rather than a lone hire. A senior PHP engineer owns the plugin and theme layer and every hook decision. A front end developer handles blocks, theme.json and the editor experience your team actually uses. A delivery lead keeps git, staging and the WP-CLI deploy path honest so nothing ships from a file manager. We do not put site assemblers on application work, and we say so before the contract rather than after the rebuild. Most clients start with a scoped diagnostic on the existing codebase, because knowing what you already own changes what you should hire for.