Service Custom plugins
PSR-4, dependency injection, PHPUnit tested, WPCS clean. Built by a team that maintains 100+ plugins in production, including WordPress.org listings used by tens of thousands of sites.
<?php
namespace Wbcom\Custom\Service;
use Wbcom\Custom\Contracts\Notifier;
use Wbcom\Custom\Models\Subscription;
final class SubscriptionRenewal {
public function __construct(
private readonly Notifier $notifier,
private readonly \wpdb $wpdb,
) {}
public function process( Subscription $subscription ): void {
if ( ! $subscription->is_due() ) {
return;
}
$this->wpdb->query( 'START TRANSACTION' );
try {
$subscription->charge();
$this->notifier->send_receipt( $subscription );
$this->wpdb->query( 'COMMIT' );
} catch ( \Throwable $e ) {
$this->wpdb->query( 'ROLLBACK' );
throw $e;
}
}
}
Why this matters
They die because nothing about them is documented, the code is one giant functions.php fork, and the next developer spends a week understanding why anything works before they can fix anything that does not. By month three the recommendation is always the same: rewrite it.
Plugins we ship read like proper PHP packages. Namespaces, classes, tests, docs, deploy pipeline. The next developer reads the README, runs the test suite, and ships a fix the same day. Code that outlives the engagement is the only code worth writing.
What we build
Modern PHP, proper structure, tests in CI, accessibility and security baked in. Distribution model that matches your business model. Code your team can extend without us.
01
No more 500-line procedural files. Plugins built as proper PHP packages with namespaces, autoloading, dependency injection, and PHP 8.2+ type hints. Read like Laravel, run like WordPress.
Junior devs can extend the plugin three years in.
02
WordPress Coding Standards enforced in CI. PHPStan at level 5 with WordPress stubs. No deprecated function calls, no missing docblocks, no escaping bugs. Every commit passes the gates.
Code passes WordPress.org plugin review on first try.
03
WP_UnitTestCase based tests on the paths that matter. Database roundtrips, REST endpoints, hook integrations, capability checks. Run on every PR through GitHub Actions.
Refactors do not break shipped features.
04
Settings page in the modern card pattern. Admin UI with React in @wordpress/components. REST endpoints with proper auth. Gutenberg blocks where the editor needs them. All shipped together.
Plugin feels like a first-party WordPress feature.
05
Every string translatable. Every form labeled. Every input sanitized, every output escaped. Nonces on every state change. Capability checks on every privileged action. WCAG AA on every UI.
Plugin works for global audiences and security audits.
06
We ship plugins to WordPress.org with svn release pipeline, or as private plugins distributed through EDD with license activation, or as headless plugins consumed by your headless frontend.
Distribution model matches business model.
100+
WordPress plugins shipped to production across our agency portfolio
25+ on WordPress.org. Tens of thousands of active installs. Source code public.
Plugin bootstrap
One Plugin class, dependency container, hooks registered through services. No 500-line procedural file. New developer reads the bootstrap and immediately sees the surface area.
<?php
namespace Wbcom\Custom;
use Wbcom\Custom\Admin\SettingsPage;
use Wbcom\Custom\REST\SubscriptionsController;
use Wbcom\Custom\Service\Container;
final class Plugin {
public static function bootstrap( string $file ): void {
$container = new Container( $file );
add_action( 'init', fn() => ( new Blocks\Registry( $container ) )->register() );
add_action( 'rest_api_init', fn() => ( new SubscriptionsController( $container ) )->register_routes() );
add_action( 'admin_menu', fn() => ( new SettingsPage( $container ) )->register() );
register_activation_hook( $file, [ Lifecycle\Activator::class, 'activate' ] );
register_deactivation_hook( $file, [ Lifecycle\Deactivator::class, 'deactivate' ] );
}
}
Process
01
One to two weeks. Feature spec, data model, hook surface, integration plan, distribution model, success criteria. Output is a fixed price quote.
No scope creep mid-build.
02
Four to twelve weeks depending on scope. Tests written alongside features. WPCS and PHPStan green on every commit. Staging plugin available within seven days.
Every commit passes the quality gates.
03
One to two weeks. WordPress.org submission or EDD release pipeline. README, code-level docs, end-user documentation. Handover call with your team.
Your team owns the plugin from day one.
Common questions
PSR-4 namespaces, dependency injection, single-responsibility classes, no global state. Same patterns Laravel and Symfony use. WordPress core calls into our plugin through proper hooks, our plugin calls back into WordPress through facade-style wrappers.
Yes. We test against WordPress trunk in CI alongside the latest stable. Deprecated functions get fixed before they go away, not after they break the plugin. Annual minor maintenance is included in our retainer.
Yes. We have shipped extensions for both, and for LearnDash, MemberPress, Easy Digital Downloads, GiveWP, and most major plugin ecosystems. Discovery call covers the integration surface and the third-party plugin compatibility plan.
When that is the right distribution channel. We have shipped 25+ plugins to WordPress.org and know the review process well. For paid plugins, EDD with license activation is the more common path.
Yes. Code lives in your GitHub repo from day one. We push directly to your repo, not ours. After delivery, your team owns the codebase, the WordPress.org listing if applicable, and the deployment pipeline.
Focused plugin builds (one core feature, settings, REST, blocks) are scoped per project. Full plugin suites with admin UI, multiple post types, integrations, and WordPress.org submission are scoped after discovery. Discovery call is free.
Need a plugin that lasts?
Discovery call is free. Fixed-price quote within 48 hours. Projects are scope-dependent.