How to Hire a WordPress Developer (2026 Guide)
If you searched for help for WordPress hoping to find a real developer rather than another support ticket queue, here’s the direct answer: before you hire anyone, check three things. Ask for proof of custom-coded work in their portfolio, confirm in writing that you own the code once the project ends, and test their design-to-code skill with a small paid task. Everything below walks you through exactly how to do that, step by step.
Most searches for help for WordPress land on WordPress.com’s support hub or the WordPress.org forums. Those are great if you forgot your password or need to restore a backup. They are useless if your actual problem is "I need to find a competent person to build my site and I have no way to tell a real developer from someone who just installs a template and swaps the logo." That’s a different problem.
I’ve spent years on both sides of WordPress projects, as the freelancer building the site and as the consultant called in after a hire went sideways. The pattern repeats often enough that it’s worth writing down. Here is the six-step vetting process I’d run if I were hiring a WordPress developer today.
Step 1: Define the Real Scope Before You Post the Job
Vague job posts attract vague developers. If your ad says "need someone to fix my WordPress site," you’ll get quotes ranging from $50 to $5,000 for wildly different work, because nobody actually knows what "fix" means yet. Scope it first.
A workable scope of work should answer these questions before you contact a single candidate:
- How many pages or templates does the site need (home, service pages, blog, checkout, etc.)?
- Does it need custom theme development, or is a modified existing theme acceptable?
- What third-party tools must it integrate with (CRM, email marketing, payment gateway, booking system)?
- Will the design come from a Figma file, a JPEG mockup, or does the developer need to design it too?
- What’s the realistic timeline, including a buffer for revisions?
- Who owns the hosting account, domain, and admin login during and after the build?
- Do you need ongoing maintenance after launch, or is this a one-time build?
- What does "done" look like? Define your acceptance criteria in advance.
Write this down in a shared document before you post anything. If you’re still unsure how detailed to get, examining what a properly scoped engagement typically includes will help clarify expectations.
Step 2: Screen for Code Ownership, Not Just Portfolio Screenshots
A polished portfolio screenshot proves almost nothing. Anyone can take a nice photo of a website they were only tangentially involved in, or one built almost entirely from a premium theme with a color swap. What actually proves skill is access, not images.
Ask every candidate for one of these instead of a screenshot:
- A link to a live staging site they built, that you can click around in.
- Access to a GitHub or GitLab repository showing commit history over time (not a single upload).
- A short screen recording of them building something from scratch.
Then ask the ownership question directly: "When this project is finished, do I own the full source code, including any custom functionality you write, with no ongoing licensing fee to you?" A professional developer answers this without hesitation. Someone who hedges, or who says the "customization" is really just a paid plugin license they resell to you every year, is telling you something important.
This is also where the difference between a child theme and a directly modified parent theme matters. A child theme is a separate theme that inherits the styling and functionality of a parent theme while keeping your custom code in its own files, so a parent-theme update never wipes out your changes. If a developer edits the parent theme’s files directly, every future WordPress or theme update can erase months of paid customization overnight. WordPress.org’s official developer documentation explains this exact risk and is worth reviewing even if you never touch code yourself.
Step 3: Test Design-to-Code Skill With a Small Paid Task
Design-to-code conversion – turning a Figma file or a flat JPEG mockup into a pixel-accurate, responsive WordPress template – is one of the clearest skill filters available, and almost nobody uses it before hiring.
Structure a small paid test task like this:
| Element | Recommendation |
|---|---|
| Scope | One page or one section (hero + one content block), not the whole site |
| Format | Give them the exact Figma link or JPEG you’ll use for the real project |
| Payment | Pay for it, even if small ($50–$150 is typical for a single section) |
| Time box | 2–4 days maximum |
| What you’re grading | Pixel accuracy, responsive behavior on mobile, clean handoff of the code |
Why does this reveal so much? Converting a static design into working, responsive markup that matches spacing, font weights, hover states, and breakpoints exactly requires actual front-end skill. Someone who only knows how to drag prebuilt sections in a page builder will either refuse the task, ask you to "simplify" the design first, or hand back something that looks close but breaks on mobile.
Page builder output versus custom-coded theme:
| Signal | Page Builder Only | Custom Theme Developer |
|---|---|---|
| Design match | Close approximation to the mockup | Pixel-accurate to the mockup |
| Page load speed | Often heavier, more plugin dependencies | Leaner, fewer dependencies |
| Editing after launch | Locked into that builder’s ecosystem | Editable via block editor or clean custom fields |
| Long-term flexibility | Limited by the builder’s own constraints | Extendable with custom PHP/JS as needed |
| Typical cost | Lower upfront | Higher upfront, often lower over time |
Neither approach is inherently wrong. A page builder can be the right call for a simple brochure site on a tight budget. The problem is a developer who can only do page-builder work while marketing themselves as a "custom developer." Understanding the difference between the block editor and page builder plugins helps you ask sharper questions when you’re hiring a WordPress developer.
Step 4: Ask the Questions That Expose a Template Installer
Technical interview questions don’t need to be intimidating. You’re not testing whether they can recite documentation; you’re testing whether they can explain their own work in plain language.
| Question | Strong Answer Sounds Like | Weak Answer Sounds Like |
|---|---|---|
| "Walk me through how you’d build this page from the Figma file." | Describes breaking the design into template parts, custom fields, and responsive breakpoints | Says they’ll "find a similar template and customize it" |
| "Do you use child themes or edit the parent theme directly?" | Explains child theme structure without prompting | Isn’t sure what a child theme is |
| "What’s your process for version control?" | Mentions Git, commit messages, branches for features | Says they just keep zip file backups on their desktop |
| "How do you hand off a finished project?" | Lists staging access, repo access, credentials transfer, documentation | Says "I’ll just email you the files when it’s done" |
| "What happens if the client’s plugin conflicts with your custom code?" | Describes debugging approach, isolating the conflict | Says "that shouldn’t happen" with no follow-up |
| "Can you show me a site where you wrote custom PHP or JavaScript?" | Points to a specific feature and explains the logic | Shows only theme customizer screenshots |
| "How do you test for mobile responsiveness?" | Names specific breakpoints and testing tools | Says "it usually just works" |
| "What’s your revision policy?" | Clear number of rounds, defined in the contract | Vague, "we’ll figure it out as we go" |
| "How do you handle a staging environment?" | Describes a staging URL separate from production | Doesn’t use staging, edits the live site directly |
| "If I need to bring in another developer later, what would you hand over?" | Full inventory: code, credentials, documentation, no fees attached | Gets defensive or vague about access |
The answers to these questions reveal whether you’re working with someone who codes custom solutions or assembles templates.
Step 5: Check How They Handle Handoffs and Mid-Project Switches
This is the step almost nobody plans for, and it’s the one I get called about the most. A client hires a freelancer, the relationship sours partway through (missed deadlines, disappearing communication, scope disputes), and now they need to bring in someone new mid-build. What happens next depends entirely on what documentation exists.
Proper handoff documentation includes:
- A staging site URL with working login credentials, separate from the live production site.
- Full version control history (a Git repository, not a folder of zip files named "final_v3").
- A written list of every plugin installed and why it’s there.
- Admin-level WordPress access and hosting account access, transferred cleanly, not "shared" indefinitely through the original developer’s account.
- Any custom code documented with at least basic comments explaining what it does.
In my experience helping clients who needed to switch developers mid-project, the most common failure pattern isn’t malice – it’s simply that no handoff plan existed from day one. The original freelancer built everything directly on the live site with no staging environment and no version control history. When the client asked for access to bring in someone new, there was nothing clean to hand over.
The fix is prevention, not cleanup. Build the handoff requirement into the contract before work starts, not after a relationship breaks down. When you’re deciding between a solo freelancer and a small agency, a few structural differences are worth weighing before you commit.
Freelancer versus agency, at a glance:
| Factor | Freelancer | Agency |
|---|---|---|
| Cost | Generally lower hourly/project rate | Generally higher, covers overhead |
| Backup if unavailable | Often none, single point of failure | Team can cover illness, vacation, turnover |
| Communication speed | Can be very fast, one person to reach | Sometimes slower, more layers |
| Specialization depth | Varies widely by individual | Often has dedicated design, dev, QA roles |
| Best fit | Small, well-defined projects | Larger builds needing multiple skill sets |
For the freelancer side specifically, structure contracts to protect you if the relationship doesn’t work out.
Step 6: Confirm Communication and Delivery Expectations Before You Sign
Even a technically excellent developer can create a frustrating project if expectations around communication were never set. Before you sign anything, get the following in writing:
- Response time. How many hours (not "soon") will they take to reply to a message during business days?
- Check-in cadence. Weekly update, milestone-based update, or only at completion?
- Revision policy. How many rounds of revisions are included before additional work is billed hourly?
- Change process. If you ask for something outside the original scope, how is that priced and approved?
- Delivery format. Will you get a walkthrough call at launch, written documentation, or both?
None of this needs to be complicated. It just needs to exist in writing, agreed to by both sides, before the first invoice is paid.
Common Red Flags When Switching WordPress Developers
Based on recurring patterns from projects that needed a mid-build developer switch, these are the warning signs worth taking seriously:
- No staging site exists. All changes were made directly on the live site, meaning every edit was a live-fire risk.
- No version control history. Work exists only as periodic zip backups with no record of what changed or when.
- "Customization" means color and logo only. The site is a premium theme or page builder template with surface-level branding changes, nothing structural.
- Refuses a paid test task. A confident developer welcomes a small, paid trial. Reluctance is a signal worth noting.
- No documentation of plugins or custom code. Nobody can explain why a given plugin was installed or what a custom function does.
- Communication gaps of a week or more with no notice. Especially concerning mid-project, when momentum matters.
- Ownership questions get vague answers. Any hesitation about who owns the code once payment is complete.
- Admin access is never fully transferred. The original developer keeps a "backup" login indefinitely without a clear reason.
If you’re currently in the middle of one of these situations, know that a clean handoff is still possible – it just takes more diagnostic work upfront from whoever you bring in next.
Frequently Asked Questions
Who can help me with WordPress if I need a developer, not just support?
Platform support channels handle account, hosting, and plugin issues. For actual development work – custom themes, design-to-code conversion, or fixing a broken build – you need a freelance developer or a small agency, vetted using a portfolio review, a paid test task, and a direct code-ownership conversation.
What’s the difference between a WordPress developer and general WordPress support?
Support handles troubleshooting within the existing platform: password resets, plugin conflicts, basic configuration. A developer builds or modifies the actual code and theme structure, custom templates, integrations, and design-to-code work that support staff typically don’t perform.
How do I check if a WordPress developer owns the code they write, or if I do?
Ask directly, in writing, before hiring: "Once this project is paid in full, do I own all custom code with no ongoing licensing fee?" Get the answer in the contract, not verbally.
What is a child theme and why does it matter when hiring someone?
A child theme is a separate theme folder that inherits the styling and features of a parent theme while storing your custom changes safely, so parent theme updates never overwrite your work. Developers who skip this and edit the parent theme directly put your customization at risk every time an update runs, as WordPress.org’s developer handbook explains.
How can I tell if someone only installs page builder templates instead of coding?
Ask to see a live staging site or repository showing custom PHP or JavaScript, not just screenshots. Give them a small paid design-to-code test task. Someone who can only assemble prebuilt sections will struggle to match a specific design pixel-for-pixel or explain their own code logic.
Should I give a paid test task before hiring a WordPress developer?
Yes. A small, time-boxed, paid task (one page or section, built from your actual Figma or JPEG design) reveals real skill far better than a portfolio review alone, and it costs far less than discovering a mismatch after a full contract is signed.
What happens if I need to switch WordPress developers mid-project?
It’s manageable if a staging site, version control history, and documentation exist. Without those, the incoming developer has to spend time reverse-engineering the existing build before any new work can start, which adds cost and delay.
Is WordPress outdated in 2026, or still worth hiring a developer for?
WordPress still powers a substantial share of websites worldwide and continues active development through the WordPress Foundation and the broader open-source community. It remains a reasonable platform choice for most small business and content sites, provided the person building it understands custom theme development rather than relying solely on page builder templates.
Can AI tools build a WordPress website instead of hiring a developer?
AI tools can speed up drafting copy, generating layout ideas, or scaffolding basic code, but they still fall short on custom integrations, accessibility compliance, and pixel-accurate design-to-code conversion for anything beyond a simple template. Pairing AI tools with a human developer who reviews and customizes the output tends to produce better results than relying on AI alone.
Getting This Right the First Time
Hiring the right person for a WordPress project isn’t about finding the cheapest quote or the fastest turnaround. It’s about verifying, before any money changes hands, that the person you’re trusting with your site actually codes rather than assembles, actually documents their handoffs, and will hand you full ownership of what you paid for. Run the six steps in order: scope it, screen for ownership, test the skill, ask the pointed questions, confirm the handoff plan, and lock down communication expectations in writing.
Do that, and you’ll avoid the single most common and most expensive mistake in this space: discovering six months in that "customization" only ever meant a logo swap.
Sources
My right hand does not know how much my left hand has given, and vice versa. Over the years, I have given to orphanages, street children and their families, the elderly, women seeking livelihood opportunities, widows, and people who are on the fringes of society. My logic is simple: I never want anyone to feel as though they have been forgotten by society. Sometimes it does not take much. People on the streets have actually smiled at me simply because I gave them a cookie. That smile can stay with you much longer than you expect. No one should feel forgotten. I’m a little like the city that raised me. My favorite food is beef pares, tenderly cooked beef simmered for several hours until the meat practically melts in your mouth. Its taste cannot easily be contained by a poverty of vocabulary when it is cooked just right, and the stew is simply the icing on the cake. In a strange way, it reminds me of the beautiful ways God has arranged my heart through my unique experiences in life. Manila itself feels like a melting pot, no pun intended, of food, beverages, languages, art, people, contradictions, and real life. I think I have become a little like the city that raised me. Read About Me.
Join the conversation
Good work gets better when people bring thoughtful questions, ideas, and perspective.