Disclosure: This article is sponsored by WellPlayedWP, the WordPress plugin library I build. That relationship is relevant here, so I’m putting it up front. The point is not that buying is always better. It isn’t.
AI made the first version cheaper. It did not make the tenth version free.
That is the part I think gets lost when people ask whether they should buy a WordPress plugin or vibe-code their own. With a capable coding assistant, a rough feature can appear in an afternoon. You describe what you want, test a few rounds, fix the obvious problems, and suddenly you have a plugin that seems to work.
Sometimes that is exactly the right move. Sometimes it is the beginning of a maintenance job you did not mean to take on.
The useful question is not, “Can AI build this?” It probably can. The question is, “Do I want to own everything that happens after it builds this?”
Buy when the problem is common and the stakes are not small
A good commercial plugin is not valuable because its developer typed the code before you did. Its value is in the boring accumulation around that code: support tickets, compatibility fixes, edge cases, migrations, documentation, security work, and the thousands of real sites that have already found the sharp corners.
I lean toward buying when the feature touches money, accounts, permissions, personal data, email delivery, subscriptions, checkout, or anything else where a quiet failure becomes an expensive one. I also buy when the feature needs to work across multiple client sites, survive frequent changes in WordPress or WooCommerce, or be handed to someone who expects a support path that does not begin with calling me.
If a maintained plugin already covers 80 or 90 percent of the need, I am careful about rejecting it because the last 10 percent feels custom. That gap may be easier to solve with a small extension than by rebuilding the whole product and inheriting every problem it already solved.
Build when the gap is narrow and you understand it
There are plenty of good reasons to vibe-code a plugin. Maybe the workflow is specific to your business. Maybe the existing options bring ten screens of settings to solve one small problem. Maybe you need a temporary bridge between two systems, an internal admin tool, or a focused feature with a limited blast radius.
That is where custom code can be wonderful. You can name things the way your team names them, remove every option you do not need, and make the workflow fit the site instead of making the site fit a product.
I am most comfortable building when I can explain the full feature in a few sentences, identify exactly where its data lives, test the important failure paths, and remove it without taking the rest of the site down. The code should be small enough that I can still understand it after the excitement of making it has worn off.
Vibe-coding changes speed, not ownership
“Vibe-coding” is useful shorthand for building software conversationally with AI, often by describing the outcome and iterating on what appears. It lowers the cost of getting started. It can also hide how many decisions are being made on your behalf.
The first demo rarely tells you whether capabilities are checked correctly, form requests are protected, inputs are validated, output is escaped, database changes can be upgraded safely, background work is bounded, or uninstalling leaves the site clean. It does not tell you how the plugin behaves with caching, multilingual content, accessibility tools, a different theme, a future PHP version, or the next major WordPress release.
AI can help with every one of those things. I use it for that. But someone still has to ask the questions, recognize a weak answer, test the result, and return when the environment changes. If that person is you, the plugin was not free. You paid with ownership.
Run the cost math honestly
A $49 or $199 plugin can feel expensive next to a prompt box. That comparison only works if your time has no value and the custom version never needs another hour.
I try to price both choices over a year, not an afternoon. For the commercial plugin, that means the license, renewal, onboarding, and any compromises required to work its way. For the custom plugin, that means discovery, prompting, review, testing, deployment, documentation, bug fixes, compatibility work, and the interruption cost every time it needs attention.
Buying is not automatically safer. A poorly maintained plugin with vague ownership, weak support, or far more access than it needs can be a worse choice than a small custom build. I still check the changelog, support history, update cadence, documentation, data handling, and whether I can leave without losing access to my own content.
Before choosing, I ask:
- Does this touch payments, logins, permissions, private data, or business-critical workflows?
- How many sites will depend on it?
- How often do the systems around it change?
- Who will diagnose it when it breaks six months from now?
- Can I replace or remove it without a rescue project?
- Is the custom part truly the product, or is it just glue?
The best answer is often hybrid
My favorite pattern is to buy the foundation and vibe-code the edge.
Use the established product for the difficult, repeatable machinery. Then write a small plugin that changes a label, adds a report, connects one event to another, or shapes the workflow around the business. The maintained plugin keeps absorbing ecosystem changes. Your custom layer stays narrow enough to reason about.
This also gives AI a better assignment. “Build an entire membership platform” is a large, slippery request. “Add one capability-protected admin action that exports these fields from this established plugin” is specific, testable, and much easier to maintain.
Before you ship the custom plugin
If custom code wins, I want a few things in place before I trust it:
- A written scope, including what the plugin deliberately does not do.
- A clean off-switch and an understood uninstall path.
- Capability checks, request protection, input validation, sanitization, and output escaping.
- Staging tests for the real workflow, including failure and rollback.
- Basic documentation for the next person, even if the next person is future me.
- A named owner for updates when WordPress, PHP, WooCommerce, or a connected service changes.
If that list feels excessive for the feature, buying the maintained version may already be the answer.
My rule is simple
If the problem is common, the failure is expensive, and a trustworthy plugin already solves it, I buy the plugin.
If the need is narrow, specific, reversible, and small enough for me to understand and maintain, I build it.
If the answer is somewhere in between, I buy the foundation and build the last mile.
That is also the thinking behind WellPlayedWP: practical plugins for recurring WordPress jobs, packaged with updates and support so every site owner does not have to reinvent the same wheel. If something in the library solves your problem, use the maintained version. If it does not, a focused custom plugin may be the more honest answer.
The goal is not to buy more software or generate more code. It is to choose the kind of responsibility you actually want.
