WordPress plugin or custom code: how to choose
Guide. Published 14 October 2026.
A plugin is usually the right choice when a well-supported one already does what you need, exactly. Custom code earns its place when no plugin fits, or when the plugins that nearly fit would cost you more in licences, clutter or workarounds than a small piece of purpose-built code. This guide shows how to tell which side your feature falls on.
In short
- Start with a plugin if a well-supported one does exactly what you need. It is quicker, and the maker maintains it for all its users.
- Judge a plugin by its updates, who makes it, what support exists and what renewing the licence costs.
- Consider custom code when the feature depends on your own figures, on how your staff work or on data from another system.
- Either way, test on a private copy, keep backups and work with a developer who can explain the code.
A simple way to decide
- Write down what the feature must do. Use plain words and include the awkward cases, such as a missing price or a half-filled form.
- Ask whether a simpler set-up would do. Sometimes the honest answer is to drop part of the feature.
- Look for a plugin that does exactly that. Roughly is not enough: a plugin that does most of the job can leave you with a workaround to repeat every week.
- If one does the job, check it against the list in the next section. If it passes, use it.
- If one does most of it, weigh the gap. A setting you can live without is fine. A gap that has your staff retyping information again and again is not.
- If none fits, or the only one that does carries a licence you would rather not renew every year, ask a developer to quote custom code.
How to judge a plugin
Every plugin you add is code written by someone else that runs on your site. Before you install one, check:
- Is it kept up to date? The plugin page in the official WordPress plugin directory shows when it was last updated. A plugin untouched for a long time is a warning sign: it may stop working with newer versions of WordPress or PHP, and security problems may go unfixed.
- Was it tested with your WordPress version? The directory lists the latest WordPress version the author has tested it with. Paid plugins usually say the same on their own site or in their change log.
- Is the source reputable? Download from the official directory or from the website of the company or person who makes it. Never use a free copy of a paid plugin from somewhere else, because such copies can carry hidden malicious code.
- Is there support? Look for a support forum or an email address, and see whether questions get answered. The number of sites using a plugin and its reviews are signals, not proof.
- What does it add? Many plugins load scripts and styles on every page, even where they are not used, which can make pages heavier. Each plugin is also one more thing to keep updated and one more part that can clash with the others.
- What are the licence terms? Paid plugins are often sold as annual licences, and when a licence lapses, the plugin usually keeps working, but updates and support usually stop, and an unpatched plugin becomes a security risk. Find out the renewal price, whose name the licence is in and where the login is kept.
Where a plugin is usually enough, and where custom code earns its place
These are tendencies, not rules. Check each one against what you actually need.
| Feature | Usually | Why |
|---|---|---|
| Contact forms | Plugin | A common need that well-supported plugins cover. |
| Basic memberships | Plugin | Member-only pages and logins are well covered. Unusual access rules may not be. |
| Bookings | Plugin | Simple appointments are covered. Unusual availability or pricing rules may not be. |
| SEO settings | Plugin | Page titles, descriptions and sitemaps are settings, not custom logic. |
| Caching | Plugin | Some hosts include caching, so check first, and use one caching tool rather than several. |
| A calculator that works from your own figures | Custom often earns its place | Your rates and rules rarely match a generic calculator, and bending your pricing to fit it invites errors. |
| A multi-step form with a review stage for your staff | Custom often earns its place | The review stage is your own process, so it must fit how your staff work. |
| Importing data from a supplier or another system | Custom often earns its place | Files are often laid out differently, and matching them to your products can need rules of your own, though a simple, regular file may be handled by a ready-made import tool. |
| A connection between your site and another system you use | Custom often earns its place | It depends on both systems, and must cope when one is unavailable. |
Some plugins do offer a ready-made connection to a popular system, so look first. For a worked example of the import case, see how supplier stock updates work in a WooCommerce shop.
The trade-offs
| Aspect | Plugin | Custom code |
|---|---|---|
| Time to start | Can be installed and set up quickly. | Has to be specified, built and tested first. |
| Fit | May do more than you need, or less. | Does what was specified, and no more. |
| Upkeep | The maker maintains it, though you still apply the updates. | Someone has to maintain it, and adjust it when WordPress, PHP or the other system changes. |
| Cost | Free, or a licence that usually renews. | The cost of the build, plus upkeep if you want it covered. |
| Documentation | Public instructions from the maker. | Only as good as what the developer writes down and hands over. |
| Dependence | The maker may stop updating it or change its terms. | You depend on the developer, or on whoever takes the code over. |
Keeping either safe, and what to bring to a developer
Keeping either safe
- Use a private copy for testing. Try changes on a copy of the site that visitors cannot see, so a problem shows up there first.
- Back up before changing anything. Make sure a recent backup exists, ideally one kept away from the site itself.
- Keep updating. WordPress, your theme and every plugin need updates, and so does custom code. See website maintenance.
- Delete what you do not use. A plugin you no longer need should be removed, not left switched off.
- Choose a developer who can explain the code. Ask what it does and what it depends on, and ask for it to be written down so someone else could take it over.
What to bring to a developer
- What the feature must do, step by step, including the exceptions. A sample file or a spreadsheet of your figures helps.
- What data it touches: your prices, customer details, files from a supplier, or another system. If it handles personal information, say so, and have your policies written for your business.
- Who will use it: customers, your staff or a supplier, and how comfortable they are with technology.
- What you have already tried, such as plugins you looked at and why they did not fit.
If the feature is part of a larger change to the site, what to send a developer before a website redesign covers the rest.
How we can help
When you ask us for a feature, we check first whether an existing plugin does the job, what it costs and whether it has the features you need, and we recommend it if it does. We write custom code only when none covers the need, or when you would rather not pay for a licence. Paid plugin licences are bought for you and stay with you. Custom work is split into tasks with hours, tested on a private copy that you review, adjusted in one agreed round of revisions and approved by you before go-live, and it is delivered with editing instructions and training. Afterwards it can be covered by a maintenance retainer. For the full picture, see custom features, plugins and integrations on our WordPress development page.
More guides: supplier stock updates in WooCommerce, what to send a developer before a website redesign and all our guides.
Have a project in mind?
A new website, a shop, a design refresh or a feature your site is missing: tell us a little about what you need and we will talk through the options.