How to Hire a WordPress Plugin Developer: What to Ask Before You Pay

Before you hire a WordPress plugin developer, look at their public work on wordpress.org. A plugin listing shows active installs, ratings, support threads and the update history, and none of it can be edited to look better than it is. The six questions below, about hooks, code ownership, updates, scope, testing and who writes the code, come after that check, because a developer with a public record has already answered most of them where anyone can see.

Why the wordpress.org check comes first

A services page can say anything. A wordpress.org listing cannot. It shows when the plugin was first published, when it was last updated, how many sites run it, what users say in reviews, and whether the developer answers support threads or leaves them open for months. If a developer has no public plugin, that is not disqualifying, but it means you have to verify everything else by asking harder questions and checking references. If they do have one, spend ten minutes on it. Open the support forum. Read the two-star reviews. Look at the changelog and count how many releases came shortly after major WordPress versions.

We keep ours public for exactly this reason. WP Responsive Menu has been listed since March 2014 and runs on more than 30,000 active sites. RestroPress has been listed since September 2018 and has passed 160,000 downloads. Both are still updated and tested up to WordPress 7.1. You can read the support threads for either and judge for yourself how we handle problems. Our plugin development service runs on the same habits.

Question 1: will you edit core, the theme, or another plugin's files?

The only acceptable answer is no. WordPress exposes actions and filters, and WooCommerce exposes thousands more, so that custom behavior can be attached without touching files that get overwritten on update. A developer who edits wp-includes, patches a third-party plugin, or drops a few hundred lines into the theme's functions.php is building something that breaks the next time WordPress or that plugin updates, which is weekly for plugins and several times a year for core. A large share of the sites that reach our site rescue queue arrive in that state.

Ask them to describe how they would add a field to the WooCommerce checkout, or change how a product is priced, and listen for the word "hook". If they cannot name one, or the first move they describe is copying a template into the theme, keep looking.

Question 2: who owns the code when it is done?

You should, outright, and it should say so in writing before any money moves. Some developers keep ownership of the plugin and license it back to you, which means you cannot take it to another developer, cannot sell the business with it included, and depend on them for every change. Others deliver a plugin whose license check calls home to their own server. Ask for the exact wording: the client owns all code, the repository and the documentation on final payment. Ask where the repository lives and whether you have admin access to it from day one, not at handover.

Question 3: what happens when WordPress or PHP updates?

Ask what their process is, not whether they have one. Hosts force PHP upgrades when a version reaches end of life, and each PHP major release has removed functions and changed behavior that older plugin code depended on. WordPress ships several core releases a year and WooCommerce adds its own. A developer who maintains plugins knows this cost and will tell you how they handle it: which PHP versions the plugin is tested on, whether they run it against the WordPress beta before release, and what their support window looks like after handover. A developer who says "it will be fine" has not been through it yet.

A related question: what does the plugin do if a dependency is missing? A WooCommerce extension should check that WooCommerce is active and show a clear admin notice if it is not, rather than throw a fatal error that takes the site down.

Question 4: what does your written scope look like?

Ask to see one from a previous project with the client details removed. A usable scope lists what is included, what is not, what you have to provide (access, content, API credentials, test accounts) and what "done" means for each item. It names the WordPress, WooCommerce and PHP versions the work targets. It says where the code will be built and how you will review it. A scope that fits in one paragraph is a quote, not a scope, and the arguments start when the first change request lands.

Fixed price against a written scope protects both sides. It forces the developer to think before quoting, and it means the price you agreed is the price you pay. Hourly billing has its place for open-ended maintenance. For a plugin with a defined outcome, it moves all of the risk to you.

Question 5: how do you test?

Listen for specifics. A staging site, yes, but also: which PHP versions, whether WP_DEBUG is on during development, whether they test with the other plugins on your site active, and whether they test with realistic data rather than a store of twelve products. For WooCommerce work, ask whether they place test orders through the payment gateway in sandbox mode, and whether they have tested against both the classic checkout and the block checkout. Those are different codebases, and a change that works on one often does nothing on the other, which is why checkout customization is its own discipline. Then ask who reviews the code before you see it. A second senior developer catches the things the author has stopped noticing.

Question 6: who will actually write the code?

At many agencies the person you talk to during sales is not the person who builds the plugin, and the person who builds it may be whoever was free that week. Ask directly. Ask whether the developer who scopes the work will build it, and whether you can talk to them before signing. If the answer is vague, the handoff between salesperson and developer is where your requirements will get lost.

Signals that are less useful than they look

• Portfolio screenshots. They show a design, not code quality, and nothing about what happened after launch.
• Years in business. A company can be old and still ship functions.php hacks.
• Certifications and badges. None of the common ones test whether someone can carry a plugin through three PHP versions.
• A low hourly rate. The cost of a plugin is the cost of owning it. The cheapest build is regularly the most expensive one to keep alive.

A checklist for the first call

1. Send a link to a public plugin, or explain why there is none.
2. Describe how you would add a custom field to the WooCommerce checkout without editing templates.
3. Confirm in writing that the client owns all code and the repository.
4. Show a redacted scope from a previous project.
5. List the PHP and WordPress versions you will test against.
6. Name the developer who will write the code, and say whether they scoped it.
7. State what support looks like after handover, and for how long.

Common questions

Should I hire a freelancer or an agency for a WordPress plugin?

Either can work, and the failure modes differ. A freelancer can disappear, and an agency can hand your project to whoever is free. Put the same six questions to both, and weigh how you get a second reviewer and continuity if the person building it becomes unavailable.

How do I check a developer's wordpress.org plugin?

Open the listing and read four things: the last updated date, the "tested up to" version, the support forum, and the reviews sorted by lowest rating. Then open the changelog and check whether releases followed major WordPress versions. Ten minutes there tells you more than an hour of sales calls.

What if the developer wants to build it inside my theme?

Say no. Functionality that lives in a theme disappears when you change the theme and cannot be reused or tested on its own. A plugin is the correct container for anything that is not presentation.

Is a fixed price realistic for custom plugin work?

Yes, if there is a written scope behind it. The scope is what makes the price fixed. Without one, a fixed price is a guess that will be renegotiated halfway through.

Should the developer give me access to the repository from the start?

Yes. Waiting until handover leaves you with nothing if the relationship ends early, and it means nobody else can review the code while it is being written.

Next step

If you have a plugin in mind, send us the brief. The developer who would build it will reply, and you can put every question above to them directly.