Why a WordPress Plugin Is a Good Build to Do With Claude Code
A WordPress plugin is a small amount of code that plugs into a large amount of existing application. The login system, the database layer, the admin interface, the user roles, the media handling and the front-end theme are already there and already work. Your plugin adds one behaviour on top. That is a genuinely small surface, which is exactly the shape of build an agent handles well.
It is also a build with a real audience attached. An enormous share of the small-business web runs on WordPress, which means a plugin that solves one specific annoyance has customers who already have the platform installed. Compared with a standalone app where you have to persuade someone to sign up for anything at all, the distance between a working plugin and someone actually using it is short.
Answer These Four Questions Before You Prompt
The quality of the plugin is decided before you type anything into Claude Code. Four answers, written down, in plain language. If you cannot answer one of them, that is the part of the idea that is not finished yet, and the agent will paper over it with a guess.
- What does it do, in one sentence, with no and in it. Adds a delivery-date field to the checkout is a plugin. Adds a delivery-date field and emails the driver and shows a dashboard is three plugins in a coat.
- Where does it appear? WordPress has distinct surfaces and they are built completely differently. An admin settings page, a block in the editor, a shortcode in a post, a widget, a change to the front-end output, or something with no interface at all that just runs on a schedule. Name the one you want.
- What does it store, and where? Nothing at all, a handful of settings in the options table, extra fields attached to posts, or its own database table. These are four different builds, and the agent will default to the most complicated one if you leave it open.
- Who can use it? Every admin, only the site owner, logged-in users, or the public. WordPress has a capability system for exactly this, and an agent that was not told will frequently write an endpoint anyone on the internet can call.
Write those four answers into a short brief and hand it over as the opening message rather than describing the plugin conversationally. This is the same discipline as any other build, and we go deeper on it in [how to write a project brief for Claude Code](/blog/how-to-write-a-project-brief-for-claude-code). On WordPress it matters more than usual because the platform has so many valid places to put the same feature.
The Build Order That Works
Build in the order that gets something visible on the screen fastest, then add behaviour to a thing that already exists. Trying to get the whole plugin right in one prompt produces a large amount of code you cannot check.
- Get an empty plugin to activate. A single main file with the plugin header comment, nothing else. Drop it in, activate it, confirm WordPress shows it in the plugin list with no errors. This takes two minutes and it proves your local setup works before any real code exists.
- Add the surface with nothing behind it. The settings page that renders one heading, or the shortcode that outputs the word working. See it appear in the right place in the admin or on the page. Now you know your hooks are registered correctly.
- Add the storage. Save one setting, reload the page, confirm the value came back. Persistence is where most plugin bugs live and it is far easier to prove with one field than with twelve.
- Add the actual behaviour. Now that the plumbing is verified, the interesting part is a small change to a thing that already works, which is the cheapest possible place to be wrong.
- Add the guards. Capability checks, input sanitising, output escaping, and a check that the plugin degrades sensibly if something it depends on is missing.
Tell Claude Code your WordPress version and whether the site uses a block theme or a classic theme in the first message. The correct way to add a feature has changed significantly between those two worlds, and an agent guessing will sometimes hand you the approach that was right several years ago.
The Four WordPress Traps to Review For Every Time
These are not AI mistakes. They are WordPress mistakes that agents make because a plugin is written as though it is the only code on the site, when in reality it is sharing one PHP process with a theme and thirty other plugins.
What to check before a plugin goes anywhere near a real site
| Trap | What goes wrong | What to check |
|---|---|---|
| Unprefixed names | Two plugins define a function with the same name and the site fatals | Every function, class, option name and database table starts with a prefix unique to your plugin |
| Missing capability checks | Any logged-in user, or anyone at all, can trigger an admin action | Every admin action and endpoint verifies the current user is allowed to do it, on the server |
| Unsanitised input and unescaped output | User input reaches the database or the page unfiltered | Everything coming in is sanitised on the way in, everything going out is escaped on the way out, with no exceptions |
| Assuming a clean environment | The plugin breaks when a dependency is missing or the site is multisite | It checks what it needs exists and fails with a clear message rather than a fatal error |
Run that review as a separate task in a fresh session rather than as the last line of the build prompt. An agent that has spent an hour building something is a poor judge of it; a clean session reading the code cold behaves like a different reviewer. Ask it to list every place user input enters and every action that changes data, with line numbers, and state which check guards each one. A list with line numbers is checkable, a paragraph saying the security looks fine is not.
Turning the Plugin Into Something People Install
A plugin that works on your machine is about seventy percent of the job. The last stretch is the part that decides whether anyone else ever runs it.
- A readme that says what it does in the first sentence and what it does not do in the second. The second sentence prevents most bad reviews.
- Sensible defaults, so it does something useful the moment it is activated without a settings tour.
- Clean uninstall. Remove your options and tables when the plugin is deleted, unless the user has asked you to keep the data.
- A version number and a changelog, because the first support question you get will be which version are you on.
- One screenshot of the thing actually working. It converts better than any description of it.
This is also where a plugin becomes a paid product rather than a favour. A narrow plugin that removes a specific recurring annoyance for a specific kind of site is one of the more straightforward things to sell, because the buyer can evaluate it in about a minute. If you are building for a client rather than for a marketplace, the handover matters as much as the code, which we cover in [how to hand off a Claude Code project](/blog/how-to-hand-off-a-claude-code-project).
What Not to Build First
Three categories are much harder than they look and make poor first plugins, regardless of how capable the agent is.
- Anything that touches payments or checkout on a live store. The cost of a subtle bug is somebody's real money and the testing burden is enormous. Build your second plugin here, not your first.
- Anything that has to work across every theme. Front-end output that must look right on any theme anyone might install is a support commitment, not a feature. Admin-side plugins avoid this entirely.
- Anything that duplicates a core WordPress capability. If the platform already has a way to do it, your version has to be better than a thing thousands of people have maintained for years, and it usually is not.
The best first plugin is boring, admin-side, and scratches an itch you personally have on a site you personally run. You get a real user with real feedback on day one, and that user is you, which makes the feedback loop about as short as it can get.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
Can Claude Code build a WordPress plugin from scratch?
Yes, and it is a good fit because WordPress supplies most of the application already and the plugin is a small piece of code on top. What the agent will not do reliably on its own is add the capability checks, prefixing and input sanitising that WordPress specifically requires, because those are conventions of the platform rather than obvious parts of the request. Build with the agent, then review for those four things.
Do I need to know PHP to build a WordPress plugin with Claude Code?
Not to get a working plugin, but you do need to be able to read what came back well enough to spot when a function is missing a permission check or a value is going into the database unfiltered. You do not have to be able to write it from memory. Reading is a much lower bar than writing and it is the bar that actually matters here.
Should I test a new plugin on my live site?
No. Use a local WordPress install or a staging copy, because an agent will occasionally produce a fatal PHP error and on a live site that is a blank page for your visitors until you find the line. Locally the same mistake costs you a few seconds and nobody else sees it.
How long does it take to build a simple WordPress plugin?
A narrow admin-side plugin with one settings screen and one behaviour is realistically an afternoon, most of which is the reviewing and testing rather than the writing. Anything that touches the front end across multiple themes, or that handles payments, is a much larger commitment and should not be your first one.
Can I sell a plugin I built with Claude Code?
Yes, and a narrow plugin that removes one specific recurring annoyance is one of the easier things to sell because a buyer can evaluate it in about a minute. What decides whether it sells is not how it was written but whether the problem is real and specific enough that someone was already looking for a solution to it.
Last reviewed by David Iya on August 19, 2026
