Table of Contents

• Stage 1: Portfolio Review
• Stage 2: Technical Screening
• Stage 3: Reference Checks
• Stage 4: Paid Test Task
• Stage 5: Contract Review
• Frequently Asked Questions

Most hiring mistakes happen not because business owners didn’t check enough, but because they checked the wrong things. Evaluating a WordPress developer on the strength of a polished website and a confident sales pitch isn’t vetting — it’s optimism.

A structured vetting process reduces the probability of a bad hire significantly. This guide walks you through each stage.

Stage 1: Portfolio Review

Evaluate live work, not mockups: Request the URLs of five recent projects. Visit each one. Assess mobile responsiveness, loading speed, and design quality. Use Google PageSpeed Insights to score performance.

Match portfolio to your project type: A developer with ten WooCommerce builds is well-suited for an eCommerce project; less so for a content-heavy services site. Look for relevance, not just volume.

Look for business outcomes: Strong portfolio presentations note what the site was built to achieve and whether it delivered. If context is absent, ask: ‘What was this project trying to accomplish for the client?’

Stage 2: Technical Screening

You don’t need to be a developer to ask these questions — but a competent developer will answer them clearly and confidently:

‘Walk me through your typical development workflow.’ A professional workflow includes discovery, wireframing (where applicable), staging environment, client review stages, QA testing, and documented handover.

‘How do you handle site security?’ Expect to hear: SSL, strong authentication, reputable security plugins, user role management, and regular updates.

‘What’s your approach to WordPress performance?’ They should mention caching, image optimisation, database cleanup, minimal plugin footprint, and ideally CDN configuration.

‘How do you approach SEO at the technical level?’ Core Web Vitals, clean URL structure, schema markup, and XML sitemaps should feature in their answer.

‘What happens if something breaks after launch?’ This reveals whether they have a post-launch support protocol — or are simply planning to move on.

Stage 3: Reference Checks

Ask for two or three past clients you can contact directly. Email or call them and ask:

‘Did they deliver on time and within budget?’ | ‘Was communication proactive or did you have to chase them?’ | ‘Were there any problems — and if so, how were they handled?’ | ‘Would you hire them again?’

The last question is the most revealing. A client who says ‘yes, definitely’ with genuine enthusiasm is a stronger signal than a polished written testimonial.

Stage 4: Paid Test Task

For significant projects, consider a small, paid test task before committing to the full engagement. Examples include: reviewing your existing site and providing a written technical assessment, building a single page or component from your brief, or configuring a staging environment.

This tests not just technical ability but also communication quality, turnaround time, and how they handle feedback. The investment is modest; the signal is high.

Stage 5: Contract Review

Before signing, ensure the contract includes: a detailed scope of work; payment schedule tied to milestones; IP ownership clauses; revision policy; agreed go-live date; and handover documentation requirements.

If the developer pushes back on any of these elements, treat it as a signal.