How to Build a WordPress Plugin as a Solo Developer

Complete guide to building a WordPress plugin as a solo developer - tech stack, architecture, timeline, and tips.

What You're Building

A WordPress plugin adds functionality to the 40% of websites that run on WordPress. That's not a small market. It's massive. Whether it's an SEO tool, a contact form, a page builder, or a WooCommerce extension, WordPress plugins can generate serious revenue because the user base is enormous and they're used to paying for premium functionality.

I know, I know. PHP. But hear me out. The WordPress plugin ecosystem is one of the most accessible ways to make money as a solo developer. The distribution is built in (WordPress plugin directory), the users already have their credit cards out (they're used to buying plugins), and the competition, while fierce at the top, has plenty of profitable niches if you look carefully.

Difficulty & Timeline

Aspect	Detail
Difficulty	Medium
Time to MVP	4-6 weeks
Ongoing Maintenance	Medium to High
Monetization	Freemium (free + pro version), annual licenses ($49-199/yr)

Recommended Tech Stack

PHP (obviously, it's WordPress), JavaScript for any admin UI interactivity, and React if your plugin has a complex settings page or dashboard. WordPress itself uses React for Gutenberg blocks, so it's a natural fit.

WordPress core sits at version 7.0 (released May 20, 2026), so target that as your "tested up to" headline while keeping a sensible lower bound. The project officially recommends PHP 8.3 or greater with MariaDB 10.6+ or MySQL 8.0+, though it confirms WordPress still runs on PHP 7.4+ (now past end of life). That gap is exactly why backward-compatibility testing matters, which I cover in the pitfalls below.

For development environment, use Local by Flywheel or wp-env (the official Docker-based dev environment). The official package is @wordpress/env, currently at version 11.7.0 with roughly 56,000 weekly downloads on npm, and it spins up a local WordPress install in minutes. Use WP-CLI (currently v2.12.0) for database operations and scaffolding.

If your plugin ships a React-based admin interface, the official build toolchain is @wordpress/scripts, currently at version 32.3.0 with about 127,000 weekly downloads on npm. It requires Node 18.12.0 or newer, so check your Node version before you start (node -v).

For premium plugin licensing and updates, use a service like Freemius or Appsero. Building your own license management system is a waste of time when these services handle everything including payment processing, license validation, and auto-updates. Freemius charges a base of 4.7% plus payment gateway fees, with an additional 2.3% for WordPress products (so plan for roughly 7% all in), no setup or monthly fees, and a $100 minimum payout. Always check current pricing before you commit, because revenue-share tiers change.

By the Numbers (2026)

Tool or fact	Current value	Source
WordPress core	7.0 (released May 20, 2026)	wordpress.org
Recommended PHP	8.3+ (7.4+ still runs, now EOL)	wordpress.org
Recommended database	MariaDB 10.6+ or MySQL 8.0+	wordpress.org
`@wordpress/scripts`	32.3.0, ~127k weekly npm downloads, needs Node 18.12+	npm registry
`@wordpress/env`	11.7.0, ~56k weekly npm downloads	npm registry
WP-CLI	v2.12.0, ~5.1k GitHub stars	GitHub
Plugin Check (PCP)	v2.0.0, 9,000+ active installs	wordpress.org
Freemius fees	4.7% + gateway fees, plus 2.3% for WP products	freemius.com
Initial review wait	around two weeks (record submission volume)	make.wordpress.org

All figures above were checked on 2026-05-30. See the Sources list at the end for direct links.

Step-by-Step Plan

Phase 1: Core Plugin (Week 1-3)

Start with the free version. WordPress plugin development follows a specific structure. Your main plugin file with the header comment, your classes organized by responsibility, hooks and filters to integrate with WordPress core. Follow the WordPress coding standards even if they feel dated. Users (and reviewers) expect it.

Build the minimum viable feature set. One thing, done well. If you're building a caching plugin, get the page caching working perfectly before you think about database caching, object caching, or CDN integration.

Create a clean settings page using the WordPress Settings API. Or if your settings are complex, use React with @wordpress/scripts (currently 32.3.0) to build a modern admin interface. Scaffold it with npx @wordpress/create-block or wire wp-scripts start and wp-scripts build into your package.json. The WordPress Settings API is clunky but works. React is more work upfront but gives you a much better user experience.

Phase 2: Premium Features (Week 3-5)

Decide what goes in free vs. premium. The free version should be genuinely useful on its own, not a crippled demo. Users who love the free version become premium customers. Users who feel tricked by a useless free version leave one-star reviews.

Common freemium splits that work. Give the core feature for free, charge for advanced settings, integrations, priority support, and extended functionality. The free version hooks people in. The premium version removes limitations they've already hit.

Integrate with Freemius or a similar service for license management, payments, and delivering updates. This saves you weeks of building infrastructure that adds zero value to your users.

Phase 3: Submit & Launch (Week 5-6)

Submit to the WordPress.org plugin directory. Before you do, run the official Plugin Check (PCP) tool (currently v2.0.0, 9,000+ active installs). Install it from the directory, then run wp plugin check your-plugin from WP-CLI or use the Tools menu in WP Admin. It runs most of the same checks reviewers use, so clearing its "Plugin repo" category first is the single best way to avoid a bounce. The human review wait is currently around two weeks, since the Plugins Team is handling record submission volume in 2026, so do not plan a launch date that assumes same-week approval. Common rejection reasons include using external CDN resources without disclosure, security issues like missing nonce verification, and not following WordPress coding standards. Read the plugin guidelines carefully before submitting.

Set up your landing page for the premium version. Include demos, feature comparisons (free vs pro), testimonials, and a clear pricing page. Most successful WordPress plugin businesses use simple annual pricing, something like $49/year for a single site, $99 for 5 sites, $199 for unlimited.

Key Features to Build First

The core feature. Whatever problem your plugin solves, nail this first. Everything else is secondary.

Settings page. Users need to configure your plugin. Make it intuitive and well-organized. Group related settings, use clear labels, add helpful descriptions.

Uninstall cleanup. When users deactivate and delete your plugin, clean up your database tables and options. Not doing this is the #1 thing that annoys WordPress users about plugins.

Internationalization. Wrap all user-facing strings in translation functions from the start. It's much harder to add later, and it opens your plugin up to non-English markets which is a huge audience.

Architecture Overview

your-plugin/
  ├── your-plugin.php          (Main file with plugin header)
  ├── includes/
  │   ├── class-main.php       (Core plugin logic)
  │   ├── class-admin.php      (Admin settings, menus)
  │   ├── class-frontend.php   (Public-facing functionality)
  │   └── class-api.php        (REST API endpoints if needed)
  ├── admin/
  │   ├── css/                 (Admin styles)
  │   └── js/                  (Admin scripts, React app)
  ├── public/
  │   ├── css/                 (Frontend styles)
  │   └── js/                  (Frontend scripts)
  ├── languages/               (Translation files)
  └── readme.txt               (WordPress.org listing)

Common Pitfalls

Security shortcuts. WordPress plugin security is serious business. Always use nonces for form submissions, sanitize and escape all data, check user capabilities before performing actions. The WordPress security team actively scans plugins and will remove yours if they find vulnerabilities.

Loading assets everywhere. Don't enqueue your CSS and JavaScript on every admin page. Only load them on pages where your plugin actually runs. Global asset loading slows down the entire WordPress admin and users will notice.

Ignoring backward compatibility. WordPress users run all sorts of PHP versions and WordPress versions. WordPress officially recommends PHP 8.3+ but confirms it still runs on PHP 7.4+, so a large slice of real installs are on older PHP. Test against your declared "Requires PHP" floor and at least the last two major WordPress releases (currently 6.9.x and 7.0). Breaking someone's site because you used PHP 8.2-only syntax when they declared support for 7.4 earns you one-star reviews fast.

Building your own update system. Use Freemius, Appsero, or Easy Digital Downloads. I wasted three weeks building my own license server once. It was buggy, unreliable, and did exactly what Freemius does out of the box.

Not investing in support. WordPress users expect responsive support. A plugin with great features but terrible support will get destroyed in reviews. Budget time for answering support tickets, especially in the first few months.

Timeline Estimate

Phase	Time	What You're Doing
Core plugin	3 weeks	Main feature, settings, WordPress standards
Premium tier	2 weeks	Pro features, licensing, payment integration
Submit & launch	1 week	WordPress.org submission, landing page
Total	4-6 weeks	Free version live, premium available

Is This Worth Building?

If you can stomach PHP and the WordPress ecosystem's quirks, absolutely. The market is massive, users are accustomed to paying for plugins, and the distribution through WordPress.org is free. Many solo developers make $5k-50k/year from a single well-maintained WordPress plugin.

The best strategy is finding a niche that's underserved. Don't build another SEO plugin or page builder. Find a specific industry or workflow that existing plugins serve poorly, and build something focused and excellent for that audience. A plugin that 500 people love and pay for beats one that 50,000 people try and forget.

Common Errors and Fixes

These are the failures that actually stop a first plugin from shipping, grounded in the official WordPress guidelines and the Plugin Check tool.

wp-scripts: command not found or build crashes on an old Node. @wordpress/scripts 32.3.0 requires Node 18.12.0 or newer. Run node -v, and if you are below that, install a current LTS (nvm makes this painless). Then npm install --save-dev @wordpress/scripts and run npx wp-scripts build.

Plugin Check flags "Plugin repo" errors. A plugin must typically pass every check in the "Plugin repo" category to be approved. Run wp plugin check your-plugin and clear those first. Other warnings (accessibility, performance) are advisory and will not block approval on their own, though they are worth fixing.

Submission rejected for contacting external servers. The guidelines state a plugin may not contact external servers without explicit, authorized user consent. If you load fonts, analytics, or a CDN asset, either bundle it locally or add an opt-in. This is one of the most common bounce reasons.

Rejected for missing input sanitization or nonce checks. Plugin Check ships a dedicated nonce-verification check (wp_verify_nonce misuse) and flags unsanitized input. Sanitize on input, escape on output, and verify a nonce on every form handler before you submit.

"Trialware" or crippled-free rejection. The directory does not allow paid functionality that locks core features. Your free version must work on its own. Gate advanced features behind the premium tier through Freemius, not by breaking the base plugin.

Trademark in the slug. You cannot use a trademarked term (for example a well-known brand or "WordPress" / "WooCommerce" as the leading word) as your primary slug. Plugin Check's Plugin Namer tool will warn you before you submit; rename early because the slug is permanent.

Stable Tag set to trunk. Plugin Check stops processing when the readme Stable Tag points at trunk. Set it to a real version number that matches your main plugin file header, and bump both on every release.