Why build a private plugin when a free one already does something similar?

If a maintained plugin covers your requirement, we say so and configure it. We write custom code when the missing behaviour is the part your business actually depends on, or when the existing options would need four more plugins to reach the same result. A private plugin does one job, has no upsell banners, and can be handed to another developer without reverse engineering someone else's product.

What happens to my plugin when the platform updates?

It should keep working, and we plan for that from the first commit. We hook into documented actions and filters instead of editing core files, keep custom data in structures that survive updates, and test the module against the current platform release on a staging copy before you install anything in production. If a platform update does break something, the plugin is small enough that the fix is usually a short job.

Can you take over a plugin that a previous developer built or abandoned?

Yes. We read the code, map what it touches, and give you a written summary of the risks before changing anything: unescaped output, direct core edits, API keys in the code, or a fork that no longer tracks its upstream. After that we either stabilise it in place or rebuild the parts that cannot be maintained.

Do we own the plugin, and can we publish or sell it?

You own the code and the repository, whether the plugin stays private or goes to a marketplace or package registry. We set up the accounts under your ownership and hand over the build scripts and documentation. Some of our own components are published publicly, so we know what distribution, versioning, and licence files involve.

How long does a browser extension take compared with a WordPress plugin?

The build is often comparable, usually one to three weeks for a focused extension. The difference is review. Chrome, Firefox, and Edge each inspect permission requests, and an extension that asks for broad host access gets sent back with questions, so we scope permissions to the narrowest set the feature needs and plan for a review round.

Custom Plugin & Extension Development

Private WordPress plugins, WooCommerce add-ons, Shopify apps, and browser extensions built to fit your existing platform and its update cycle.

See our work:

React Support Ukraine Banner→CUSTOM BOX→

Most platforms do the job you bought them for. The gap that starts a project like this is narrower: a checkout that must collect one extra field before payment, an admin screen your team rebuilds by hand every Monday, a supplier portal that only exports PDFs. Buying a full product to cover that gap means running a large system for one screen.

A private plugin, add-on, or browser extension closes the gap on the platform you already run. We build them for WordPress and WooCommerce, for Shopify, for the browsers your staff work in, and for internal tools maintained by your own developers. The visible surface is small. The judgement sits in what happens after launch, when the platform updates and your module has to keep working.

What we build

WordPress plugins for custom post types, admin editing screens, scheduled jobs, and REST endpoints other systems call. A common shape is an ordering flow that writes to a CRM and produces an invoice, which off-the-shelf plugins handle partly or by pulling in three more plugins that each need their own updates.

WooCommerce add-ons for pricing rules, shipping calculations, extra checkout fields, and payment gateway behaviour. The rule that matters is specific to your product mix, your courier, or your accounting process, which is why settings screens do not cover it.

Shopify apps and checkout extensions that add an admin block, a webhook consumer, or a step the theme cannot reach alone, shipped through Shopify's app review.

Browser extensions for Chrome, Firefox, and Edge on Manifest V3, for teams who move data between an external portal and an internal system. A content script that reads one page needs far less access than a background worker watching every tab, and the narrow request clears review sooner.

Reusable components published to npm or a private registry, so three teams do not rebuild the same widget. We also write modules that extend internal tools: a dashboard your company built in-house, or an open source platform customised for one business.

Who this is for

Teams running a platform that already covers most of their process. That usually means a WordPress site with one non-standard workflow, a WooCommerce store with unusual pricing, a Shopify merchant whose fulfilment step does not exist in the admin, or an operations team pasting data between two browser tabs all day.

A plugin is the cheaper container when a full custom application would be wasteful. If your requirement is a product with accounts, billing, and its own interface, that is custom web application development.

What we deliver

Scoping against plugins you already run

Before writing code we inventory what is installed: plugins, theme overrides, and any custom code a previous developer left behind. That inventory points to one of three paths. Configure the plugin you already pay for. Write a small companion plugin that hooks its filters, so updates keep flowing from upstream. Or fork it when the maintainer will not take your change, with the cost stated plainly: a fork becomes yours to carry through every release.

Update safety

We work through documented actions and filters. We do not edit core files or a theme we did not commission, because the next update erases that work. Custom data lives where it survives updates, in post meta or its own table with a migration routine, instead of a serialised blob in one option row. The readme records the platform version and the PHP or Node version the module was tested against.

Data migration and permissions

If the plugin replaces a manual process, the existing records come with it. We write the importer, run it against a copy of your database first, and keep a rollback path until you have checked the output. Permissions get the same attention as features: capability checks on admin actions, nonce verification on forms, sanitised input, escaped output, least-privilege OAuth scopes, and credentials stored server side. A browser extension is readable by anyone who installs it, so anything bundled into it counts as public.

How the engagement runs

The first week is discovery. We inventory the platform, write a spec for the missing behaviour, and decide build against configure. You get a scope with the assumptions written down, including the parts that depend on a third-party plugin.

Build runs in short cycles against a staging copy of your site or store, so each piece is clicked through on the real platform. Before handover the module is installed on staging with the latest platform release, and the upgrade path from your current version is tested.

Handover includes the repository, the build scripts, and the account credentials, all under your ownership. The documentation covers what the plugin does, which hooks it uses, and what to check after a platform update.

What it costs

Work runs at our flat rate of $39 per hour, or as a fixed scope once the spec is agreed. Cost follows the platform's constraints more than the size of the feature on screen. A WordPress plugin with one admin screen is often a few days of work. A WooCommerce add-on that touches shipping, tax, or a payment gateway, or a Shopify app with OAuth, webhooks, and app review, is normally a two to four week build. Browser store review adds calendar time on top of development.

Any module in production needs attention, because the platform under it keeps moving. WordPress releases land several times a year, PHP support windows shift, Shopify deprecates API versions on a published schedule, and browser stores change their manifest requirements. That work fits a maintenance retainer, described on the website maintenance and support page, or a monthly capacity plan from $2,699 for teams with a standing queue of platform work. The pricing page explains both models and what each includes.

Proof

React Support Ukraine Banner is a small open-source React component, published to npm, that displays a UNITED24 support banner on any site. What keeps it in the extension category is its shape: no backend, no database, no user accounts. A host project imports one component, overrides the styling if it wants to, and that is the whole product: one component with a documented API. Version 1.1.0 shows what public maintenance involves, because the component was rewritten in TypeScript and the separate CSS import was dropped, so existing projects could upgrade without tracking a stylesheet. After launch the obligations are React version support, triage of issues filed by strangers, and a release whenever a change would break an existing import.

Custom Box is an Objective-C iOS app we built for BandC IND., a Manhattan packaging company, so their sales team could price custom-sized boxes during a customer conversation. It extends the systems the company already had: we made it compatible with them and fitted it into daily operations, and it serves one sales team with one calculation instead of a market of end users. Maintenance for a private tool like that is less visible and easier to postpone, because the app depends on iOS and Xcode releases, on App Store distribution rules, and on pricing logic that follows the company's costs for board, print, and box sizes. The case study notes that the original product is no longer presented as a live service, which is what happens to an internal tool when nobody owns its next update.

Related services

WordPress development for themes, WooCommerce stores, and full builds around a custom plugin
Web development for the wider front-end and back-end work we take on
API development and integration when the plugin must talk to a CRM, ERP, or payment provider
WordPress setup and customization to configure an installation before new code is written
Open source component development when the module is meant to be published and reused beyond your project

Next step

If a plugin in your stack almost does what you need, send us the plugin name, the platform and version, and the missing behaviour. We will say whether to configure it, extend it, or replace it, and what each path costs to maintain.

Contact us with those details, or put the requirement through the Vasilkoff.info estimator for a first scope and cost range.