We build custom WordPress plugins to core coding standards, with tests, documentation, and a real update path, so the thing still works after the next WordPress release. Our own plugins run on more than 10,000 sites, which is where the standards come from.
“We’re using six plugins to do one thing.”
Consolidation is usually cheaper to maintain than the stack you have now. See the scoping sprint
“A previous developer left us code nobody can read.”
We audit, document, and either refactor or replace it. Scoping tells you which. See how it runs
“We need to sell or distribute the plugin.”
Licensing, updates, and a release pipeline are part of the build, not an afterthought. See the plans
“We just need a small snippet.”
Then don’t buy a plugin build. Ask us and we’ll probably tell you for free. Read who this isn’t for
These figures cover every Gatilab service, not this one alone. We’d rather say that plainly than imply a per-service record we haven’t published.
Brands we’ve delivered work for
Fixed-price plugin builds without a scoping stage are how both sides end up unhappy. The sprint is deliberately separable, and its output is yours to take elsewhere.
For teams who need a technical spec, an estimate they can budget against, and a second opinion on the approach.
1 to 2 weeks
The fee is credited against a build booked within 60 days.
For internal tools, client-specific functionality, and integrations that no off-the-shelf plugin covers properly.
Scoping included · 4 to 8 weeks typical
Fixed scope means fixed price. Change requests get quoted, never silently absorbed.
For plugins in active use where WordPress releases, PHP upgrades, and feature requests keep arriving.
3-month minimum
You keep the repository. Cancel and nothing about it becomes inaccessible.
Custom development goes wrong when the client cannot see progress. Every milestone here is inspectable.
Weeks 1 to 2
Requirements get mapped to concrete use cases, then to a data model and a hook design. We decide what the plugin deliberately will not do, which matters more than the feature list.
You leave with: A written technical spec and a milestone estimate.
Weeks 3 to 6
Work happens in your repository, in reviewable commits, against core coding standards. You see progress continuously instead of receiving a zip file at the end.
You leave with: Repository access and a working build at each milestone.
Week 6 to 7
PHPUnit tests cover the logic, PHPStan catches type problems, and documentation gets written for both developers and the people who’ll use the admin screen.
You leave with: A test suite you can run and docs written for two audiences.
Week 8
Versioned release, update mechanism configured, and a handover walkthrough. Copyright assignment is in writing.
You leave with: The code, the copyright, the docs, and a release pipeline.
Custom development is the easiest place to overbuy. Two of these are reasons we say no.
Something not covered? Ask directly and you’ll get a straight answer, not a calendar link.
You do, including copyright, assigned in writing at handover. The repository is yours from day one and we work inside it. We keep no licence that requires you to stay with us, because code you cannot leave with is leverage, not a deliverable.
Because a fixed price quoted before anyone understands the problem is either padded or about to become a dispute. The sprint produces a spec detailed enough to quote against, and it’s deliberately portable. If you take it to a cheaper developer, that’s a legitimate outcome and you’ll have spent $1,500 to avoid a much more expensive mistake.
That’s what the standards and the test suite are for. Building against documented core APIs rather than undocumented internals is the difference between a plugin that survives an update and one that breaks. Our own plugins run on more than 10,000 sites, and that number is why we work this way.
Yes, and it’s often the best arrangement. We work in your repository with your review process. Your team learns the codebase as it’s built rather than inheriting something unfamiliar, which is the usual failure mode of outsourced development.
Yes. Distribution adds licensing, an update server, support documentation, and repository guidelines compliance to the scope. Say so during scoping, because retrofitting a licensing and update layer afterwards costs considerably more than designing it in.
Small changes get quoted individually. If requests are arriving steadily, the maintenance retainer is cheaper than a series of small quotes and gives you a named response time. We’ll tell you honestly which pattern you’re in after the first month.
Send the problem in your own words, along with whatever you’ve already tried. If an off-the-shelf plugin solves it, we’ll name the plugin and tell you not to hire us.
Free to download, no email required. Custom development means custom disputes about ownership and scope. Settle both in writing first.
Scope, change control, IP transfer on final payment, and a termination clause. Use it on whoever builds your site.
The structure a proposal should follow, so you can tell a considered quote from a padded one.
If you would rather have this done than do it yourself, tell us what you are working on. If not, the templates are still yours.
