The ability library or MCP plugin you built in Courses 2 and 8 works. You know how it’s configured, what its edge cases are, and what to do when something goes wrong, because you wrote it and you’ve been running it. None of that knowledge exists for the person who finds your plugin on WordPress.org next week, has never seen an ability or an MCP server before, and expects it to either work immediately or tell them clearly why it doesn’t. That gap, between “it works for me” and “a stranger can install, configure, and trust it,” is the entire subject of this lesson, and it’s usually bigger than developers expect.
This lesson assumes a plugin that already passes your own testing, the CI pipeline from
Course 8’s ci-cd-pipelines-for-mcp-plugins lesson is a reasonable bar. It doesn’t
assume you’ve decided on pricing or licensing yet, those come next.
Step 1: “Works for me” versus “works for a stranger”
Your own installation has advantages a customer’s won’t: you know your API keys are
valid, you know which WordPress version and PHP version you’re running, you know what
wp_register_ability() calls the plugin makes and roughly what they cost in API calls,
and if something breaks you can read the code. A stranger installing your plugin has
none of that. They have a plugins page, an activation button, and whatever your
onboarding screen shows them in the first thirty seconds.
| Dimension | Works for you | Sellable |
|---|---|---|
| Configuration | Hardcoded or set once, from memory | A settings screen with validation, defaults, and inline help |
| Error handling | You read the PHP error log | Errors surface as plain-language admin notices with a next step |
| API key setup | You know where to get one | The setup flow links directly to the provider’s key page and validates the key before saving |
| Failure recovery | You debug it yourself | A documented troubleshooting path exists before the customer ever emails you |
| Trust signals | Irrelevant, it’s your own site | A readme, a changelog, a support channel, and a privacy-and-data-use statement all visible before purchase or install |
Step 2: Onboarding is the first thing that has to work perfectly
A first-time user who hits a confusing setup screen doesn’t file a detailed bug report, they uninstall and leave a review. The onboarding flow for an AI feature specifically has to handle a few things your local dev environment let you skip entirely.
Ask a developer friend, or use a genuinely fresh local environment with no prior config, to install your plugin with zero guidance from you. Watch where they get stuck. Every stuck point is either a documentation gap or a UI gap, and it’s far cheaper to find those before launch than to learn them from support tickets.
Step 3: Documentation is a support-cost reduction tool, not a formality
For a typical CRUD plugin, documentation is nice to have. For an AI feature, it’s closer to required, because AI features fail in ways a customer can’t self-diagnose from the UI alone: a provider outage looks identical to a bug, a rate limit looks identical to a broken feature, and a model returning an unhelpful answer looks like the plugin is “wrong” even when it executed exactly as designed. Good documentation answers these before the customer opens a ticket:
Step 4: Set support expectations you can actually keep
A solo developer or a two-person team cannot promise 24/7 support, and pretending otherwise in your marketing sets up a review that says “no response in three days.” Say what’s true: a support forum with a stated typical response window, a paid tier with a faster or more direct channel, and clear boundaries around what’s supported (the current version, current WordPress and PHP releases) versus what isn’t. Customers tolerate honest limits far better than broken promises, and an honest support policy also protects you from the specific complaint reviewers watch for on WordPress.org: unresponsive developers on a plugin that claims active support.
It’s tempting to keep adding abilities and features when a product isn’t selling. Often the actual blocker is earlier: a setup flow that confuses a non-technical site owner in the first two minutes. Before adding scope, watch someone unfamiliar with your plugin try to install it, and fix what you see.
Recap
A working plugin and a sellable product differ in configuration, error handling, documentation, and support, not in feature count. Onboarding has to work for someone who has never seen an ability or MCP server before, documentation has to answer the specific ways an AI feature fails (which don’t look like typical bugs), and support commitments need to be honest about what a small team can actually deliver. Get this right before you touch pricing or licensing, since a product nobody can successfully install won’t be helped by either.
Resources & further reading
- WordPress Plugin Handbook: Plugin readme.txt, developer.wordpress.org
- Plugin Developer FAQ, developer.wordpress.org