No — AI isn't killing the WordPress plugin market, but it's quietly gutting the middle of it. Simple utility plugins that solve one small problem for $49/year are getting replaced by 60 lines of AI-written code. Complex plugins with real infrastructure behind them are safer than ever. The squeeze is happening in between.
Is AI actually replacing WordPress plugins?
Partially. AI coding assistants have made it economically rational to build small, site-specific functionality instead of buying and maintaining a plugin for it. But that shift only touches a specific tier of the market: cheap, single-feature utilities. Anything with a hosted backend, ongoing compliance burden, or hundreds of edge cases is still cheaper to buy.
The WordPress.org repository lists roughly 59,000 free plugins, and the commercial market layered on top of it is worth hundreds of millions annually. That market didn't get built because people love plugins. It got built because writing code was expensive and buying was cheap. That equation just changed on one side.
According to the Stack Overflow Developer Survey, 76% of developers were using or planning to use AI tools in their development process (2024). In agency-land, that number is functionally 100% at this point. Every WordPress developer I know has Claude Code or a similar tool open in a terminal while they work. The question stopped being "can AI write this?" and became "should we own this?"
What actually changed: the economics, not the technology
Custom WordPress code was always possible. What changed is that a 90-minute developer task became a 20-minute supervised task, and that flips the buy-vs-build math on a whole category of small features.
Here's the scenario I hear constantly from agency owners. A client wants shipping messages that change by zone and product category. Historically: find a plugin, pay $79/year, install it, discover it loads 140KB of JavaScript on every page, and now you own a dependency forever. Today: describe the requirement to an AI coding tool, get a 40-line function, test it in staging, ship it. That's a $79/year recurring cost eliminated and one fewer update to babysit.
Multiply that across 40 client sites and the numbers get real:
| Cost factor (3-year view) | Commercial plugin | AI-assisted custom function |
|---|---|---|
| Upfront build | $0 | |
| License, 3 years | $150–$300 | $0 |
| Update/compatibility checks | ~15 min × 12 updates = 3 hrs | ~30 min total (PHP/WP version checks) |
| Security exposure | Shared attack surface, disclosed CVEs | Private, unadvertised, small surface |
| Bus factor | Vendor may abandon or get acquired | Your team owns it (good and bad) |
| Feature drift | You get features you didn't ask for | Exactly what you specified, nothing more |
| 3-year total cost | $400–$700 per site | $60–$150 per site |
That table looks like a slam dunk for custom code. It isn't, and the reason is in the "bus factor" row. We wrote a full decision framework on this — when to replace WordPress plugins with custom code — because the answer genuinely depends on the plugin, not on a philosophy.
Which plugins are actually at risk?
Three tiers. The bottom tier is already being eaten. The middle tier is getting squeezed. The top tier is arguably stronger than it was five years ago.
Tier 1 — Being replaced right now. Single-purpose utilities: custom post type registration, conditional shipping messages, admin column tweaks, login page branding, simple redirect managers, "hide this menu item from this role" plugins. These are 30–120 lines of code with no ongoing service. Buying them was always a convenience purchase. Convenience just got cheaper elsewhere.
Tier 2 — Under pressure. Mid-market plugins in the $99–$299/year range that do one substantial thing: form builders, basic membership gating, simple booking systems, table plugins. AI makes a stripped-down replacement viable, but only if your requirements are genuinely narrow. Most teams underestimate how many edge cases the plugin already solved — spam filtering, GDPR export hooks, timezone handling, accessibility markup.
Tier 3 — Safe, and getting safer. Anything with a hosted service, payment processing, or a large compliance surface: WooCommerce extensions touching money, real security stacks, backup systems with off-site storage, page builders, SEO suites with data pipelines. You cannot AI your way to a maintained PCI-adjacent payment integration in an afternoon, and you shouldn't try.
The pattern is simple: AI replaces code, not infrastructure. If most of a plugin's value is a hosted API, a threat-intelligence feed, or a team keeping up with a third party's breaking changes, the plugin wins.
When replacing a plugin with custom code makes business sense
Replace when the plugin does one small thing, the requirement is stable, and you're paying for convenience rather than infrastructure. The strongest signals: a plugin that loads assets sitewide for one page's worth of function, a plugin you've had to filter or override to make behave, or a plugin whose vendor just got acquired.
Concrete green lights:
- You already override it. If your functions.php has five filters bending a plugin into shape, you're maintaining custom code plus a dependency. Pick one.
- Performance tax is measurable. A plugin adding 200ms of TTFB or 300KB of unused JS on every page has a real conversion cost, not a theoretical one.
- The vendor's future is shaky. Plugins get abandoned, sold, or pulled from the directory entirely — and when that happens, you're inheriting the code anyway, just without documentation.
- You're paying per-site licenses across a portfolio. Forty sites × $79/year is $3,160/year for functionality you could own once.
- The spec fits on an index card. If you can describe the entire behavior in three sentences, it's a candidate.
If you haven't run a WordPress plugin audit recently, do that before you write a line of code. Most sites we onboard have 4–8 plugins that are either duplicating each other or doing nothing at all. Deleting is faster than rewriting, and free.
When buying the plugin is still the smarter call
Buy when the plugin's real product is ongoing vigilance. Security tools, backup systems, payment gateways, tax calculation, and anything tracking a third-party API's breaking changes are all cases where the license fee buys you someone else's full-time attention.
Red flags that should stop a rewrite:
- Money touches it. Checkout, subscriptions, tax, refunds. The failure cost is asymmetric — save $200/year, lose $9,000 in a botched tax rounding bug.
- Compliance touches it. GDPR data export, accessibility, cookie consent. These rules change and someone has to track them.
- A third-party API touches it. Shipping carriers, CRMs, marketplaces. Their breaking changes become your emergency.
- You can't describe every edge case. "Handle recurring bookings" hides a calendar's worth of complexity.
- Nobody on the team can read the output. AI-generated code you can't review is worse than a plugin you didn't write, because at least the plugin has a support desk.
That last one deserves emphasis. AI dropped the cost of producing code to near zero. It did not drop the cost of reviewing code. If your team can't tell whether a generated function sanitizes input properly, you've traded a known vulnerability surface for an unknown one. Patchstack found that roughly 97% of WordPress vulnerabilities disclosed in 2023 came from plugins — but that statistic reflects code quality across a public ecosystem, not a magical property of the word "plugin." Sloppy custom code is just an undisclosed vulnerability.
The hidden cost nobody prices in: maintenance ownership
Writing the code is now 10% of the total cost. The other 90% is owning it through every WordPress core release, PHP version bump, and theme change for the next five years — and doing it without a vendor's changelog to warn you.
Here's what that looks like in practice for an agency running 40 sites:
| Portfolio scenario | Plugin licenses/yr | Custom functions owned | Annual maintenance hours | Net annual cost |
|---|---|---|---|---|
| All plugins, no custom code | $6,400 | 0 | ~48 hrs update testing | ~$11,200 |
| Aggressive custom-code strategy | $1,900 | 60+ functions | ~70 hrs review + regression | ~$12,900 |
| Selective replacement (Tier 1 only) | $3,100 | 12–15 functions | ~40 hrs | ~$9,100 |
(Assumes $100/hr blended internal rate. Figures are illustrative planning numbers, not benchmarks.)
The aggressive strategy costs more, which surprises people. Owning 60 custom functions across 40 sites means 60 things that no vendor tests against WordPress 7.x for you. The winning play is selective: kill the cheap utilities, keep the infrastructure plugins, and put the savings toward better testing.
This is also where the managed vs. unmanaged hosting question stops being abstract. Custom code without staging is a coin flip.
Why this shift makes your hosting environment more important, not less
Custom code moves risk from a vendor's QA team to your deployment process. That's a fine trade — if you have a deployment process. Without staging, snapshots, and fast rollback, every custom function is a production experiment with your client's revenue as the test subject.
A plugin at least ships with a version number, a changelog, and a rollback path via the WordPress admin. Your custom add_filter has none of that. When it breaks after a PHP 8.4 upgrade, the recovery plan is entirely on your infrastructure.
What that practically requires:
- Real staging that mirrors production. Not a subdomain running different PHP. Same stack, same versions. Our approach to WordPress staging environments covers why "close enough" staging causes more incidents than no staging.
- Snapshot-and-rollback measured in minutes. If restoring takes an hour and a support ticket, you'll avoid deploying, and avoiding deployment is how technical debt compounds.
- Monitoring that catches silent failures. A broken custom shipping function doesn't throw a 500. It just quietly stops applying a rule, and you find out from an angry client in three weeks. TopSyde Sentinel handles 24/7 monitoring for exactly this class of problem.
- Humans who read PHP. When something breaks at 4pm on a Thursday, "restart your browser" isn't support. TopSyde support responds in under 2 hours during business hours, and the people answering can actually read a stack trace.
You can see the full environment spec on our hosting stack spec sheet if you want to compare it against what you're running now.
So what happens to the plugin market?
Consolidation, not collapse. Expect the $30–$99/year single-feature tier to shrink meaningfully over the next few years, while plugins built around hosted services, data, and compliance expand. The plugin business is turning into a software-services business — which is what the strong vendors already were.
Three predictions I'd put money on:
- Free utility plugins stay, paid ones don't. If someone can generate the same thing in 20 minutes, a paywall doesn't hold.
- Plugin vendors ship AI features to justify licenses. We've already covered what WordPress 7's AI features actually do — the same pressure applies to commercial vendors.
- Agencies split into two camps. Those with proper dev workflows go custom-heavy and improve margins. Those without go plugin-heavy and stay safe. Both are valid. Picking the wrong one for your team's actual capability is what hurts.
For agencies specifically, the margin story is the interesting part. Cutting $3,000/year in per-site licenses across a portfolio doesn't just save money — it makes care plans and managed hosting for agencies more profitable without raising client prices. That's a real competitive edge, and it compounds.
How to test this without betting the portfolio
Pick one site. Not a client's flagship — an internal site or a low-traffic client you have a good relationship with. Then:
- Run a plugin audit and list every plugin costing under $100/year that does one thing.
- Pick the two worst offenders by page-weight or override count.
- Rebuild them as custom functions in staging, with an actual code review by a human who knows WordPress.
- Snapshot, deploy, monitor for 30 days.
- Measure: page weight, TTFB, license savings, and — honestly — how many hours it actually took.
If the numbers work on site one, roll it out. If they don't, you've spent an afternoon and learned something concrete about your team's capacity. Either result is worth having.
The one thing that shouldn't be optional is the environment you're running the experiment in. If your host can't give you a production-identical staging site and a rollback that takes 90 seconds, the strategy isn't available to you yet — and no AI tool changes that.
TopSyde managed WordPress hosting starts at $89/mo per site with staging, snapshots, 24/7 monitoring via TopSyde Sentinel, and support that answers in under 2 hours during business hours. There's a 30-day money-back guarantee, and we handle the migration. If you're running a portfolio, the agency hosting plans and full pricing breakdown are the right places to start.
Frequently Asked Questions
Can AI write a WordPress plugin from scratch?
Yes, for narrow, well-specified functionality — AI tools produce working plugin scaffolding and functions reliably. What they don't reliably produce is comprehensive input sanitization, capability checks, and edge-case handling without a knowledgeable human reviewing the output. Treat AI as a fast junior developer, not a replacement for code review.
Is custom code more secure than using a plugin?
Not inherently. Custom code has a smaller, unadvertised attack surface, which is a genuine advantage — attackers scan for known plugin vulnerabilities, not your private function. But a plugin from a serious vendor gets security review from people who do it full time. Custom code is only safer if you actually review it.
How many plugins is too many for a WordPress site?
There's no magic number, but most sites we onboard run 25–40 plugins and could comfortably operate on 15–20. The metric that matters isn't count — it's how many plugins load assets or run queries on pages where they aren't used. A plugin audit answers that faster than a rule of thumb.
Will replacing plugins with custom code lock me into my developer?
It can, which is a legitimate business risk. Mitigate it by requiring documented, commented code stored in version control rather than pasted into the theme's functions.php. Documented custom code in a repo is portable; undocumented code buried in a child theme is a hostage situation.
Does managed hosting matter more if I'm running custom code?
Yes. Custom code removes the vendor's testing and rollback safety net, so your hosting environment becomes the safety net. Production-identical staging, fast snapshot restores, and monitoring that catches silent failures are the difference between a custom-code strategy that saves money and one that generates emergencies.
Topics
Founder & Lead Developer
20+ years full-stack development, WordPress, AI tools & agents
Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.
