Custom module development
When contrib modules don't fit how your organisation works, a custom module does. I write Drupal modules and Symfony components around your business rules, to Drupal and Symfony coding standards, with tests and documentation, so they stay easy to maintain long after the project ends.
engagement: Fixed-scope project or day rate stack: Drupal 10/11, Symfony, PHP 8.x tests: PHPUnit unit, kernel and functional code: In your repository, yours once paid
Sounds familiar?
- Editors run a process by hand or in spreadsheets that the site should handle
- Data has to move between your website and a CRM, ERP or finance system
- Contrib modules are patched so heavily that every update breaks something
- A third-party API you rely on has no Drupal integration
- Staff or members should sign in with your organisation's identity provider
The work, in detail.
Custom entities and content models
Entity types and fields modelled on your data, with proper access control and Views support, instead of forcing everything into content types.
REST and JSON:API integrations
Endpoints for apps, partners or a decoupled front end, with authentication and documented responses.
CRM, ERP and payment connectors
Syncs that use queues, retries and logging, so a slow or failing third-party system doesn't take your site down with it.
Single sign-on with SAML and OAuth
Login through your identity provider, with roles mapped from the groups your organisation already manages.
Replacing patched contrib with clean code
Heavily patched or abandoned modules replaced with small, focused code that does what you need and updates safely.
PHPUnit and functional test coverage
Tests that run in your CI pipeline, so later changes don't quietly break the module.
From first call to finished work.
Every engagement starts with a free 30-minute discovery call and a written proposal. Nothing starts until the scope, price and terms are agreed in writing.
Discovery
We go through the rules, the data and who uses it. I check whether a contrib module already does the job, and tell you if it does.
Specification and quote
A written specification with acceptance criteria, and a fixed price or a day-rate estimate.
Build in small releases
Work happens in branches on your repository and is shown on staging as it progresses, so you can steer early.
Test, document and hand over
Tests, a developer README and an editor guide, deployed through your normal release process.
Frequently asked.
Why not just use a contrib module?
Often you should. Part of discovery is checking drupal.org first. I only recommend custom code when contrib doesn't fit, or when it would need so many patches that maintaining it would cost more than writing something focused.
Who owns the code?
You do. The code lives in your repository from the first commit, and the intellectual property in it is assigned to you once the invoice is paid in full.
Can another developer maintain it later?
Yes. It follows the Drupal and Symfony coding standards, has tests and a README, and avoids clever shortcuts, so any competent PHP developer can pick it up.
Will you have access to personal data?
If the work means handling personal data, such as user accounts, form submissions or a copy of a live database, we sign a UK GDPR data processing agreement alongside the contract before I get access. Where I can, I work on copies with personal data removed.
Tell me what your site needs.
The first conversation is free and comes with no obligation. Tell me about your site and I'll come back with a written proposal.