There is a dangerous sentence in WordPress development.
“There must already be a plugin for that.”
Usually there is.
There are approximately seventeen of them. One was last updated during the first Obama administration. Three do 80 percent of what you need. Two do 400 percent of what you need and would like permission to add twelve new menu items to WordPress. One looks perfect until you discover the feature you actually need is included in the Enterprise Platinum Galactic plan.
And one really is excellent.
We are not anti-plugin. WordPress would be a fairly peculiar platform on which to take that position.
But over the years we have increasingly found ourselves reaching a point where installing another plugin is not the obvious answer.
Sometimes it is easier, safer and ultimately better to build exactly what the project needs.
We always look for the sensible existing solution first
Custom development should not begin with ego.
If a mature, well-supported plugin already solves the problem properly, rebuilding it simply so we can admire our own PHP would be a spectacular waste of the client's money.
There are areas of WordPress where established products have years of development, enormous user bases and teams maintaining compatibility and security. Replacing that with something written on Tuesday afternoon because “we like custom code” is not craftsmanship.
It is Tuesday afternoon.
So the first question is always whether an existing solution genuinely fits.
The important word is genuinely.
Eighty percent can be the expensive option
A plugin that does 80 percent of the job sounds like a good compromise.
Sometimes it is.
Other times the missing 20 percent is the entire reason the project exists.
Imagine a catalogue where the client needs products organised in a particular way, imported from existing data, displayed through a custom finder and managed without turning WordPress into an unfamiliar back-office system.
An off-the-shelf catalogue plugin may provide products, categories, filters and search. On paper, that looks very close.
Then the real requirements arrive.
The data model is different. The filtering logic is different. The imported content already has relationships that must be preserved. The client does not need a shopping cart. The frontend has to match a bespoke design. The administration screen needs to expose three fields the generic plugin hides among forty-seven settings.
At that point you are no longer configuring the plugin.
You are negotiating with it.
Sometimes custom development begins when adapting the existing solution becomes more complicated than solving the actual problem.
This is how our own plugins tend to start
Most Delicious software has not begun with somebody sitting down and announcing, “Today we shall enter the software industry.”
It starts with a website project.
A client needs something. We look at the available options. We test the obvious approaches. Then we discover that the cleanest solution is a small purpose-built system.
The small system works.
Then another project needs something similar.
Then we realise the useful part is not specific to the first client at all.
That is how an internal solution starts becoming a product.
Our catalogue tools grew from real product-management requirements. Delicious Forms grew from wanting much more control over enquiries, delivery status, attribution and how submissions are stored. Delicious Slider grew from interactions we wanted to behave in a very particular way rather than accepting whatever behaviour happened to come bundled with an existing slider.
Delicious Gallery followed the same logic. Hosting Manager came from the operational reality of managing hosting rather than from brainstorming plugin categories on a whiteboard.
Real problems are surprisingly good product managers.
Forms are a perfect example
A contact form sounds like one of the last things WordPress needs another plugin for.
There are excellent form plugins. We have used them.
But a form becomes something different when the enquiry itself is operational data.
For one of our current projects, we wanted every successful submission saved to the WordPress database before email notification was attempted. The enquiry needed a sequential contact ID. We wanted to know which form generated it, which exact page it came from, the landing page, referrer and campaign attribution. Notification delivery needed its own sent or failed status, timestamp and recipient, with the ability to retry delivery without losing the original enquiry.
That is no longer simply “send these five fields to an email address”.
It is a small lead-management system.
Could we assemble that from an existing forms plugin, add-ons, hooks, custom snippets and another plugin for SMTP?
Probably.
At some point, however, the architectural diagram starts looking like somebody dropped a bowl of spaghetti behind the server rack.
Building the system ourselves means the database-first behaviour is not an add-on to the design. It is the design.
Owning the code changes the debugging conversation
There is another advantage to purpose-built software that becomes obvious only after something goes wrong.
You can trace it.
When a site depends on a chain of unrelated plugins, a bug can turn into an archaeological expedition.
Plugin A generates the content. Plugin B modifies it. Plugin C intercepts the request. Plugin D optimises the result. A theme adds its own behaviour. Everything works until an update changes one assumption buried somewhere in the middle.
Then everybody points politely at everybody else.
With software we own, we can inspect the actual data path. We know why the architecture exists. We can change the source rather than stacking another workaround on top of a workaround.
That does not magically prevent bugs.
It does make them ours.
Strangely, that is often preferable.
Less software can mean a simpler website
People sometimes hear “custom plugin” and imagine more complexity.
It can be the opposite.
A focused plugin might contain exactly the functionality a project needs and nothing else. There may be fewer settings, fewer dependencies, fewer assets loading on the frontend and fewer opportunities for unrelated features to interact.
A general commercial plugin has to serve thousands of customers with thousands of possible requirements. That flexibility is its strength.
It is also why the settings screen occasionally resembles the cockpit of a Boeing 747.
Purpose-built software can afford to be opinionated.
If a client only needs six controls, giving them six excellent controls is often better than giving them 106 controls and a training video explaining which hundred not to touch.
But custom code has a cost
This is the part developers should not conveniently forget.
If you build it, you own it.
You own compatibility. You own security. You own testing. You own updates. You own the phone call when WordPress changes something three years later.
A reputable established plugin spreads those responsibilities across a product team and a large customer base. Custom software concentrates them on the developer who created it.
That is why we do not build custom plugins simply because we can.
The benefit has to justify the responsibility.
For a one-off requirement that a reliable existing plugin solves cleanly, buying the plugin is often the sensible engineering decision.
For functionality that is central to the project, unusually specific, likely to evolve or awkwardly served by existing tools, owning the architecture can be worth considerably more.
There is a middle ground too
Not every custom solution needs to become a giant standalone product.
Some of the most useful WordPress development is deliberately small.
A migration utility that exists only to move one complicated site safely. A custom content importer. A tightly scoped integration. A module that presents existing data in a particular way. A management screen that makes an awkward workflow simple.
These tools may never appear in a public marketplace.
They do not need to.
Their value is that they remove friction from the project they were built for.
Sometimes the best plugin has exactly one customer.
Then occasionally the one-customer plugin escapes
This is where things get interesting.
Once you have solved a problem properly, you start noticing the shape of the solution.
Which parts belong specifically to the original project? Which parts are broadly useful? Could the configuration become generic? Would another designer, developer or business understand the interface without knowing the story behind it?
That is the point where internal software can become commercial software.
It also changes the standard you build to.
The interface needs more explanation. Defaults matter more. Error handling matters more. Security assumptions need to survive environments you do not control. Updates and backwards compatibility become product concerns rather than project concerns.
The little tool that solved Tuesday's problem has acquired responsibilities.
Congratulations. You now have a software product.
AI has made custom development more practical, not automatic
AI has also changed the economics of this decision.
We can analyse code faster, trace interactions across larger projects, generate repetitive scaffolding, inspect unfamiliar APIs and test implementation ideas more quickly than we could a few years ago.
That makes purpose-built development practical in situations where the time cost might once have pushed us toward a less suitable generic solution.
But the same rule applies here as everywhere else with AI.
Faster code generation is not architecture.
You still need to decide what the plugin should own, how data should be stored, what happens when something fails, which permissions are required, how the interface behaves and what future updates are likely to break.
AI can help build the machine.
Somebody still needs to know what machine they are building.
So when do we build instead of install?
There is no heroic answer.
We build when the project earns it.
When an existing plugin solves the problem well, we use it.
When several plugins would have to be stitched together to imitate one coherent feature, we look harder at custom development. When the missing functionality is central rather than peripheral, custom becomes more attractive. When owning the data model, interface or behaviour gives the client a meaningful long-term advantage, it becomes more attractive again.
And when the solution turns out to be useful beyond the original project, sometimes it joins the Delicious software family.
That is how we prefer software ideas to arrive.
Not because a market-research spreadsheet says the world needs plugin number 60,001.
Because we encountered a real problem, tried the sensible options and eventually reached that dangerous WordPress sentence from the opposite direction:
There isn't quite a plugin for that.
Fine.
We'll build one.
