“Should we buy this or build it?” is one of the highest-leverage questions in a WordPress project, and it gets answered badly in both directions — agencies over-build things that exist, and clients over-buy things that were never going to fit.
Default to buying
If a well-maintained plugin does what you need, buy it. Someone else is handling compatibility with every WordPress release, security patches, edge cases you have not thought of, and support. That is a lot of ongoing work you are not doing.
Before deciding it does not fit, check honestly whether your requirement is genuinely different or just unfamiliar. A surprising amount of “we need something custom” is really “we have not read the settings page”.
When buying stops working
Four situations where off-the-shelf reliably runs out:
- The logic is your business. Your pricing rules, your approval workflow, your fulfilment process. Nobody sells that because nobody else has it.
- The integration does not exist. Your ERP, your 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 with configuration nobody documented.
- The plugin is abandoned. No updates in two years, and you are now depending on code nobody maintains.
The hidden cost of “nearly fits”
This is the expensive middle ground. A plugin does seventy percent of what you need, so you buy it and work around the rest. The workarounds accumulate: a snippet here, a second plugin there, a manual process every Tuesday.
Add up what the workarounds cost in staff time over a year, then compare that to building the thing once. That comparison is frequently uncomfortable, and it is the calculation almost nobody does.
Plugin or theme code?
If you decide to build, this matters more than people realise. The test is simple:
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 becomes far more expensive than quoted. The new theme arrives and three years of accumulated functionality has to be found, understood and rewritten — usually discovered halfway through.
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 one is the line 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 bad trade.
A decision you can apply in five minutes
- Does a well-maintained plugin do this? → Buy it.
- Does one nearly do it, and the gap is cosmetic? → Buy it and extend it through its hooks.
- Are you running several 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 and never by editing core files. Custom code that breaks on every WordPress update is worse than the workaround it replaced.