| WHAT THIS ARTICLE COVERS — AND HOW IT WILL HELP YOU
This article gives you six diagnostic questions to ask any WordPress development agency before signing a contract. Each question has a specific disqualifying answer pattern that signals a sales-first operation rather than a development-first one. You will come away knowing: • The six questions that reveal operational discipline, not just past outcomes |
Choosing a WordPress development partner should be straightforward.
Review their portfolio. Check their testimonials. Take a look at a few websites they’ve built. Then make a decision.
The problem is that none of those things tell you how an agency actually works.
A polished portfolio doesn’t tell you whether they’ll overload your site with plugins to save development time. A strong sales presentation doesn’t tell you who will be writing the code. And a list of client logos certainly doesn’t tell you what happens after launch when updates, maintenance, and unexpected issues start appearing.
That’s why so many businesses end up disappointed with a development partner that looked like the right choice on paper.
The gap isn’t usually design quality or technical capability. It’s operational discipline: the processes, standards, and development practices that determine whether a website remains stable, secure, and maintainable long after launch.
The six questions below are designed to uncover that discipline. Each one targets a specific aspect of how an agency builds, reviews, maintains, and supports WordPress websites. More importantly, each has a disqualifying answer pattern that can help you identify an agency that sells well but delivers inconsistently.
Whether you’re evaluating agencies for the first time or reassessing a partner that isn’t meeting expectations, these questions will help you look beyond the pitch and understand how the work actually gets done.
Need a WordPress Partner You Can Actually Trust?
See how our development process is built around code quality, transparency, and long-term maintainability—not just launching websites.
- Custom WordPress Development
- Peer-Reviewed Code
- Dedicated In-house Team
- Ongoing Maintenance & Support
Q1 — “What’s Your Plugin-to-Custom-Code Ratio, and How Do You Decide?”
Every WordPress agency reaches for plugins. That is not the problem. Plugins are appropriate for a wide range of functionality, and using them well is a legitimate development skill.
The question is whether the agency can articulate its decision logic or whether plugins are the default because they are faster and cheaper, not because they are the right fit for your specific requirement.
As noted in a widely shared LinkedIn analysis of WordPress technical debt, “plugins are technical debt with a UI; each plugin is a dependency with its own update cycle and compatibility surface, and sites with 30+ active plugins accumulate fragility over time, with every update.” A partner who cannot explain their plugin selection discipline is accumulating that fragility on your behalf, and you won’t see it until something breaks.
The plugin-to-custom-code ratio question is not about preferring one approach. It is about whether the agency makes deliberate choices or default ones.
The Disqualifying Answer
“We prefer plugins where possible — it keeps costs down and makes maintenance easier.” This answer reveals that plugins are the default, not the result of requirement analysis. It signals that your budget is being optimised at the cost of your site’s long-term resilience.
What a Real Answer Sounds Like
A capable agency describes specific criteria: whether the plugin is actively maintained, whether it adds unnecessary bloat for the specific requirement, whether the use case warrants the ongoing dependency, and what they would build custom when a plugin does not serve the actual need.
They should give you a concrete example of each direction: one case where they chose a plugin and one where they wrote custom code, with reasons for both.
Q2 — “Walk Me Through Your Post-Launch Maintenance Discipline”
The delivery-and-disappear pattern is the most common failure mode in WordPress development. An agency delivers the project, hands over credentials, and moves to the next client.
This question surfaces whether the agency treats launch as the end of the job or the beginning of the relationship.
Post-launch maintenance discipline is the difference between a partner and a vendor. One has a stake in what happens next.
The Disqualifying Answer
“We offer maintenance retainers if you need them” presented as an optional add-on with no specifics about what it covers tells you launch is the finish line. A related disqualifying pattern: a maintenance plan described only in hours per month, with no explanation of what those hours address or how priorities are set.
What a Real Answer Sounds Like
The agency describes a specific post-launch protocol: how plugin updates are sequenced, what gets tested before and after, how they monitor for regressions, and what the escalation path looks like when something breaks. If they can tell you which plugins in a typical build they consider high-risk for updates, they are operating with real maintenance discipline.
Q3 — “Who Specifically Will Work on My Project? In-house team members or Contractors/Freelancers ?”
This question isn’t about whether the agency introduces every developer before you sign. It’s about whether they’re transparent about how work is staffed, who is accountable, and who ultimately owns delivery.
Many agencies present themselves as a single in-house team but quietly outsource development to freelancers or rotating contractors. There’s nothing inherently wrong with using contractors. The problem is when clients aren’t told who is actually building their website or who is responsible if something goes wrong.
This question helps you understand the agency’s delivery model, accountability structure, and whether there is clear ownership throughout the project.
The Disqualifying Answer
“We have a great team that handles everything.”
If the answer stays at that level, without explaining whether the work is done by employees or contractors, who manages the project, who reviews the code, or how accountability is maintained, you’re learning very little about how the agency actually operates.
What a Real Answer Sounds Like
A confident agency explains:
- whether development is handled by in-house staff, contractors, or a combination of both
- who will oversee the project from start to finish
- how developers are assigned
- who performs code reviews and quality assurance
- when you’ll be introduced to the people working on your project
They should be clear about their staffing model and accountability, even if individual developer assignments happen after the engagement begins.
You can also explore what a direct engagement looks like. Hiring WordPress developers on retainer gives you named accountability from the outset.
What a full WordPress development services engagement includes — and who delivers it — should be answerable in concrete terms before you sign.
Need a WordPress Partner You Can Actually Trust?
See how our development process is built around code quality, transparency, and long-term maintainability—not just launching websites.
- Custom WordPress Development
- Peer-Reviewed Code
- Dedicated In-house Team
- Ongoing Maintenance & Support
Q4 — “Can You Show Me a Plugin You’ve Shipped Publicly?”
This is the most diagnostic question on the list. A plugin published on the WordPress.org repository or the WooCommerce marketplace is peer-reviewed, maintained, and documented code that anyone can read and install. It is not a portfolio site that you can only judge by looking at it.
Publicly shipped plugins demonstrate three things simultaneously: that the agency can write code to open-source standards, that they understand the responsibility of maintaining public software, and that they have been through a review process they did not control.
An agency that cannot point to a publicly shipped plugin has never had their code reviewed by anyone outside a client relationship.
The Disqualifying Answer
“We focus on client work rather than our own products” or a pivot to showing you private client repositories. A client repository that you cannot access, cannot verify, and was never reviewed externally tells you nothing about code quality that the portfolio does not already tell you.
What a Real Answer Sounds Like
They point you directly to a specific plugin — ideally more than one — with installation counts, update history, and support thread handling visible. A plugin that has been actively maintained for two or more years tells you something significant about the agency’s operational discipline over time, not just at delivery.
If you want to see what plugin development capability looks like as a documented engagement, our WordPress development services page covers the full scope of what this kind of work actually involves.
Q5 — “Describe Your Code Review Process. Who Reviews Before It Goes Live?”
Code review discipline is the strongest signal of whether an agency operates like an engineering firm or like individual contributors who happen to share a project management tool.
As Codeable’s developer vetting framework documents, “partners who FTP directly to production are a liability.” Git with visible commit history and branching strategy is the professional baseline. Agencies operating below that baseline are demonstrating how they work before you need to ask.
According to security research cited in that same framework, 94% of WordPress security vulnerabilities originate in poorly coded plugins and themes — making code review not just a quality practice, but a security one.(Source: Codeable)
The Disqualifying Answer
“Everyone checks their own work before pushing” or “we have a QA process that catches issues before launch.” Both answers describe testing, not code review. Testing and code review are different disciplines. The disqualifying pattern is when an agency presents a QA checklist as a substitute for a second developer reading the code before it ships.
What a Real Answer Sounds Like
The agency describes a specific workflow: feature branches, pull requests, a second developer reviewing before merge, and what happens when a review catches something. They should name whether the reviewer is a peer or a senior developer, and they should give you an example of something that was caught in review before it reached the client.
Q6 — “If We Needed to Transition to a Different Partner, How Would That Work?”
A confident partner answers this question easily. A partner building dependency rather than capability deflects it.
This question is not about planning to leave. It is about testing whether the agency operates in a way that makes leaving possible. An agency that documents well, uses standard version control, keeps credentials in order, and hands over cleanly is one that trusts its own work.
The Disqualifying Answer
“Let’s focus on getting started first,” or any reframe that treats exit planning as a sign of bad faith. Avoidance is itself the disqualifying answer. A related pattern: “you’ll own everything” delivered with no specifics about documentation, credential structure, or transition support.
What a Real Answer Sounds Like
As White Label Coders documents in their WordPress technical debt audit framework, the most damaging handover situations occur when sites rely on custom features built by developers who are no longer available, leaving business owners unable to update WordPress or plugins without risking functionality breaks.
A real answer describes the documentation delivered at project close, how credentials are structured so you are not dependent on the agency for access, and what a transition support window looks like.
The agency that answers this question confidently is the one least likely to create the situation that makes the question necessary.
Need a WordPress Partner You Can Actually Trust?
See how our development process is built around code quality, transparency, and long-term maintainability—not just launching websites.
- Custom WordPress Development
- Peer-Reviewed Code
- Dedicated In-house Team
- Ongoing Maintenance & Support
| How We at WisdmLabs Would Answer These Six Questions
One structural advantage of publishing a piece like this is that it commits you to honesty. So here, in the same format, are our own answers. Q1 — Plugin-to-custom-code ratio: We assess each requirement individually. If a plugin covers 95% or more of the need and the remaining gap can be handled with hooks and filters, we use it. If the requirement needs precise control, carries significant performance implications, or introduces a dependency we would not want to maintain long-term, we build custom. We can give you specific examples from active client work of both calls and why we made them. Q2 — Post-launch maintenance discipline: We do not treat delivery as the finish line. Retainer clients have scheduled update cycles with staging verification rather than live-site bulk updates. For project-based work, we have a defined post-launch support window with a clear escalation path. We know which plugins in a typical build carry the highest update risk and we plan the maintenance sequence accordingly. Q3 — Team structure: Our development work is delivered by staff, not contractors. We believe in being transparent about how projects are staffed, who is accountable for delivery, and how every change is reviewed before deployment. Once your project is underway, you’ll be introduced to your assigned developer and project lead. Q4 — Publicly shipped plugins: Yes. Our WooCommerce plugin suite (Product Enquiry Pro, Customer Specific Pricing, Custom Product Boxes, and Sales Booster Pack) is publicly available, actively maintained, and has been through marketplace review processes outside our control. You can read the code, read the support threads, and judge the maintenance history directly. Q5 — Code review process: We use Git with feature branching. All code goes through peer review before staging. A second developer reviews before merge. This is not a recent addition; it is the standard we have maintained throughout our build process. Q6 — Transition planning: We document as we build. Project close includes a handover package covering code documentation, a credentials checklist, and a 30-day transition support window. You own all code. We publish this section not because we think we are the only agency capable of answering these questions honestly. We publish it because you should ask every agency these questions — including us — and compare the answers side by side. A team culture that supports these standards is also visible in how we approach client work. |
Quick Assessment — How Does Your Prospective Partner Score?
Answer three questions based on conversations you have had — or plan to have before signing.
| Q1: When you asked about their plugin-to-custom-code decision process, they:
A) Said something like “we prefer plugins where possible — it’s faster and cheaper” (1 point) B) Explained their decision factors, but could not give a specific example of going either direction (2 points) C) Gave a specific example of a use case where they chose a plugin and one where they wrote custom code, with reasons for both (3 points) |
| Q2: When you asked how they ensure projects stay on track, they:
A) Focused on timelines and deliverables without explaining how work is managed. (1 point) B) Explained parts of their project management process but left gaps around reviews or accountability. (2 points) C) Clearly explained how work is managed, reviewed, communicated, and tracked from kickoff to launch. (3 points) |
| Q3: When you asked how a transition to a different partner would work, they:
A) Changed the subject or said it was premature to think about (1 point) B) Said you would own the code, but provided no specifics about documentation or handover process (2 points) C) Described a documented handover process: code documentation, credentials checklist, and a transition support window (3 points) |
Your Result
🟢 5–6 Points: Strong Evaluation Process
You’re looking beyond portfolios and asking the questions that reveal how an agency actually works.
Next step: Compare agencies based on their processes, communication, and post-launch support—not just price or timelines.
🟠 3–4 Points: Some Important Gaps Remain
You have a good starting point, but there are still areas where an agency’s working practices aren’t fully clear.
Next step: Revisit the questions where you answered “No” and ask for specific examples of how the agency handles those situations.
🔴 0–2 Points: You’re Still Evaluating on Trust
At this stage, you’re relying more on sales conversations than evidence of how the agency delivers work.
Next step: Schedule a free consultation with our team. We’ll help you evaluate your shortlisted agencies, understand the answers that matter most, and spot potential red flags before you commit.
FAQ
What questions should I ask before hiring a WordPress development agency?
Beyond portfolio and references, focus on operational questions: how they decide between plugin and custom code, who specifically will work on your project, what their code review process looks like, whether they can show you a publicly shipped plugin, how post-launch maintenance works, and what a transition to a different partner would involve. These reveal operational discipline rather than just past outcomes.
What is the difference between a WordPress development agency and a freelancer?
An agency brings multi-disciplinary coverage — project management, development, QA — and typically offers continuity if a specific individual leaves. A freelancer offers direct access to the person writing the code and often faster feedback loops, but no built-in redundancy. The evaluation framework in this article applies to both models. The disqualifying answers are the same whether you are talking to an agency or an individual.
What should a proper handover from a WordPress development agency include?
At minimum: all source code in a version-controlled repository you have access to, complete credentials documentation covering every service and account used in the build, documentation of any custom code or non-standard approaches, and a transition support window where the agency answers questions from an incoming partner. If any of these elements are absent from the handover proposal, ask about them before the engagement ends, not after.
How do I know if my current WordPress development partner is underperforming?
Apply the same six questions to your current arrangement. If your partner cannot explain their plugin selection logic, if you do not know who reviews the code, if you have never received a clear answer about what would happen if you needed to transition — those are the same signals applied retrospectively.
Conclusion
The biggest risk when choosing a WordPress development agency isn’t making the wrong choice on purpose.
It’s choosing a partner based on what you can see—a portfolio, a proposal, a sales presentation—while missing the processes, standards, and working practices that determine whether the project succeeds after launch.
That’s what these six questions are designed to uncover.
Before you sign a contract with any agency, ask all six. Pay close attention to the answers, and even more attention to how confidently they’re explained. The agencies worth trusting will have clear processes, real examples, and no hesitation discussing how they work.
If you’re currently evaluating agencies and want a second opinion, let’s talk.
We’ll walk through your shortlist with you, explain what strong answers look like, highlight any red flags we see, and help you make a more informed decision—even if you don’t end up working with us.
