WordPress specialist developer: what changes compared to a generalist.

Moving a production WordPress site is more than a backup and restore. You need to know how WordPress serialises URLs in the database, manage DNS TTL before propagation, flush and rebuild caching layers without leaving stale pages. One wrong step in sequence and the site goes down during peak hours.

A specialist has a protocol: search-replace on serialised data, checking for hardcoded options, staging tests before cutover. There is no improvisation. This reduces the risk of errors and makes the process faster to run and easier to delegate.

The typical response to a plugin conflict is to disable one and find an alternative. That works on simple sites. On structured projects — where every plugin is there for a reason — replacement isn't an option. You need to understand which hook they're colliding on, who has priority, and whether you can resolve it with a custom filter.

Diagnosing a WordPress conflict requires knowing plugin load order, the hook and filter system, and how to isolate the problem without breaking the rest of the build. A generalist can do it; a specialist does it in a fraction of the time.

ACF, custom post types, and meta queries are standard on any reasonably structured agency project. Writing WordPress queries that scale requires deep knowledge of WP_Query: when to use meta_query, when a direct SQL query is better, how to use the object cache to avoid repeated database round-trips.

A generalist produces working code. A specialist produces working code that doesn't degrade when the site grows from a hundred to ten thousand posts. On an e-commerce site or a content-heavy portal, the difference shows in load times before the client even asks for an audit.

Any developer can open Lighthouse. Knowing what to look at after is a different matter. On WordPress the most common bottlenecks are platform-specific: render-blocking theme CSS, filters on the_content that inflate markup, synchronously loaded scripts from form plugins, unoptimised images because wp_get_attachment_image isn't being used correctly.

A specialist arrives with a diagnostic framework already in place: they know that on certain builders LCP depends on how hero images are loaded, that certain cache plugins break native lazy loading. The diagnosis is faster and the fixes are more precise.

The worst time to bring in a specialist is halfway through a project, after a generalist has already built the architecture. Getting up to speed on someone else's codebase, understanding the decisions made, and correcting them without breaking the rest costs more than starting with the right person from day one.

This isn't a criticism of generalists — it's the structure of the problem. Every developer optimises for what they know. If the project requires WordPress-specific skills, involving a specialist from the start is almost always cheaper than involving them after.

The most useful questions aren't about years of experience. They're about concrete situations: have you handled a zero-downtime migration? How do you resolve a plugin conflict on a shared hook? Have you worked with ACF on multi-post-type architectures? Vague or generic answers already tell you something.

A good indicator is also how they describe past mistakes. Someone who has resolved specific WordPress problems remembers them in detail — the type of problem, what they tried first, what worked. Someone who has only grazed the surface tends to generalise.

The right question isn't whether to outsource WordPress development, or even whether a candidate knows WordPress — almost everyone does. It's whether they can step into an active project, understand context without being walked through everything, and hand over something the team can pick up after them.

Autonomy reduces the coordination tax: a developer who needs constant direction on browser compatibility, plugin choice or layout consumes senior time as a dependency. Handoff quality is the other half — a build only its author can maintain isn't a finished project, it's an undeclared support contract. Concrete signals of a solid handoff: commented code where choices aren't obvious, ACF configured for non-technical editing, no undocumented plugin dependencies, staging that behaves like production before cutover.

Communication has to fit agency cadence: async updates with clear status, questions that arrive with a proposed answer already attached, escalation only for decisions that genuinely need PM input. The most useful evaluation questions aren't about years of experience — they're about concrete situations: how do you handle a brief with ambiguous scope, walk me through a delivery that didn't go as planned.

• A very low hourly rate with no explanation — the scope probably wasn't understood.
• A portfolio of solo work only — it doesn't prove they can operate inside an agency workflow.
• Slow responses during evaluation — that's the collaboration cadence to expect.
• No defined process for revisions and handoff — informal requests keep arriving after launch.

The real comparison isn't hourly rate versus gross salary. An in-house hire brings onboarding, hardware, software, paid leave and management time that accumulate before the role reaches real autonomy — and that cost stays active even when workload drops. A junior profile often needs ongoing review that pulls senior time away from higher-value work; white-label support works better when the capacity needs to step into staging and deliver without a long ramp-up.

Practical rule of thumb: if expected role utilisation stays below roughly 70 to 75% for several months, fixed hiring cost usually becomes harder to defend, and ready-to-start white-label capacity is the cleaner margin decision. If volume stays stable through most of the year and the agency already has senior time for supervision, in-house can be the better long-term fit.