WordPress Plugin Developer Hiring Checklist: Qualification Criteria for Buyers
Most plugin engagements begin with the buyer holding several candidate vendors and limited time to choose between them. The pressure produces shortcuts: a recommendation from a colleague, the cheapest quote, the most polished website, the vendor who answered the first email fastest. Each of these is a signal, but none is sufficient on its own. The buyers who make good hiring decisions consistently are the ones who have a process for converting signals into evidence and evidence into a decision.
This checklist provides that process. It is structured as qualification criteria the buyer applies to each candidate, with a decision table at the end that aggregates the assessments. The framing is commercial: the question is not which developer is best in some abstract sense, but which developer is the right fit for this specific engagement, with this specific scope, this specific timeline, and this specific budget. A great developer for one project is a poor fit for another; matching the developer to the project is the buyer’s job.
Timeline framing: when in the hiring process to use the checklist
The checklist works best when applied in three passes rather than once. Each pass narrows the candidate pool by a different filter.
The first pass is fast. The buyer has perhaps ten to fifteen candidates from referrals, search results, directory listings, and inquiries. The first-pass checklist is short: does the candidate work in the plugin development space? Are they available on the timeline you need? Are they in a reasonable rate band for your budget? Three to five questions, answered in fifteen minutes per candidate. The output is a shortlist of perhaps five candidates worth deeper evaluation.
The second pass is structured. The buyer evaluates the shortlist against the full qualification criteria. Each candidate has a written proposal, an interview, and reference checks. The second pass takes a day or two of buyer time per candidate; if it is taking less, the buyer is probably not asking enough questions. The output is a ranked list with one or two finalists.
The third pass is the commitment. The buyer negotiates terms with the finalist, reviews the contract carefully, and confirms that the engagement is structured to succeed. The third pass is short in calendar terms (perhaps a week) but high in attention. The contract is where good intentions become enforceable commitments; signing without reading is the most common buyer mistake.
First-pass checklist: filtering the long list
The first-pass checklist removes candidates who clearly do not fit, so that the second-pass effort is concentrated on candidates who might. The questions are simple and the answers are binary.
- Does the candidate have demonstrable WordPress plugin development experience (not just general web development)?
- Is the candidate’s portfolio (or claimed experience) consistent with the complexity of your project?
- Is the candidate available during the timeline you need?
- Is the candidate’s rate band consistent with your budget?
- Does the candidate work in a language you can communicate in?
- Does the candidate’s time zone allow for sufficient overlap with your working hours?
- Does the candidate operate in a way (freelancer, agency, studio) that fits the way you want to engage?
A candidate who fails any of these is removed from the list. The shortcut is not unfair; the shortcuts that exclude unfit candidates protect the buyer’s time for the candidates who fit.
Second-pass qualification criteria
The second pass evaluates each shortlisted candidate against criteria that predict engagement success. The criteria are grouped by area, with each criterion accompanied by the question the buyer asks and what a strong answer looks like.
Technical qualification
The candidate has the technical skills required for the specific project. This is more specific than general WordPress experience; it includes the particular technologies, integrations, and patterns the project will involve.
Question: have you worked on plugins similar in scope and technical character to this one? Strong answer: describes specific previous projects with comparable characteristics, can speak about the technical challenges they encountered, and explains how they would approach this project’s particular challenges.
Question: explain a technical decision from a recent project that involved a trade-off. Strong answer: describes the options, the trade-offs they considered, the decision they made, and what they learned from it. Weak answer: cannot recall a specific decision or gives a generic methodology answer.
Process qualification
The candidate has a way of running projects that produces predictable outcomes. The process does not need to match the buyer’s preferred methodology, but it needs to exist explicitly.
Question: walk me through how you would run this engagement, from kickoff to launch. Strong answer: describes the stages, the cadence of status, how scope changes are handled, how defects are triaged, how releases are managed. Weak answer: is generic about methodology without operational specifics.
Question: how do you handle a project that starts to fall behind schedule? Strong answer: describes specific actions: identifying the cause, deciding whether to add capacity, descope, or extend, communicating with the buyer, and revising the plan. Weak answer: claims that projects do not fall behind, or describes a process that does not include early communication with the buyer.
Communication qualification
The candidate communicates in ways that support a multi-month engagement. Clarity, consistency, and timeliness all matter.
Question: how often will I hear from you during the engagement, and through which channels? Strong answer: describes the cadence (weekly status, milestone reviews, ad-hoc as needed), the channels (email for written record, video for substantive discussions, chat for quick questions), and the expected response times. Weak answer: is vague about cadence or implies the buyer will need to chase for updates.
Question: what do you do when you disagree with the buyer about a decision? Strong answer: describes raising the disagreement directly, explaining the reasoning, and respecting the buyer’s final decision while documenting any concerns. Weak answer: avoids disagreement entirely, or describes overriding the buyer’s preference.
Commercial qualification
The candidate’s commercial structure (pricing, payment, contract terms) is reasonable and transparent.
Question: how is your pricing structured, and what is included? Strong answer: itemized line items, clear definition of what is in scope, clear handling of change requests, and reasonable payment milestones tied to deliverables. Weak answer: a single headline number without detail, or payment milestones tied to calendar dates rather than deliverables.
Question: what warranty terms do you offer after release? Strong answer: a defined warranty period (commonly thirty to ninety days) covering defects against the agreed scope at no additional charge. Weak answer: no warranty, or warranty terms that exclude almost everything.
Reference qualification
The candidate has previous clients willing to speak about their engagements honestly.
Question: can you provide two or three references from comparable projects? Strong answer: provides the references promptly, including contact information, and the references are accessible by phone or video. Weak answer: provides only written testimonials, or references are unresponsive or only available by email.
Question to ask the references: what would you do differently if you were starting the engagement again? Strong reference answer: speaks specifically about what went well and what could have been better, in a tone that is honest rather than promotional. Weak reference answer: only positive generalities, with no acknowledgment of any imperfection.
Decision table: aggregating the qualification
The table below provides a structure for recording your assessment of each candidate. Score each candidate on each criterion from one (poor) to five (excellent). The total is a relative indicator for comparison, not a deterministic ranking.
| Criterion | Candidate A | Candidate B | Candidate C | Why this criterion matters |
|---|---|---|---|---|
| Plugin-specific technical experience | — | — | — | WordPress plugin work has patterns that general PHP experience does not cover |
| Code quality on sample or past work | — | — | — | Best predictor of code quality on your project |
| Specific technical fit for your project | — | — | — | Experience with similar projects predicts smoother delivery |
| Project process clarity | — | — | — | Predicts whether problems are caught early or surface late |
| Change management process | — | — | — | Scope drift is the most common cause of overrun |
| Defect management process | — | — | — | Determines how issues are handled during and after release |
| Communication clarity | — | — | — | Affects how cleanly requirements are captured and status is reported |
| Communication cadence and reliability | — | — | — | Predicts whether you will need to chase for updates |
| Pricing transparency | — | — | — | Determines whether you can plan budget against the project |
| Warranty and maintenance terms | — | — | — | Affects what happens after release |
| IP and source code terms | — | — | — | Determines what you actually own at the end of the engagement |
| Reference quality | — | — | — | Most reliable predictor of how engagement will actually run |
| Cultural and time zone fit | — | — | — | Affects daily working experience over a multi-month engagement |
| Team continuity | — | — | — | Predicts whether the same people will be available for the whole engagement |
| Risk management approach | — | — | — | Predicts how the candidate handles uncertainty during the engagement |
| Total | — | — | — | — |
Special qualification criteria for specific situations
The general checklist above applies to most engagements. Several specific situations introduce additional criteria worth checking explicitly.
For projects requiring security expertise
The plugin will handle sensitive data, integrate with payment systems, or be deployed on sites with strict security requirements. Additional criteria:
- Has the candidate worked on plugins with comparable security requirements?
- Does the candidate describe security as part of their standard practice or as an add-on?
- Can the candidate explain common WordPress security patterns (capability checks, nonce verification, prepared statements, escaping) in operational detail?
- Has the candidate worked with external security auditors before, and how do they handle audit findings?
- Does the candidate carry professional indemnity insurance with coverage appropriate to the engagement?
For projects requiring accessibility compliance
The plugin’s output will be public-facing and needs to meet WCAG conformance at a specified level. Additional criteria:
- Has the candidate built plugins to accessibility conformance before?
- Can the candidate describe accessibility patterns specific to WordPress (heading structure, ARIA roles, keyboard navigation, screen reader compatibility) in operational detail?
- Does the candidate include accessibility testing in their standard QA process?
- Has the candidate worked with accessibility auditors and addressed their findings?
For projects with complex integrations
The plugin will integrate with multiple external services. Additional criteria:
- Has the candidate worked with the specific external services your project requires?
- Can the candidate describe their approach to handling API failures, rate limits, and authentication?
- Does the candidate build integration abstractions that survive third-party API changes?
- Has the candidate worked with webhooks, OAuth, and other integration patterns relevant to your project?
For projects requiring multisite compatibility
The plugin will be used on WordPress multisite installations. Additional criteria:
- Has the candidate built plugins with explicit multisite support before?
- Can the candidate describe the differences between site-level and network-level functionality?
- Does the candidate’s testing matrix include multisite installations?
For projects with regulatory or compliance requirements
The plugin’s deployment is subject to specific regulations (privacy frameworks, financial services rules, healthcare rules). Additional criteria:
- Has the candidate worked on plugins subject to the same or comparable regulations?
- Can the candidate describe how their development process accommodates compliance requirements?
- Does the candidate’s standard documentation include the artifacts compliance audits require?
Red flags that signal a poor match
The qualification criteria identify good fits. The red flags below identify likely poor fits. Any of these is worth probing; multiple of them together usually indicate that the candidate is not the right choice regardless of price.
Communication that becomes vague when specific questions are asked. The candidate may be uncomfortable with the topic, may not have a real answer, or may be overstating their experience. Repeat the question more directly; if vagueness persists, treat the area as unknown rather than confirmed.
Pricing that is substantially below the next-lowest quote. Either the candidate has a margin model you do not understand (possible) or they have under-scoped (more likely). The risk of accepting a substantially low quote is that the candidate either delivers poorly to meet the price or returns mid-project asking for more budget.
Refusal to provide references. The most reliable signal of how an engagement will run is conversations with previous clients. A candidate who cannot or will not provide references is asking you to commit without the evidence that protects you.
Proposals that read like generic marketing copy without specific reference to your project. Either the candidate has not actually read your brief, or they apply a one-size-fits-all approach regardless of context.
Promises that go beyond what is reasonable. A guarantee of zero defects, a commitment to a timeline that seems half what other candidates propose, an offer to absorb scope changes at no charge. These promises are either unrealistic (and the candidate will struggle to deliver) or qualified by fine print that will surface later.
Resistance to written contracts and terms. Some candidates prefer informal arrangements because they reduce friction in the short term. Informal arrangements are also where disputes are hardest to resolve later. A written contract protects both sides.
Reluctance to deliver source code progressively. The candidate may prefer to hold source code as commercial leverage. Insist on progressive delivery; this is a standard request, and resistance is itself a signal.
Inability to describe past failures. Every candidate has had projects that did not go as planned. A candidate who cannot describe one, or whose description is implausibly positive, is either inexperienced or being dishonest about their experience.
Confirming the decision with a small engagement
For high-value engagements, a small initial engagement before committing to the full project is sometimes worthwhile. The small engagement might be a paid discovery sprint, a proof of concept on the most uncertain area, or a small initial deliverable that tests the working relationship.
The advantage is real evidence: how the candidate actually delivers, communicates, and handles issues over a few weeks of real work. The disadvantage is cost and time: the small engagement is an investment, and it may delay the main project.
The cost-benefit makes sense when the main project is large (a few weeks of discovery is a small fraction of a six-month build), when the candidate is unfamiliar (no prior relationship or strong references), or when the project has high uncertainty (the right architecture or approach is genuinely unclear). For smaller or more straightforward projects, the qualification process described above is usually sufficient.
Maintenance reminder: the hiring decision is the start, not the end
The qualification process produces a hiring decision. The decision is the start of the engagement, not the end of the work. Several practices in the engagement’s early weeks confirm that the choice was right and let the buyer course-correct if it was not.
Run the kickoff carefully. The kickoff sets the working pattern: how the team communicates, how status is reported, how decisions are made, how concerns are surfaced. A well-run kickoff produces a strong engagement; a poorly-run kickoff produces drift that is hard to recover later.
Hold the first status review on schedule, even if there is little to report. Establishing the cadence early prevents the meeting from becoming optional.
Submit the first change order through the formal process, even if it is small. The process is more important to install than to use; running it once on a real item establishes that it exists.
Provide feedback on the first deliverable promptly and explicitly. The pattern of how feedback is given and received sets the tone for the engagement.
Hold an explicit thirty-day review. Is the engagement matching the expectations the qualification process set? If yes, continue with confidence. If no, surface the gap directly and decide what to do about it. Engagements that drift are much harder to recover than engagements where concerns are raised early.
The hiring checklist is one tool among many. The engagement itself is the longer work. Buyers who use the checklist well, hire the right candidate, and then run the engagement well consistently get better outcomes than buyers who shortcut any of these. The compounding effect of doing each step properly is what produces the difference between an engagement that delivers and one that struggles. The checklist is the first lever; the rest is execution, and the buyer owns most of it.
