The people who ask me about a plugin of their own are usually site and store owners who have already gone through the WordPress directory and a few paid add-ons, and none of them does exactly what they need. A custom WordPress plugin is code written for one specific function of your business: an unusual price list, an integration with a system nobody else uses, or a process someone in the office still retypes by hand. The question is rarely whether it can be built, because it almost always can. It is more like this: when is it cheaper than buying a ready-made plugin and bending it into shape, and who will maintain it when WordPress ships its next update?
Below I break it down into three decisions: when off-the-shelf stops being enough, what drives the cost of building and maintaining a plugin, and how to choose between buying, adapting and building from scratch. I am not repeating the licence bill for ready-made plugins or the theme decision here - I covered both separately and link to them below.
A custom WordPress plugin - what it is and what it is not
A plugin is a separate package of code that WordPress loads alongside the theme. It attaches to so-called hooks, the points where WordPress and WooCommerce let you add your own behaviour: when an order is saved, when the cart price is calculated, when an email goes out. That way your own feature does not require digging into the core of the system, and it survives core updates as long as it follows those rules.
A plugin built to order is not the same as a modified copy of someone else’s plugin. Changes written straight into the files of a ready-made add-on disappear with its next update. And if someone switched updates off to protect those changes, the site is left with code nobody patches any more.
Nor is it a snippet pasted into the theme’s functions.php file. That code vanishes when the theme changes, and a year later nobody remembers it is there. A plugin of your own lives separately: it has its own name, version and change history, and switching it off is one click in the admin panel.
When an off-the-shelf plugin stops being enough
A ready-made plugin is a good choice as long as it does what you need without you working around its limits. The trouble starts when a layer of patches grows around it. The signals I see most often with clients:
- You buy a second plugin to fix the first one. One add-on calculates discounts, another fixes how they show up in the cart, a third turns it all into a report. Each has its own author, its own update cycle and its own idea of what belongs in the same database field.
- The plugin does a lot and you use one thing. A settings panel full of options, of which you touch two, loads on every page view, and each of its updates can change something you do not even know exists.
- Your business process is unusual. Per-customer pricing taken from a contract, shipping that depends on the warehouse, a document in the exact format your system expects. Ready-made plugins build the averaged version, and someone makes up the difference by hand.
- An integration with a system nobody else has. An in-house warehouse program, an older ERP or a wholesaler with its own API. There is no market for that integration, so there is no ready-made plugin either.
- Updating the plugin regularly breaks something. That is a sign you are working at the edge of what the plugin was designed for.
One signal on its own is not a reason to build from scratch. Several at once usually mean you are paying more for working around the plugin than your own code would cost - you just pay in staff time and outages rather than in a single invoice.
The cost of building and maintaining - market ranges
Asked what a WordPress plugin built for a business costs, an honest answer starts with the scope, not with a figure. The same label covers a simple cart add-on and an integration with a warehouse system. Treat the ranges below as a reference point, not a price list - they depend on scope and shift from year to year.
| Scope | Example | Market range |
|---|---|---|
| A single new feature | a calculator, a custom cart field, a simple customer panel | from a few hundred to a few thousand zloty |
| Integration with an external system | ERP, warehouse, courier, invoicing | a few thousand zloty and up |
| Hourly billing | when the developer does not quote the scope up front | from several dozen to a few hundred zloty per hour |
I went through the same ranges in more detail in the post on how much a WordPress developer costs. What matters more here is what pushes the cost up or down:
- How many places the plugin hooks into. A feature visible only in the admin panel is a different job from one that changes the cart, the order, the email and the invoice at the same time.
- External systems. Every API means documentation, a test environment or the lack of one, and edge cases the spec does not mention.
- Historical data. If the plugin has to take over orders or customers from the current solution, moving that data and checking it is part of the job.
- A settings screen. Options your team can click through cost more than values fixed in the code.
Maintenance is the other half of the bill, and the half least often discussed when the quote is written. A plugin of your own has no licence to renew, but it is not written once and for all. It is affected by:
- WordPress and WooCommerce updates that change how hooks behave or retire old functions
- a change of PHP version on the hosting
- changes on the side of external systems: a new API version, new fields, an old endpoint switched off
- new business needs, because a plugin usually grows together with the process
With a plugin that has automated tests, a review after a major update means running the tests and checking the key paths on a staging copy. Without tests, every update means clicking through everything again by hand and hoping nothing slipped through.
A premium off-the-shelf plugin has the opposite cost profile: a small outlay at the start, but a yearly licence that in practice is a subscription to updates and support. Once it expires, the plugin usually keeps working, it just stops receiving fixes. How those licences add up in a store is something I showed in the post on what WooCommerce plugins really cost.
How to choose: buy, adapt or build
| Option | When it makes sense | What to watch |
|---|---|---|
| Buy off the shelf | the feature is standard, the plugin covers it fully, the author ships regular updates | licence on the company account, not the developer’s; date of the last update |
| Adapt a ready-made plugin | the plugin does most of it, one behaviour is missing | changes through hooks in a separate small plugin, never in the plugin’s own files |
| Build your own | an unusual process, an integration with no ready-made option, several plugins patching one feature | scope in writing, code in the company repository, a maintenance plan from the start |
The middle option is underrated. Many ready-made plugins expose hooks of their own precisely so their behaviour can be changed from the outside. Instead of rewriting everything, you add a small plugin next to it that changes one behaviour and survives the main plugin’s updates. Small things like a custom cart field or a simple shipping rule are often a dozen or so lines of code rather than another yearly licence.
Before you decide, answer four questions:
- Does the ready-made plugin do what I need without a second plugin to fix the first?
- Does it have an active author and regular updates?
- Does money or customer data pass through this feature?
- Who will maintain it a year from now?
If the answer to the first two is yes, buy. If the plugin is close but not quite there, adapt it. If no ready-made option gives a good answer to the third and fourth, that is the moment for your own code. The same logic, where off-the-shelf wins at the start and code written for the business wins over time, applies to choosing between a premade theme and a custom design, except that there it is about the look of the whole site and here it is about one feature.
What I do differently - code in your repository, tests and transfer of rights
Extending an existing site or store with a missing feature is part of my site and store optimization work. Before I suggest a custom plugin, I check whether a ready-made one or an adapted version would solve the problem. I go into the code and fix the foundation instead of bolting on yet another plugin, but I also do not build from scratch something that already exists and works.
When a plugin of your own makes sense, this is how I work:
- Code in the client’s repository from day one. Not at handover - I work in the company’s repository from the start, so the code is where it is meant to stay.
- Tests. I test every line and take responsibility for it. My toolkit includes automated tests - PHPUnit and Pest for the logic, Playwright for paths in the browser - so a review after a WordPress update is not guesswork.
- Licences on the client’s account. If the solution relies on paid add-ons, the licences are bought in the client’s company name, so updates keep arriving after we stop working together.
- Transfer of rights. The rights to what I wrote to order pass with the final payment, in writing, with the scope named. A copy that any developer can run on their own machine is part of the handover.
- A fixed price for an agreed scope. You get the quote in writing before the start, so you know the figure before anything is built.
I work this way because a plugin of your own is code your business starts to depend on. If it sits only with the developer, you swap dependence on a plugin author for dependence on one person. What part of the code and graphics actually belongs to your company after you pay is something I covered in the post on who owns the website code and graphics.
Frequently asked questions
When is it worth ordering a custom plugin? When working around a ready-made plugin costs you more than your own code would: several plugins patch one feature, your process is unusual, or you need an integration with a system nobody has written an add-on for. For standard features, a ready-made plugin with an active author usually wins.
How much does a plugin built to order cost? It depends on the scope. On the market, a single feature runs from a few hundred to a few thousand zloty, and an integration with an external system a few thousand and up. A specific figure is only possible once you describe what the plugin should do, where it hooks in and what it talks to.
Who maintains the plugin after WordPress updates? Whoever has its code and knows how it is built - which is why the code has to sit in your company’s repository, not only with the author. That can be the author under ongoing support, or another developer you hand the repository to. With tests, the review after an update is short; without them, someone has to walk through every path by hand.
Will a custom plugin slow my site down? It does not have to. A well-written one loads only what it uses, while a ready-made plugin full of options often loads more than the site needs. If your own plugin does slow the site down, the cause usually sits in database queries - and that shows in the code and can be fixed, because you have access to it.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. See how I work on it: site and store optimization.