In 2025, security researchers logged 11,334 new vulnerabilities across the WordPress ecosystem.
91% of them were in plugins. WordPress core itself had six.
Sit with that for a second, because it rearranges the whole question. WordPress is not your security problem. Your plugin folder is your security problem. And the average WooCommerce store is running 58 active plugins.
So when someone asks me whether they should build a custom plugin or just buy one off the shelf, the honest answer is that both options carry risk, and the sales pitch you have heard for each one is wrong.
The thing that will surprise you about paid plugins
Everyone assumes the premium plugin is the safe one. You paid for it. There is a company behind it. Somebody is watching.
The data says otherwise. Patchstack’s 2026 report found that premium components had roughly three times more known exploited vulnerabilities than free ones, and that the large majority of premium vulnerabilities were actually exploitable.
Paying for a plugin does not buy you safety. It buys you support and a roadmap. Those are worth money. They are not the same thing as security.
Two more numbers from the same report that should shape how you think about updates. Nearly half of the vulnerabilities were public before a patch existed. And for the vulnerabilities that get hammered, the median time to mass exploitation is measured in hours, not days.
Which means “we update our plugins monthly” is not a security policy. It is a slow apology.
The risk nobody puts in the build-versus-buy spreadsheet
Here is a thing that actually happened, and it should be part of your calculation.
In October 2024, WordPress.org invoked a clause in its plugin directory guidelines and forked Advanced Custom Fields, one of the most widely installed plugins in the world, away from the company that owned it. It took over the plugin’s slot in the directory and pushed a replacement out through the update channel. Sites that auto-updated got different software than the one they installed.
A court ordered it returned that December. The dispute is still in litigation.
I am not taking a side on that fight. The point is narrower and it is uncomfortable. A plugin you depend on can be taken away from its author, and the replacement can be pushed to your site through an update channel you do not control. That is not a hypothetical. It happened to one of the biggest plugins in the ecosystem, and if you were relying on it, you found out when it happened.
“Just use a plugin” is not the risk-free option. It is a different set of risks, and this is one nobody mentions.
What “free” actually costs
Run the real numbers before you decide.
Premium plugins are almost never a one-off purchase any more. They are annual licences, often priced per site, and the price ratchets. A mid-size site with eight or ten paid plugins is carrying a recurring bill that never ends and that goes up when they feel like it.
Look at a single plugin at a couple of hundred dollars a year. Over ten years that is a couple of thousand dollars, which is inside the range of just having the thing built. That is not an argument for building. It is an argument for doing the arithmetic over the life of the site instead of at the checkout.
Then there is the abandonment problem. A large number of plugins in the WordPress directory have not been touched in years. When a plugin you depend on is abandoned, no patch is ever coming. The fix is a migration project you did not budget for, at a time you did not choose.
And note this, because people misunderstand it: WordPress.org can pull a plugin from the directory, but the copy already installed on your site keeps running. Removal from the directory does not remove it from you. It just quietly stops being maintained while it sits there.
When buying is obviously right
I make my living building custom things and I will still tell you to buy, often.
Buy when the need is genuinely generic. Forms. SEO metadata. Caching. Backups. Analytics. These are solved problems maintained by teams of full time engineers, and building your own is re-inventing a wheel that a hundred people are already polishing.
Buy when a mature product exists with a real company behind it, frequent releases, a public changelog and a security disclosure process. Those are the signals. Not the star rating.
And the answer that is right most often, which almost nobody offers you, is the middle one. Buy the platform and build the last ten percent. A twenty hour custom plugin that extends a mature plugin through its own hooks will beat a two hundred hour ground-up build almost every time, and it leaves you on a maintained foundation.
When building is the right call
When the logic is your business. Your pricing rules. Your quoting process. The workflow your operation actually runs on. If the thing you are automating is the thing that makes you different from your competitors, then bending a generic plugin to fake it will produce something fragile that nobody understands, including you.
When you are stacking plugins to imitate one workflow. If the answer to a business requirement is four plugins and a snippet from a forum, you have not saved money. You have bought four update surfaces, four possible conflicts, and a system nobody can explain in a year.
When the licence and workaround cost exceeds the build cost over three years. Do that sum honestly. Sometimes buying still wins. Do the sum anyway.
When you need to own the data model. If your data is shaped by a plugin vendor’s assumptions, then their roadmap is your roadmap.
The custom plugin is not a purchase. It is a subscription you pay to yourself.
This is the part people do not want to hear, and it is the most useful thing in this post.
Budget somewhere around fifteen to twenty percent of the build cost, every year, forever. PHP moves. WordPress moves. Whatever API you integrated with will change. Code that nobody touches for three years is not stable, it is rotting quietly.
If you cannot commit to that, do not build. Buy the off-the-shelf plugin and let the vendor carry the maintenance, because maintenance is precisely what you are buying from them.
The one request that tells you if your developer is any good
You do not need to read PHP to check the quality of what you paid for.
Ask them to run Plugin Check against it and send you the report. It is the official tool WordPress maintains to test plugins against directory standards, and it covers security, performance, accessibility, translations and version compatibility.
A competent developer will do this in ten minutes and be mildly pleased you asked. Someone who has been cutting corners will find reasons why it does not apply to your project.
That is the whole test. It costs you one email.
Questions worth asking, and why each one matters
“What capability does each action check for?” The most exploited class of WordPress vulnerability is broken access control, which in plain English means the plugin let somebody do something they were not allowed to do. This is not an exotic attack. It is the boring, common one, and it is a discipline question, not a cleverness question.
“Where is user input sanitised, and where is output escaped?” If this question produces a confident, specific answer, that is a good sign. If it produces a vague one, that is your answer too.
“If I delete this plugin, what is left behind in my database?” A good plugin cleans up after itself. A bad one leaves rows in your options table forever, some of them loading on every single page request for the rest of your site’s life.
“Will this plugin’s CSS and JavaScript load on pages that do not use it?” The correct answer is no, and this is one of the biggest quiet causes of a slow WordPress site.
“Is it tested on current PHP?” WordPress recommends PHP 8.3 or newer. A developer still writing PHP 7 era code is building you something that is already aging.
“Can I install this on a fresh WordPress and have it work?” If the answer is no, because it has your page IDs or your server paths baked into it, then you did not buy a plugin. You bought a hostage.
The red flags
- Hardcoded API keys or passwords sitting inside the plugin files. They end up in every backup you take, forever.
- No git repository, or a repository that belongs to them rather than you.
- Wants FTP and admin access to your live site and will not use a staging environment.
- No documentation. You cannot hire a second developer without it, which is exactly the point.
- The plugin re-implements something WordPress already does, like user roles or scheduled tasks, badly.
- Obfuscated code, or a licence key that phones home to their server. Acceptable in a commercial product you are renting. Not acceptable in bespoke work you are paying to own.
- It is one freelancer, with no handover plan, on a plugin your revenue depends on.
- They will not put in writing that you own the copyright and get the source.
How long it really takes
A simple plugin is a couple of weeks. Something mid-sized, a booking engine or a quote calculator with one integration, is more like a couple of months once you count the edge cases and the admin screens that nobody remembered to specify. Anything touching an ERP or a CRM is a quarter, and that assumes the other system’s API is documented and somebody on your side can answer questions about it. It usually is not, and there usually is not.
The biggest variable in that schedule is not the developer. It is you. The same plugin takes four weeks for a client with a clear spec and a decision maker, and sixteen weeks for a client doing their thinking inside the build.
A developer who insists on a proper scoping phase before quoting is not padding the bill. They are the one being honest with you about where the time goes.
The short version
Buy the generic. Build the thing that is actually your business. Extend rather than replace whenever you can.
And drop the assumption that installing a plugin is the safe, cheap, low-risk choice. Ninety one percent of last year’s WordPress vulnerabilities were in plugins, the paid ones were not safer than the free ones, and a plugin can be forked out from under you by the platform itself.
Both roads have risk. Pick the one where the risk is yours to manage.
If you want someone to look at a requirement and tell you honestly whether it needs a custom wordpress plugin or whether you should just buy one and extend it, ask me. I will tell you to buy when buying is right.
