WordPress plugin development of any complexity
WordPress plugins of any complexity: built from scratch against a spec, existing ones extended, WooCommerce extensions and Gutenberg blocks. The code follows the WordPress standards, the source lives in your repository — and how it is written is visible in the open projects before you order anything.
- 5 plugins
- published, code open
- 42 projects
- on WordPress, in the archive
- Open code
- read it on GitHub before you order
Why
When the directory falls short
The ready-made one drags extras
A plugin with forty features for the sake of one: extra tables, extra scripts on every page, extra surface to attack. One written for the task does a single thing — and that is all.
The right one does not exist
An integration with a local courier, an exchange with a self-written accounting system, a report shaped to one particular bookkeeping — the directory does not have it and never will.
Two ready-made ones fight
Each works on its own; together they break each other. A bridge plugin that reconciles the two is ordinary custom work.
The author is gone
The plugin is abandoned, three years without updates, creaking on the current WordPress. Two ways out: replace it with a maintained analogue, or take the code over — both are part of this service.
The scope
What the work includes
A plugin from scratch
From the spec to working code: the architecture, the admin screens, the permissions, the integrations. The spec is written before the start — the handover is checked against it later.
Extending an existing one
Widening, speeding up or fixing somebody else's plugin — through hooks and extension points where possible, so the author's updates do not erase the changes. A fork is the last resort, and from that moment the code is maintained as one's own.
Security
Capability and nonce checks on every action, escaping on output, prepared statements to the database. What the directory's vulnerability reports list most often is closed here by default.
Performance
Settings in a single option rather than a scatter of rows; heavy work on cron rather than on every request; scripts only on the pages where they run.
Compatibility
The WordPress coding standards, current PHP versions, a check on fresh WordPress and WooCommerce before handover. Automated tests where they earn their keep: payments, calculations, critical logic.
WooCommerce
Extensions for the store
A store is always a little more than WooCommerce out of the box. Extension work is the same work that shows in the open WC Regional Catalog: prices and a catalogue per city, with a feed per region.
Payment and delivery
Payment gateways for local banks, delivery rules built on carriers' real tariffs, statuses that match the warehouse's process.
Prices and the catalogue
Regional prices, wholesale rules, personal price lists for B2B — pricing logic the core does not have, written on top of it without touching the core.
Data exchange
Synchronisation with the accounting system, feed exports, stock imports on a schedule — the store stops living a life separate from the books.
Gutenberg
Blocks for the editor
The editor is as good as its blocks. A custom block hands the editor exactly the fields the content needs — and not one more.
A block for the content
A product card, a team, reviews, a pricing table — the editor fills in fields, and the layout comes out right every time.
Variations and patterns
Block variations and ready page patterns: the editor assembles a page from proven parts rather than from a blank canvas.
Server-side dynamics
Blocks rendered on the server — lists, queries, personalisation — stay fast and cacheable.
The handover
What you receive
The code is yours
The source goes into your repository, the rights stay with you. Changing contractors is a change of access, not a negotiation.
Documentation
A README with installation and setup, the hooks and filters described for the next developer.
Warranty fixes
Bugs found within a month of handover are fixed for free. After that — support per request: updates for new WordPress and WooCommerce versions as separate tasks.
A checkable handover
The handover is checked against the spec written before the start — point by point, not by feel.
The price
What it is made of
An estimate against the spec
The task is written down before the start; the price and the date are named against the description and fixed. The task changes — the estimate is revisited, not the other way round.
What moves it
The complexity of the logic, the number of integrations, work with somebody else's code. Extending a foreign plugin often costs more than the same volume of one's own: the code has to be read first.
After the launch
The warranty window is free. Then per request: a task, an estimate, the work. There is no retainer — there is nothing here to pay for by the month.
Questions
Before you write in
Nearby
Which page you need
Start
Fill in the brief
Describe the task as you can — your own words are enough. The reply brings the clarifying questions, an estimate and a date; the spec we write together.