How to Hire a WordPress Developer: Skills, Tests, Red Flags

"WordPress developer" is one job title for two different jobs. Some people assemble sites from themes, page builders and plugins. Others write the plugins. Both are worth paying for, and most hiring mistakes come from getting one when you needed the other. Knowing how to hire a WordPress developer starts with knowing which of the two your project calls for.

From there it is a matter of checking a short list of skills, asking for specifics, paying for a small trial and looking at the code that comes back. None of it requires you to read PHP.

Before you hire a WordPress developer, decide which kind you need

An implementer installs a theme, sets up a page builder, configures plugins and enters content. For a brochure site, a set of landing pages or a standard store, that is the right hire. It costs less, it is faster, and custom code would only add things to maintain.

A developer writes PHP and JavaScript: custom plugins, integrations with outside systems, data migrations, performance work, fixes for plugin conflicts. You need one when the site has to do something no plugin does, or when a plugin almost fits and has to be extended safely.

Trouble starts in the gap. An implementer asked for custom logic tends to paste snippets into functions.php or stack plugin on plugin until the site slows down. A developer asked to choose colors and write page copy is an expensive route to an average design. Write down the three hardest things your project needs, and the category usually becomes obvious.

Skills that separate a developer from a site builder

• Hooks. Actions and filters are how WordPress behavior is changed without editing core, a plugin or a parent theme. A developer reaches for a hook first and can explain why edits to those files vanish on the next update.
• The data model. Custom post types, taxonomies, post meta and WP_Query, plus a view on when data belongs in its own table.
• The security APIs. Sanitizing input, escaping output with functions such as esc_html() and esc_url(), nonces, capability checks with current_user_can(), and $wpdb->prepare() for hand-written SQL. The security section of the developer handbook is the reference.
• The REST API or the block editor, depending on your project: an endpoint with a proper permission_callback, or a block defined in block.json.
• Working method. Git, a local environment, a staging site, WP-CLI, and debugging with WP_DEBUG_LOG instead of guessing.

For a store, add WooCommerce specifics: its hooks and its order and product objects. Someone who reads order data straight from post meta has not kept up with how WooCommerce stores orders, which is one reason a WooCommerce developer is a role of its own.

What to ask in the interview

Scenario prompts work better than "rate your PHP out of ten". Each of these has a recognizable good answer.

"A client wants different text on the checkout button. Where does that change go?" In a small custom plugin or a child theme, through a filter. Never in the plugin's own files.

"How does a change get from your machine to the live site?" You want to hear version control, a staging copy, a deployment step and a backup. "I edit it in the theme editor" on a live business site is a no.

"A form saves data and shows it on a page. What do you check on the way in and on the way out?" A nonce and the user's capability, sanitized input, a prepared query, escaped output.

"The admin area has become slow. How do you find the cause?" Measure before changing anything: a profiling plugin such as Query Monitor, the slow query log, and switching plugins off one at a time on staging.

"When would you tell a client not to build something custom?" When a maintained plugin already does it. A developer who never says this will build you things you then pay to maintain.

Run a short paid trial task

An hour of conversation shows how someone talks. Half a day of work shows how they build. Keep the task small, pay for it, and run it on a staging site or in a private repository, never on the live site. Tasks that reveal a lot in four to eight hours:

• a small plugin that registers a custom post type, adds a settings field and outputs a list of items through a shortcode or block
• a real, non-urgent bug from your own backlog
• a written review of one of your existing custom plugins, with the three changes they would make first

Judge the result on more than whether it works:

1. Did they ask questions before starting, or guess?
2. Did the work arrive as a plugin in Git with a few clear commits, or as a zip of edited files?
3. Does it activate with WP_DEBUG switched on and no notices?
4. What happens with no data, and with a logged-out visitor?
5. Did the hours match the estimate, and did they say so early if not?

Do not ask for free work, and do not set a twenty-hour "test". Good developers decline both, and you end up choosing among the ones who did not.

Review a code sample when you cannot read PHP

Ask for a plugin they wrote, or use the trial task. Look at the outside first. Is there a readme? Does the commit history say what changed and why? Are function names prefixed or namespaced, so they cannot collide with other plugins?

Then let a tool read it. Plugin Check, maintained by WordPress.org, tests a plugin against the plugin directory's standards for security, performance and more. Install it on a test site, open Tools > Plugin Check and pick the plugin, or run it from the command line:

wp plugin check sample-plugin

A report full of missing escaping and nonce errors tells you plenty. A clean one is a good sign and not proof, so on a large project pay a second developer for an hour of review. The WordPress Coding Standards give that reviewer a shared yardstick.

Red flags that should end the conversation

• They want to work directly on the live site and do not mention a backup or staging.
• They edit core files, plugin files or the parent theme. Those changes disappear with the next update, or block updates for good.
• They quote without seeing the site. Nobody can price work on a codebase they have not opened.
• They offer premium themes or plugins "included" without a license. Pirated copies are a common source of malware, and you get no updates.
• They register your domain, hosting or licenses in their own name. You should hold every account and grant access.
• They promise search rankings or a perfect speed score. Neither is in a developer's gift.

Freelancer, agency developer or in-house hire

For a small, well-defined job on a simple site, a good freelancer is often the best value, and the steps above are how you find one. If the website is your main sales channel and changes every day, an in-house developer who knows the business will repay the salary.

A developer from an agency makes sense between those two: when the work is continuous but not a full-time job, when you want cover for holidays and illness, or when the site needs design, QA and store knowledge that one person rarely has. That is the case our WordPress developers for hire are meant for. You see resumes and interview before you commit, and a developer who is not the right fit is replaced. For a single custom feature, a quoted plugin development project may be simpler than hiring anyone, and routine updates belong in a maintenance plan.

If you are taking a site over from a previous developer, our handover checklist lists what to collect before they leave.

Frequently asked questions

How much does it cost to hire a WordPress developer?

Rates vary widely with location, experience and whether you hire a freelancer or go through a company, so a single figure would mislead. Compare candidates on the same paid trial task. The cheapest hourly rate often produces the most expensive site once rework is counted.

Do I need a WordPress developer or a designer?

If the problem is how the site looks and reads, start with a designer and have an implementer or developer build the result. If the problem is what the site does, such as a calculation, an integration or a slow checkout, you need a developer. Larger projects need both.

What access should I give a new WordPress developer?

Give them their own administrator account, not a shared login, and access to a staging copy first. Hosting, domain and license accounts stay in your name. Take a full backup before they start, and remove or downgrade the account when the work ends.