Choosing a WordPress developer is harder than it should be. The work is invisible until it isn’t. The proposals all look reasonable. Three months in, you find out whether you picked well — and by then the cost of switching is high.
Here’s what actually matters when you’re hiring, in the order it matters.
1. Look at code, not just websites
Anyone can show you a portfolio of pretty homepages. Pretty homepages are the easy part. Ask for code. Specifically:
- A theme they’ve built (zip file or GitHub link)
- A custom plugin they’ve written
- The actual files for one of the live sites in their portfolio
If they can’t or won’t share any of this, they’re either ghostwriting their portfolio or they’re doing throwaway work they’re not proud of. Both are problems.
Even if you don’t read code, you can spot the difference. Clean code has consistent indentation, useful comments, descriptive variable names, and obvious structure. Bad code is a wall of text with magic numbers and a lot of “@TODO” markers.
2. Test their writing
The single best signal of a good developer is how they communicate in writing. Ask them to send you a written project plan before signing anything. Read it carefully.
What you want to see: clarity about what’s in scope and what isn’t. Specific timelines per phase. Honest acknowledgment of what they don’t yet know about your project. Questions about your business, not just your design.
What’s a red flag: vague language, no concrete deliverables, “we’ll figure it out as we go,” or proposals that look like they were generated from a template with your company name pasted in.
3. Ask about pricing model and ownership
Two questions filter out 80% of bad-fit developers:
“What’s your pricing model — fixed or hourly?” If they’re hourly without any cap, they’re putting all the budget risk on you. Fixed pricing is the standard you should expect.
“At what point does the IP and code ownership transfer to me?” The right answer is “on final payment.” Anything else — license-only, ongoing royalties, code in their account — is a problem. You’re paying for the work; you should own the work.
4. Talk to former clients
Don’t ask the developer for references. Ask for two specific references: someone who launched in the last 6 months, and someone who’s been a client for over a year.
The recent client tells you what the build process is like today. The long-term client tells you what happens after the project ends — whether maintenance is responsive, whether bugs get fixed, whether the relationship survives the inevitable disagreement.
A developer who can’t or won’t connect you with both is showing you something.
5. Watch the discovery call
Good developers spend the first 30 minutes asking questions. Bad developers spend the first 30 minutes pitching their process and showing you slides.
The questions to listen for: who’s your customer, what’s the goal of the site, what does success look like, what’s the editor team’s experience level, what integrations matter, what does your existing analytics show. If a developer doesn’t ask any of these and just wants to know your budget and timeline, run.
The shortlist
By the end of this process you should have 2–3 finalists. Get written proposals from each. Compare not just the price but the structure: what’s in scope, what’s out, what’s the timeline, what’s the support window after launch, what’s the change-request process.
One last thing: the cheapest proposal almost always isn’t the cheapest project. The variance comes from how things go when something doesn’t go to plan, and the cheap option usually has the worst response in those moments. The hidden cost of cheap web work covers this in depth.
If you’re in this process now and want a second opinion on a proposal you’ve received, our team will look at it and give you honest feedback for free. We do this even when we’re not the right fit for the project — it’s the kind of work the industry needs more of.
