Build and deploy a WordPress plugin or theme with an AI coding tool

When a plugin you rely on breaks, is abandoned or does far more than you need, an AI coding tool such as Claude Code can help you write a small one of your own that does exactly your job. The same goes for a child theme that changes a few things about your site's look. This guide takes you from a written brief to a plugin running on your live site: build it on your computer, test it on a staging copy, deploy it through Git on sPremium or as an upload on any plan, and keep it maintained afterwards.

Last reviewed: 19 October 2026, against WordPress 7.1, the current Claude Code release and WP Toolkit on Noiz hosting.

Official Documentation Reference

• WordPress Plugin Handbook: Header requirements: what makes a file a plugin.
• WordPress: Security: sanitising, validating and escaping data, nonces and capability checks.
• WordPress Theme Handbook: Child themes: changing a theme without editing it.
• WP Toolkit (Plesk Customer Guide): Clone and Copy Data.

Before you start

• Claude Code on your computer, in the Manual mode that asks before every edit and command.
• Git on your computer, and a private repository on a Git host such as GitHub or GitLab if you will deploy through Git.
• A staging copy of the site. On sPremium, clone it with the Clone option on the site's card in WP Toolkit. On sLegacy, test on a local copy of WordPress on your computer instead.
• A backup of the live site taken today.

Decide whether you should build it

Build your own when the job is small and clearly yours: a shipping rule for your shop, a field on your booking form, a shortcode that shows your opening hours, a replacement for one function of a large plugin. Keep a maintained plugin when the job touches payments, security, user accounts or a law you must comply with, because those need someone who watches for threats every week. A plugin you build is a plugin you maintain.

Step 1: Write the brief

The quality of the plugin depends on the brief. Write down what it must do, what it must never do, and how you will know it works. For example:

Write a WordPress plugin called "Example Delivery Days" for a WooCommerce
shop. On the checkout page, show a required field "Preferred delivery day"
with the options Tuesday and Thursday. Save the choice on the order and
show it on the admin order screen and in the order emails.

Rules: one plugin folder, main file example-delivery-days.php with a proper
plugin header including Requires at least and Requires PHP. No external
services, no tracking, no database tables of its own. Sanitise every input,
escape every output, check capabilities for anything in the admin, and use
nonces for any form you add. Follow the WordPress coding standards. Add a
readme with what it does and how to remove it. Do not edit WooCommerce or
any other plugin's files.

Done when: a test order on staging shows the chosen day in the admin and in
the customer email, and the plugin deactivates cleanly.

For a child theme, the brief names the parent theme and lists the changes: "Create a child theme of the active theme that changes the header background to our brand colour and hides the author line on posts. No edits to the parent theme."

Step 2: Build it on your computer

1. Make a folder for the plugin and put it under Git: git init.
2. Start Claude Code in that folder and paste the brief.
3. Read each file it proposes before you approve it. Ask questions: "Where do you sanitise the field?" "What happens if WooCommerce is deactivated?"
4. Commit when a step works, so that you can go back to it.

Ask the tool to explain any part you do not understand. If you cannot follow the code at all, ask for a simpler version, or ask someone who can read it to review it before it goes live.

Step 3: Test it on staging

1. Upload the plugin folder to the staging site's wp-content/plugins folder, by SFTP, with the File Manager in Plesk or with Git (Step 4), or zip it and use Plugins > Add New Plugin > Upload Plugin on the staging site.
2. Activate it on staging and run the test you wrote in the brief.
3. Turn on WordPress debugging on staging only, and read the debug log for warnings. The tool can explain each one.
4. Deactivate and delete the plugin once on staging to check it leaves nothing broken behind, then install it again.

Never test a new plugin on the live site first. A fatal error in a plugin can take the whole site down until the plugin is removed.

Step 4: Deploy it

On sPremium, with Git

1. Push the plugin's repository to your private Git host.
2. In Plesk, under the live domain, open Git and click Add Repository. Choose Remote Git repository and paste the repository's SSH address. Add the SSH public key Plesk shows as a read-only deploy key on your Git host.
3. Click Change branch and path and set the deployment path to httpdocs/wp-content/plugins/example-delivery-days (your plugin's folder name in place of the example).
4. Choose Manual deployment for the first release, click Deploy, then activate the plugin in WordPress.
5. For later releases, push to the repository and deploy again. To roll back, deploy the previous commit.

On sPremium you can also deploy to staging first with the same steps, and copy only the plugin's files to the live site with WP Toolkit's Copy Data (Files Only).

On any plan, as an upload

1. Zip the plugin folder (the zip must contain the folder, not just the files).
2. On the live site, go to Plugins > Add New Plugin > Upload Plugin, choose the zip and click Install Now.
3. Click Activate. Run your test once more on the live site.

Step 5: Keep it maintained

• Read the update notes for WordPress, WooCommerce and any plugin yours depends on. When one changes, ask the tool to check your plugin against the change, and test on staging.
• Keep the brief and the repository. They are the plugin's documentation. A new session of the tool can pick up the work from them.
• Remove what you no longer use. An inactive plugin is still code on your server.

Troubleshooting

• The site shows a critical error after activation. Rename the plugin's folder in the File Manager in Plesk or over SFTP to switch it off, then read the error log in Logs under the domain and give the error to the tool.
• The Upload Plugin page says the package could not be installed. The zip contains the files without their folder, or the folder name does not match the main file. Zip the folder itself.
• Git deployment fails. The deploy key is missing on your Git host, or the path is wrong. See How to fix Plesk Git errors when the repository folder is missing.
• The plugin worked on staging but not live. Compare the PHP versions, active plugins and WooCommerce versions of the two sites; WP Toolkit shows them on each card.

Hosting that suits building your own

sPremium is where this workflow works best: Git deployment, WP Toolkit staging and copy, your choice of PHP version and a dedicated PHP pool. Compare the plans. Once your plugin is live, WordPress Care keeps WordPress, its plugins and themes updated, with a restore point before each change; building and changing your own code stays with you or your developer.