Default to buying
If a well-maintained plugin does what you need, buy it. Someone else handles compatibility with every WordPress release, security patches, edge cases you have not imagined, and support. That is a great deal of ongoing work you are not doing.
Before deciding it does not fit, check honestly whether your requirement is genuinely different or merely unfamiliar. A surprising amount of “we need something custom” turns out to be “we have not read the settings page”.
Check what you are depending on
Buying means taking a dependency. Two minutes on the plugin’s wordpress.org page tells you whether that is safe:
| Signal | Healthy | Walk away |
|---|---|---|
| Last updated | Within months | Over a year |
| Tested up to | Current WordPress | Two majors behind |
| Support forum | Recent threads with replies | Unanswered for months |
| Active installs trend | Steady or growing | Falling sharply |
For premium plugins there is no public page, so ask directly: how often do they release, and what is the policy when WordPress or PHP makes a breaking change?
An abandoned plugin is a liability that grows. It will break on a PHP release eventually, and by then it may hold years of your data. Replacing it later costs far more than choosing differently now — which is why “it works today” is not the test.
When buying stops working
Four situations where off-the-shelf reliably runs out:
- The logic is your business. Your pricing rules, approval workflow, fulfilment process. Nobody sells it because nobody else has it.
- The integration does not exist. Your ERP, an internal system, an API with no WordPress connector.
- You are chaining plugins to fake one feature. A form plugin, an automation plugin, a webhook plugin and two connectors, held together by configuration nobody documented.
- The plugin is abandoned and you now depend on code nobody maintains.
Price the “nearly fits” option properly
This is the expensive middle ground, and almost nobody does the arithmetic.
A plugin does seventy percent of what you need. You buy it and work around the rest — a snippet here, a second plugin there, a manual process every Tuesday. Then:
| Line | Worked example |
|---|---|
| Manual work the gap creates | 2 hours a week |
| Over a year | ~100 hours |
| At a modest internal cost | Several thousand pounds |
| Plus errors, and the person who leaves | Not on the invoice, but real |
| Against: building it once | Often less than one year of the above |
Use your own numbers rather than these. The point is that the workaround has a price and it is recurring, while the build has a price and it is mostly once. That comparison is frequently uncomfortable.
The option people forget: buy, then extend
Between buying and building sits the answer that is right surprisingly often — buy the plugin that does seventy percent, then close the gap through its own hooks.
A small plugin of your own
<?php
/**
* Plugin Name: Acme — Store Rules
* Description: Our pricing logic. Built on WooCommerce hooks, not core edits.
*/
add_filter( 'woocommerce_product_get_price', function ( $price, $product ) {
// Trade customers get our contract rate.
if ( ! is_user_logged_in() || ! current_user_can( 'trade_customer' ) ) {
return $price;
}
$contract = get_post_meta( $product->get_id(), '_trade_price', true );
return is_numeric( $contract ) ? $contract : $price;
}, 10, 2 );Twenty lines in your own plugin, surviving every update of the plugin it extends. That is a different proposition from either buying blind or building everything.
Never edit a plugin’s own files. The next update overwrites your change without warning — and you will not find out until something quietly stops working. If it cannot be done through a hook, fork it properly or build your own.
Plugin or theme code?
If you do build, this matters more than people realise.
Would you still need this if you redesigned the site tomorrow? If yes, it is functionality and belongs in a plugin. If no, it is presentation and belongs in the theme.
Business logic sitting in functions.php is one of the most common reasons a redesign costs far more than quoted: the new theme arrives, and three years of accumulated functionality has to be found, understood and rewritten — usually discovered halfway through.
# How much is hiding in there?
wc -l wp-content/themes/your-theme/functions.phpSeveral hundred lines is a warning sign. Move the functionality into a small site-specific plugin now, while it is a calm afternoon rather than a redesign emergency.
What building actually costs
Not just the initial development. Budget honestly for:
- Specification — deciding what it does and does not do, which is most of the value
- Build and testing
- Documentation, so the next developer is not reverse-engineering it
- Ongoing compatibility as WordPress and PHP move
That last line is the one people forget. A custom plugin is a small permanent commitment, not a one-off purchase — which is exactly why building something a maintained plugin already does is a poor trade.
A decision you can make in five minutes
- Does a well-maintained plugin do this? → Buy it.
- Does one nearly do it, and the gap has a hook? → Buy it and extend it.
- Are you chaining plugins to fake one feature? → Build it.
- Is the logic specific to how your business works? → Build it.
- Is it presentation only? → Theme code, not a plugin.
Whatever you build, build it on documented hooks and APIs — never by editing core. Custom code that breaks on every WordPress update is worse than the workaround it replaced.
Common questions
How much does a custom plugin cost?
It depends entirely on the specification, which is why the spec is the first deliverable rather than an afterthought. Anyone quoting before understanding the rules is guessing, and the guess will be wrong in one direction or the other.
Can we start with a plugin and build later?
Often the best sequence — buy to validate that the feature matters, build once you know exactly what it needs to do. Just keep the data portable so the switch is not a rewrite.
What about code snippets from a blog post?
Fine for something small, in a site-specific plugin, once you understand what it does. Pasting unread code into functions.php is how sites acquire mysteries.
Who owns custom plugin code?
Agree it in writing before work starts. You should own it and hold the repository — otherwise you have bought a dependency on one supplier, which is the thing custom development was supposed to avoid.
