Services / Custom Development
Not everything needs a plugin. When your requirements exceed what off-the-shelf solutions can deliver cleanly — or when an existing plugin is delivering five things you do not need in order to do the one thing you do — I build exactly what is needed and nothing more. Code that is readable, documented, and maintainable by whoever works on your site next.
PHP, JS, HTML, CSS
Languages
PSR-12, WPCS, WCAG 2.2, W3C
Standards
Lean, documented, maintainable
Approach
The case for custom
The WordPress plugin ecosystem is vast, and the right plugin for a common requirement is usually a better choice than custom code. But plugins are built for a general audience. When your requirement is specific — a custom product type, a data integration with a proprietary system, a checkout modification that conflicts with the assumptions built into every available plugin — a plugin is the wrong tool.
Every plugin you install is a maintenance obligation: updates to apply, compatibility to verify, potential security vulnerabilities to monitor. A small, focused piece of custom code that does precisely what you need has none of that overhead and introduces none of the conflict risk that comes from third-party code interacting with the rest of your stack.
I write code to WordPress Coding Standards and PSR-12, with inline documentation where the behaviour is non-obvious. The goal is always a codebase that your next developer can read, understand, and maintain without having to contact me.
What is included
All development work begins with a requirements discussion and a written specification. I do not begin building until we agree on exactly what the code should do. Fixed-price engagements only.
Functionality built to your exact specification, coded to WordPress Coding Standards, documented, and built so your next developer can maintain it without needing to contact me. Micro-plugins that do one thing cleanly are frequently the right architecture. I do not build monolithic plugins that accumulate features over time and become maintenance liabilities.
Customisations that survive parent theme updates. No hacking core files, no brittle overrides that break on the next update cycle. I work primarily with GeneratePress and have deep familiarity with its hook system, but the child theme methodology applies to any parent theme. Every customisation is implemented at the correct layer: CSS variable overrides, template part replacement, or action hook, rather than brute-forced with specificity hacks.
Connecting WordPress to external services, CRMs, automation platforms, and third-party APIs. I build integrations correctly: authenticated, rate-limited, error-handled, and resilient to the external service going down. Webhooks, polling, and event-driven integrations are all within scope. I have experience building integrations with GoCardless, n8n, and bespoke internal systems.
Custom product types, modified checkout flows, bespoke shipping logic, and payment gateway integration built to fit your exact business process rather than bending your process to fit the plugin. WooCommerce customisation requires thorough understanding of its hook architecture. I do not override core WooCommerce templates where a filter achieves the same result more maintainably.
As a former W3C Invited Expert in web accessibility, I identify and fix WCAG 2.2 failures systematically, not cosmetically. This means resolving the underlying HTML structure and interaction patterns that cause accessibility failures, not adding ARIA attributes over inaccessible markup and calling it done. Remediation engagements include a post-fix audit against the original findings to verify resolution.
Inheriting a WordPress codebase from a previous developer and not confident in its quality or security? I conduct structured code reviews against WordPress Coding Standards and current security best practice, producing a prioritised findings report. Legacy code modernisation, including replacing deprecated functions, eliminating security vulnerabilities, and restructuring for maintainability, is scoped from that review.
Who this is for
You have a specific functional requirement that every available plugin almost fulfils, but with unwanted features, conflicts, or performance overhead that makes it unsuitable.
Your site has accumulated customisations from a previous developer that are breaking on updates and need to be rebuilt correctly.
You need to connect WordPress to an external system, a CRM, an automation platform, or a payment processor, and need it done correctly the first time.
Your site has known accessibility failures that are a legal or contractual obligation to fix, not a nicety.
You run WooCommerce with a checkout flow or product type that the standard plugin cannot accommodate without heavy workarounds.
You have inherited a codebase and want an expert assessment of its quality and security before continuing to build on it.
FAQs
All custom development is fixed-price, based on a written specification. I do not work on a time-and-materials basis for development projects. The specification phase, where we agree exactly what the code should do, is included in the project. You receive a fixed price before any code is written.
Yes. That is a design goal, not an afterthought. Code written to WordPress Coding Standards with appropriate inline documentation should be readable and maintainable by any competent WordPress developer. I deliberately avoid clever or obscure patterns in favour of straightforward, conventional implementations that are easier to read and debug.
Yes, though I typically begin with a code review to understand what exists and assess its quality before committing to a scope. Inheriting code from an unknown source without reviewing it first is how technical debt accumulates. The review gives us a clear picture of what can be extended and what needs to be rebuilt.
No. My focus is engineering: performance, security, development, and troubleshooting. I do not take on design-led website builds where the primary deliverable is a new visual design. If you need both engineering work and a new design, the right approach is to engage a designer for the design work and bring me in for the technical implementation.
Public sector bodies in the UK are legally required to meet WCAG 2.1 AA under the Public Sector Bodies Accessibility Regulations 2018. Private sector businesses have obligations under the Equality Act 2010, which does not specify a technical standard but treats inaccessible digital services as potential discrimination. WCAG 2.2 is the current W3C recommendation and the appropriate target for new work.
From the blog
There is a moment in every growing ecommerce business when the infrastructure that got you here starts working against you. A plugin added to handle a...
Forty-two percent of UK B2B businesses have no ecommerce tech stack in place. That figure comes from The Inevitable Shift report, produced by Commerce...
If you run a WooCommerce store and spend money on TikTok ads, you have probably seen the headlines about TikTok’s new paid subscription. The natural...
Tell me what you need it to do. I will tell you whether custom code is the right answer and what it would cost to build it properly.
