Custom WordPress Plugin Development: Fixed Prices, Build vs Buy

Custom WordPress plugin development means we write a plugin from scratch — usually because nothing on the .org repository does what you need, or because you don’t want a $300/year subscription to a 50-feature plugin for the one feature you actually use. This page covers what we build, what it costs, and the decisions worth making before you commission a plugin instead of buying one.

Before you commission anything: build vs buy

Most plugin work that lands in our inbox shouldn’t actually become a custom plugin. The first conversation we have with every new client is whether something on the .org repository already covers 80% of the need. If it does, paying us $4,000 to rewrite it is wasted money. We’ll point you to the existing plugin and call it done.

Custom plugin development makes sense when one of these is true:

• The feature you need doesn’t exist anywhere — true for maybe 10% of plugin requests we get
• An existing plugin does it but the licence model is hostile (a $500/year subscription for one form, a per-site fee that doesn’t scale to your 12 client sites, GPL conflicts with your distribution)
• The plugin you’d buy has 200 features and your performance budget has 1 — we strip it to just the one
• You need code on your repo, on your terms, with no third-party dependency
• The plugin needs to integrate with internal systems (your CRM, your warehouse, your custom Magento bridge) where no public plugin will fit

What we mean by a “plugin”

Roughly four categories, in order of how often we ship them.

Integration plugins (most common)

A plugin that connects WordPress to one external system. Examples we’ve shipped: a HubSpot custom-object sync that the official HubSpot plugin doesn’t cover, an internal CRM bridge that maps Gravity Forms entries to a Pipedrive deal stage, a warehouse-feed importer that pulls product stock from a SOAP API every 15 minutes. These are 80% of our plugin work.

Build time: 2-4 weeks. Lines of code: usually 800-2,500. Distribution: private, installed via Composer or a private GitHub repo.

Editor / admin tools

A plugin that adds features to the wp-admin for editors or admins. Custom block libraries, ACF field type plugins, a workflow plugin that adds a draft-review queue, a content-audit dashboard. Typically not visible on the front end.

Build time: 1-3 weeks. Lines of code: 500-2,000 including the React block code if there is one. Distribution: usually private, sometimes published to .org if it has wider use.

Front-end / display plugins

A plugin that adds a feature visible to site visitors. Custom search with Algolia or Elasticsearch backend, a member-only content gate, a custom subscription manager. Less common than the above two because these usually exist as commercial plugins already, and our job is to argue you out of building it.

Build time: 2-6 weeks. Lines of code: 1,500-5,000. Distribution: private repo, occasionally .org if the use case is generic enough.

Full custom modules (rare)

A plugin that’s effectively a whole application — a custom booking engine, a B2B quote system, a multi-vendor commission tracker. The kind of project where we’ll ask whether you should be on Laravel or a SaaS platform instead. If WordPress is still the right host, we’ll build it, but the budget shifts to the upper end.

Build time: 6-14 weeks. Lines of code: 5,000+. Distribution: always private.

Pricing brackets

Small plugin — $1,500 to $3,500, 1 to 3 weeks

Integration plugins under 1,500 lines, simple editor tools, custom block libraries with under 10 blocks. Includes settings page, basic unit tests for the API layer, README.md, and a developer handover doc.

Medium plugin — $4,000 to $9,000, 3 to 6 weeks

Larger integrations, front-end display plugins, plugins with a custom database table. Includes admin UI in React, comprehensive PHPUnit tests, GitHub Actions CI, semantic versioning, and 30 days of post-launch support.

Full module — $10,000 and up, 6 to 14 weeks

Custom applications living inside WordPress. Includes architecture review, custom database schema, REST API endpoints, React-based front-end, full PHPUnit + Playwright test suite, GitHub Actions deploy, 60 days of post-launch support.

The stack we use when we own the choice

PHP target. PHP 8.1 minimum for new plugins. We use typed properties, enums where they fit, and named arguments. We don’t ship plugins that need PHP 5.6 — the WordPress core support window is long enough without us extending it artificially.

Composer for dependencies. Every plugin has a composer.json with PSR-4 autoloading. We vendor php-scoper’d dependencies into a unique namespace so our Guzzle doesn’t fight your other plugin’s Guzzle. The pain of plugin conflict in production isn’t worth saving 20 minutes of build setup.

React for admin UIs. The WordPress core team built @wordpress/scripts and @wordpress/components and they work fine. We use them instead of bundling our own React build. Block development goes through @wordpress/create-block with TypeScript on bigger projects.

Testing. PHPUnit with the wp-phpunit test suite for the PHP side. Brain Monkey for mocking core functions. Playwright for end-to-end where the plugin has a real UI. GitHub Actions running the tests on every PR. We don’t skip tests on “small” plugins — it’s the small plugins that break silently in WP 7.0.

Coding standards. WordPress Coding Standards with a sensible deviation list: we allow short array syntax ([]), we ignore the “Yoda condition” warning, we run PHP-CS-Fixer on top. CI fails the PR if any of these regress.

What a plugin project looks like, week by week

This is for the Medium bracket — the most common — assuming a 4-week build.

Week 1 — scope and architecture

2-hour call to walk through the requirement. We write a 2-3 page brief: what the plugin does, what it doesn’t do, the API surface we’re committing to, the database schema if applicable, the settings UI. You sign the brief before code starts. We set up the repo, the CI, and a stub plugin that activates on a local WordPress.

Weeks 2 to 3 — build

Feature branch per major component. PR descriptions explain the change, the test coverage, and any decision worth noting. We tag a v0.x.y release at the end of every week so you can install it on your staging site and click through. Feedback loop usually 2-3 days.

Week 4 — QA, docs, handoff

Final round of QA against the staging site. Plugin gets a tagged v1.0.0 release on the private repo. We write a README that covers install, configuration, hooks (filters and actions you can use to extend the plugin), and the upgrade path for future major versions. 30-minute call walking your dev team or maintainer through the code.

What you get at handoff

• Tagged v1.0.0 release on a private GitHub or GitLab repo (your account, not ours)
• A composer.json so the plugin can be installed via composer require on Bedrock-style WordPress setups
• README.md with install, configuration, and extension docs
• The PHPUnit and (if applicable) Playwright test suite
• GitHub Actions workflow that runs tests on every PR
• A 30-minute video handover for your maintainer
• 30 days of post-launch support (60 for Full module bracket)
• Licence: GPL v2 by default (WordPress core requirement). We can ship dual-licence if you need a commercial proprietary track — talk to us.

Distribution: WP.org vs private vs Composer

Three options, three reasons to pick each.

WP.org repository if the plugin is generic enough that other people might use it and you want the free marketing. Downside: the review queue takes 2-12 weeks, the .org repo doesn’t like aggressive marketing in the readme.txt, and security disclosures go through the .org security team.

Private GitHub or GitLab repo if the plugin is yours alone and you want full control. We default here for client work. Updates go through manual upload or a tool like PluginKit if you want self-hosted update servers.

Composer-only if you run Bedrock-style WordPress and you want to install plugins through composer require from a private repo. Cleanest for agencies managing multiple client sites. We do this for our own internal plugins.

When NOT to hire us

• Budget under $1,500. Below that price, hire a freelancer on Codeable or a Fiverr Pro for a one-shot script. We won’t break even on the contract overhead.
• You want a WordPress plugin to do a SaaS product’s job. If the plugin needs multi-tenancy, billing, separate user accounts per tenant, you’re building a SaaS. WordPress is the wrong host. We’ll point you at Laravel or RedwoodJS instead.
• You want to clone a paid plugin to avoid paying for it. Yoast SEO Premium, WPForms Elite, MemberPress — each of those took years to build. We won’t rebuild them for a discount.
• The integration target has no public API. Reverse-engineering proprietary endpoints is brittle and risks the breaking change you can’t fix. We’ll push back to wait for a real API or build a different integration.

How this connects to the rest of our work

Custom plugins usually ship inside a larger project. The integration plugin lives on a site we built through our WordPress development services. The migration plugin runs as part of a WordPress migration from a CMS the .org importers can’t handle. Standalone plugin commissions exist, but they’re maybe 20% of what we do — most plugins are scoped during a build or migration discovery call.

If you have a plugin idea, the form below is the fastest way in. Drop the source system the plugin connects to (or just the problem you’re solving), the rough budget you’re working with, and the deadline. We’ll reply within one business day with either a discovery call or an honest “this exists on .org for free, install it and move on.”