The WordPress plugin market is having a hard time. Customers no longer renew their licences just to get the latest version of a plugin. Agencies no longer buy plugins for their clients. Developers now use AI to build the small utility plugins they used to pay for.
The reason is easy to see. Anyone who needs a plugin can open an AI coding tool, describe what they want, and have a working version before lunch. Why pay every year for fifty features when you only need three?
I have watched this from both sides. I spent a year managing a portfolio of WordPress plugins with large free user bases at a plugin company. Over the years I have also worked with many individuals and agencies in the WordPress community as a developer, a partner and a community leader. My answer will not please plugin companies, and it is not what the AI demos say either.
The short answer
AI has made the first version of almost any software cheap. It has not made owning that software any cheaper. When you buy, you pay someone else to carry the cost of ownership, and they split it across thousands of customers. When you build, even with AI, you carry all of it yourself. So the build vs buy question in 2026 is no longer “can we build it?” The answer to that is almost always yes. The question is “do we want to own it?”
What AI actually changed
Some of the change is real, and it is big:
- Time to a first working version went from weeks to hours.
- Who can build changed. A founder who does not code can now get a working tool without hiring a developer.
- Fit got better. A custom tool does exactly what you need and nothing else, with no settings screens full of features you will never use.
For a lot of small internal tools, building is now the right call when five years ago it was not. I am not arguing against that. I am arguing against stopping the sums at day one.
What AI did not change: the bill for year two
Running plugins taught me where most of the work in software sits. Very little of it was building new features. Most of it was keeping existing code working while everything around it changed. Security alerts arrived regularly. Customers reported problems with features we had shipped long ago, and asked for new variations of features we already had, built slightly differently for their own setup. None of that work went away when AI arrived. It moved to whoever owns the code.
Here is what you take on when you own it:
- Updates you do not control. WordPress core, PHP versions, your theme and the other plugins on the site all change on their own schedule. Any of them can break your code without anyone touching it. A plugin team tests against those changes before every release. A custom plugin gets tested on the day it breaks.
- Security. Every form, upload and login is a target. Plugin companies receive vulnerability reports and ship patches. Nobody sends reports for code only you have, and nobody patches it unless you do.
- Edge cases. The version AI writes handles the case you described. Real users find the cases you did not: the empty field, the second currency, the visitor on an old phone, the form that stops sending emails the day the site switches to a different SMTP plugin.
- Knowledge. When it breaks, someone has to understand code that nobody wrote line by line. If the person who prompted it leaves, that knowledge leaves with them.
- Data. Once real customer data lives in your custom tool, moving away from it costs more every month.
None of this shows up on the day you build it. It shows up months later, usually at a bad moment, as technical debt that nobody planned for.
When building with AI is the right call
Build it yourself when most of these are true:
- The tool is internal and only a few people use it.
- If it breaks, the cost is an annoyance, not lost money or leaked data.
- What you need is narrow and will not change much.
- It is part of what makes your product different, so owning it is the point.
- Nothing on the market fits, or the closest fit is mostly features you will never use.
- It is a prototype to learn what you actually need before you choose a product to buy.
When you should still buy
Buy when the software touches money, personal data, security or compliance, or when keeping it correct means keeping up with an outside world that changes without asking you: payment rules, tax rules, browser changes, platform APIs. That work is the product someone else is selling, and they do it for every customer at once.
Payments are the clearest case. When I led a payment gateway migration for a family of telecom products, nobody suggested building our own payment processing. Even moving from one bought gateway to another took under three months of careful work: saved cards, auto top-ups, 3D Secure, and a gradual traffic split so that no payment or balance was lost. That was the effort to move between two products other companies maintain. Owning that layer ourselves would have meant running a different company.
The middle option most teams miss
Build vs buy is rarely all or nothing. The option that usually works best now is to buy the core and build the edges with AI. Keep a maintained product for the part that needs updates, security and support, and use AI to build the small custom piece it does not cover: the one workflow, the one integration, the one report. The maintained part carries the heavy ownership cost. Your custom part stays small enough that one person can understand all of it.
Five questions before you build it yourself
- If this breaks on a Friday night, who fixes it, and how fast does it need fixing?
- Does it touch money, personal data or logins?
- What outside systems does it depend on, and how often do they change?
- Can someone other than the person who built it explain how it works?
- A year from now, will we be glad we own this, or will we be paying someone to maintain it?
If the honest answers to questions 1 and 4 make you uncomfortable, buy. If they do not, build, and write down who owns it.
What this means if you sell software
If you make plugins or SaaS, features are no longer what you are selling, because a customer can now build the three features they need. What they cannot easily build is ownership: the updates, the security patches, the support and the years of edge cases already handled. Three things follow from that:
- Price and market the maintenance, not the feature list. A renewal should buy security fixes, compatibility with the next WordPress and PHP release, and support. Say so plainly on the pricing page, because that is the part customers cannot build in an afternoon.
- Become the core that others extend. If customers are going to build the edges with AI anyway, make your plugin the maintained base they build on: clear hooks, a documented API, and examples an AI coding tool can follow. A customer who builds on top of your plugin keeps renewing it.
- Sell agencies ownership, not licences. Agencies stopped buying plugins for each client, but they still carry the risk when a client site breaks. Offer them what reduces that risk: updates across all their client sites, security monitoring and priority support.
Build it, but decide who owns it first
Use AI to build, by all means. I do. Just make the build vs buy call on the cost of year two, not on the speed of day one. Helping founders make this kind of call before it turns into a maintenance problem is a large part of my work as a fractional product manager.
Tahir Shahzad
Tahir Shahzad is a Product Manager, Product Owner, and technology consultant with over a decade of experience helping startups and organizations build products people actually use. If you are working on a product problem worth solving, reach him at tahirshahzad.com/contact/
