Maintenance and quality · Drupal 10, 11 and 12

Drupal maintenance for projects where quality matters.

Built above all for agencies that deliver Drupal projects, though you can also hire me directly as an end client. I am the Drupal technical partner your agency leans on, the quality insurance on what gets delivered: tests, code analysis, performance, security and configuration, worked on every month so no delivery breaks anything. I am the specialist you do not have to hire, a profile that is scarce and expensive. And I fit into the way you already work: everything goes through Git, your team reviews and deploys, and the relationship with your client stays yours. Closed prices, no meetings and no hours to burn through.

A flat monthly fee per project, no surprises

The point of the plan is that your agency stops worrying: about recurring maintenance, about the quality of the code that ships, and about those bugs that slip into production and end up burning the client. The base plan is a monthly Drupal maintenance and support subscription, per project, that covers the five areas every Drupal project needs looked after, for one closed price. If your agency runs several projects, each one gets its own plan. It replaces hour-based Drupal consulting: what agencies used to ask a Drupal consultant for by the hour is folded into the fee. And it works the way maintenance works: recurring monthly effort, detecting and fixing another batch of each area every month, so the technical debt shrinks little by little and the project then stays up to date. It is not a full-time dedication, and it does not mean everything gets fixed in the first month. When you want a backlog cleared now rather than over the months, that is what the acceleration sprints are for: one-off two-week pushes that bring one area up to date in one go. To put a figure on it: done by hand, everything in here is easily some ten working days a month of a senior developer who, depending on the country, charges at least 50 € an hour: that is around 4.000 € a month, and with more senior profiles an equivalent service easily costs more than that. The monthly fee stays under half of that figure because part of the work is done by my own AI agents and skills, made for exactly this service, and that saving is passed on. Nothing they produce is merged into any branch without my review first. From there you only add what your project actually needs: the update rhythm, and the extras.

Everything the monthly plan includes
  • Unit and kernel tests: they check on their own that each change breaks nothing.
  • PHPStan and PHPCS: clean code, cheaper to maintain.
  • Performance and frontend: a faster site on less server.
  • Site configuration: permissions, caching, security and settings kept in check.
  • Three Playwright tests to start: a robot browses your site and warns when something key fails. Plus the upkeep of every test.
  • The DruScan Business dashboard and the set-up, at no extra cost.
4.000 €/mo 1.790 €/mo
Project size does not change the fee. It changes the time. Every month a batch of work gets done, the batch the fee pays for. The more custom code and configuration your site carries, the more findings will turn up and the more months it takes to get everything up to date. A big project does not pay more each month: it pays more months. And when you want to shorten that road, that is exactly what the sprints are for.
Your part of the work is close to zero. You hand me access to the Git repository and an up-to-date copy of the database, and that is it: I do the work and push it to a branch, and your team reviews it and merges whenever it suits them. You delegate it and stop thinking about it.

DruScan, continuous audit of your project

DruScan.com is a web service I built and run myself. You connect your Drupal site to it and it audits it over and over: security, pending updates, configuration, performance and code quality, all turned into a score you can follow over time. It is a paid product, 399 € a year on the Business plan, and because it is mine I include that plan at no cost for as long as we work together. I need the panel to decide what is worth doing on your project, so it makes no sense to charge you for it on top.

DruScan Business plan
  • Environment comparison: the scores of development, testing and production, side by side.
  • Automatic alerts the moment something starts to slip.
  • Ninety days of score history, to see whether the project is getting better or worse.
  • The list of the modules you have installed, with their versions.
399 €/yr Included
It builds on the Audit module. A module I wrote and contributed to the community, free and open source: it audits the project and scores it. DruScan is what turns those scores into history, alerts and a screen you can read without being a developer.
What it checks, in plain terms. It runs 24 audits and scores each area from 0 to 100: pending updates and security advisories, permissions and exposed accounts, caching at every level, database size, errors in the logs, fields and views set up wrong, technical SEO, images, multilingual and code quality with PHPStan, PHPCS and the automated tests. One detail that matters: the analysis runs on your server, and the only things sent to DruScan are the scores and the list of module versions. Your code, your content and your users never leave home. And there is no monthly report to wait for either: you see the same live panel I see.

Getting set up

Before anything else I need your project running in my own environment: repository, database, configuration. It happens during the first days of the service, it is real work, and I do not charge for it: it is included at no cost.

Project set up in my environment
  • Your repository cloned and the site running on my machine.
  • Your configuration reproduced, working from a sanitised copy of the database: if you cannot sanitise it yourselves, I do it before installing anything.
  • DruScan connected and the first audit run, so there is a baseline to compare against.
  • The way we work agreed in writing: branches on your repository, changelog, and who approves what before it goes live.
At no cost

Contract and billing

The whole deal fits in three rules.

What you sign
  • Billing is monthly and always in advance. I only work on months already paid, so nobody has to chase invoices.
  • There is no lock-in: it is a monthly fee you can walk away from whenever you want. The only ask is one month of notice, not a few days.
  • The fee buys a batch of work every month, month after month: almost never does the first month leave everything fixed. When you want an area up to date right away, that is what the sprints are for.
Why there is no lock-in. The set-up is time I put in without billing it, and I only earn it back if you stay. So the pressure is on me, every single month: the service has to keep being worth more than it costs, or you leave.

Core and contrib updates

What you get is one less worry: a security advisory never catches the site unpatched, and updating stops being the task nobody finds time for. If you leave this part to me, I update Drupal and the community modules on a recurring basis, via Composer, at the pace you choose. Drupal publishes its new versions on Wednesdays, so I work to that release calendar. Each round goes on a branch of your own repository (update/YYYY-WW): I run the automated tests and send you a summary of what changes and what risk each item carries. You review it and decide when it goes live.

Frequency

Drupal core publishes its bug fixes on the first Wednesday of the month and its security advisories on the third, and I prepare the branch against that calendar. The community modules follow their own: new versions, security ones or not, can land any week. That is what a weekly cycle picks up as it comes and a monthly one lets pile up. If your own team already does the updating, leave them out and this section costs nothing; if I do them, the rhythm you pick is added to the monthly fee.

What gets updated

This decision is separate from the frequency and does not change the price. My recommendation is to update everything: nothing piles up and each round stays small. On very large portals, with many community modules and where stability weighs more than running the latest version, it can make more sense to take only the security ones and ask for a full catch-up every few months.

Who pushes it to production

Major versions are not part of the fee. The fee covers the minor versions of the branch you are on: every 10.x if you run Drupal 10, every 11.x if you run Drupal 11. Jumping from 10 to 11, or from 11 to 12, is a different job, a major-version migration: the upgrade needs contrib compatibility checks, deprecated code replaced and many more tests, so it is quoted separately, at a closed price agreed before anything starts.
Production is never touched automatically. Not from the update pipeline, not from any other tool in the process. The branch arrives reviewed and with the project tests run, but a human always presses the button.
What the tests can promise, and what they cannot. On every round I run the tests the project already has, and the more there are, the easier the two of us rest. But let me say it plainly: most projects arrive with very little coverage, and the tests cover the code written for you, not the community modules themselves. Updating twenty contrib modules at once is something no amount of tests can certify as risk-free. Which is why the branch reaches you for review, why the coverage work in the Tests step is worth what it costs, and why on very large portals taking only the security ones is a reasonable decision rather than a lazy one.

Automated code tests (unit and kernel)

Automated tests re-check the whole project in minutes, every time somebody touches the code. Without them, the way you find out that a change broke something is a user hitting it in production. These tests cover the logic built specifically for your project, not what Drupal already ships, and they report before the branch goes out. In technical terms they are unit and kernel tests written with PHPUnit, the Drupal standard: the unit ones check one piece of logic on its own, and the kernel ones check that same piece running against a real Drupal, with its database, its configuration and the modules it depends on. And one note that I think matters: now that so much code is written or reviewed with AI, these tests are the only thing that separates 'it works' from 'it does not crash'.

Monthly coverage

Progressive coverage, included in the monthly plan Every month another slice of the custom code gets covered, starting with whatever gets touched most, up to the minimum coverage we agree on together. Anything new that lands ships with its own tests, so the figure keeps climbing instead of decaying. Included in the monthly plan

User interface tests (Playwright)

These tests open a real browser and use your site the way a person would. Each test replays one complete journey, step by step. On a shop, for example: open a product, add it to the basket, change the quantity at the checkout, fill in the form, place the order — and then check in the admin panel that the order really got created. On a content site: open the search from the home page, type a word, check the right page shows up among the first results, go into it, and check its image opens large in a modal, with its alternative text in place. The idea is always the same: the journeys your site cannot afford to break get walked automatically after every code change, configuration change or update, before any of it reaches production. They are end-to-end (E2E) tests, written with Playwright: I do not work with Cypress or Behat.

What the monthly plan already covers

Three tests at no cost, and the upkeep of all of them The first time you take out the monthly plan I write three tests at no cost: the home page loading what it should, the login working, and a third one that matters to your project, such as the search finding what it must. Only that first time; any test beyond those three is hired in the batches on the Extras step. The monthly plan also maintains every test, mine or not, old or new: when an update or a code change makes one fail, fixing it or adapting it is part of the fee. Included in the monthly plan
Who runs them, and where. Every test, of either kind, I write and run on my own machine before delivering, so nothing broken reaches you. They all live in your repository, and anybody on your team can run them locally, on any branch. Continuous integration and scheduled runs on your own server are your team's to set up: on infrastructure of mine, nothing runs automatically.

Static analysis: PHPStan and PHPCS

PHPStan reads the code without running it and finds faulty PHP that would otherwise only surface in production: a call to something that no longer exists, a value arriving empty where nothing expects it. PHPCS checks that the code is written in one single style, the one the Drupal community agreed on. It sounds cosmetic and it is not: code that follows the standard is code any developer can pick up, review and change without deciphering it first, and that is exactly what makes a project cheap or expensive to maintain. Tools like SonarQube measure much of this same ground, so it is also what shows up in a technical audit. I run both on my machine on every change I make, and your team can run them too or wire them into its own pipeline. The work is getting the project clean the first time and keeping it that way.

Monthly clean-up

Progressive clean-up, included in the monthly plan Every month a batch of the pending findings is cleared, and whatever new code lands in the repository is kept clean from the start so the backlog does not grow back. Included in the monthly plan

Performance and frontend good practice

Your custom code is reviewed, back end and front end, for what makes the site slow, what hurts your Core Web Vitals, and what will make it expensive to maintain: queries repeated hundreds of times on a single page, cache metadata that hands one visitor another visitor's content, Twig templates that break invalidation, CSS and JavaScript loaded on every page to be used on one. Whatever turns up gets fixed, in small, reviewable deliveries, one topic at a time.

Monthly work

Progressive work, included in the monthly plan Every month the findings are worked through in order of what costs the site most, and the code landing in the meantime is reviewed with the same criteria so nothing new is added to the pile. Included in the monthly plan

Site configuration

DruScan.com — the dashboard included at no cost — gives you the summary of what is being detected on the project. A good part of it is configuration: modules still sitting in the repository without being enabled, which can simply be dropped; caching set up wrong, both site-wide and on each individual view; permissions granting more than they should; SEO settings letting traffic slip away. From there every finding has to be decided one by one: dismissed as a false positive, or actually fixed. That is the work this section covers. And each new release of the audit can bring to light things that were going unnoticed before.

Monthly fixes

Progressive fixes, included in the monthly plan What the panel reports gets corrected batch by batch, worst first, and settings that change along the way are checked with the same criteria. Every change arrives as a reviewable delivery or as exported configuration, never as a direct touch in production. Included in the monthly plan

Acceleration sprints

The sprints are one-off payments that speed one specific area up, instead of waiting months while the monthly plan works through it bit by bit. They are also how you set priorities: if you want every possible test in place before I even look at PHPCS, you book the coverage sprint and that area jumps the queue. They can be booked at the start or at any point of the service. Each one is two weeks of calendar, not two weeks of exclusive dedication, worked with the same agents and the same review as everything else, and that is why they can carry a closed price instead of a consulting estimate by the hour.

Unit and kernel tests

PHPStan and PHPCS

Performance and frontend

Site configuration

A sprint buys two weeks, not a finished project. In each sprint I get through as much as two weeks allow, always starting with what matters most. How far that reaches depends on how much custom code the project carries and on the state it is in: on a small site it can mean clearing the whole list, and a big one takes several sprints. Whatever is left keeps moving through the monthly plan, and you can always book another one later.

More UI tests (Playwright)

These are the Playwright tests from the Automated tests step: journeys checked in a real browser. The monthly plan includes three of them, written once, when you first sign up, not three new ones every month. From there the plan keeps every test alive, and any journey beyond those three is developed as a one-off batch: the bigger the batch, the cheaper each test, because the set-up work is shared.

Confidentiality and use of AI

Part of my work leans on AI, but not on generic AI: on my own agents and skills, built and tuned for this exact workflow, which read code, spot patterns and draft a first version that reaches a quality hard to match otherwise. I always review that work by hand, and nothing is merged into a branch without that review. This section is only about where the underlying models run, because it is the one decision on this page that puts your code in front of a third party. Everything else stays with me: I work on my own machine, always from a sanitised copy of the database, so I never handle the real names or email addresses of your users.

About your project

These answers do not change the price of what you have configured. They tell me whether it fits your project as it is, or whether the proposal should suggest an adjustment. All of them are required.

This is the one way I work: everything goes through Git and every delivery is a branch. If your project does not use it yet, setting it up is the first thing we do.
Environments of your own*
Tick every one you have.

Contact details

Sending this request commits you to nothing: within two working days at most, the closed proposal reaches you in writing, with the scope spelled out. Prices are quoted without VAT, and the fee is month to month, with no lock-in.

Your details are used to prepare and send you this proposal, and nothing else: no newsletter, and they are not passed on to anybody.
Savings vs done by hand 2.210 €/mo Monthly cost 1.790 €/mo One-off payment 0 €