Two very different services get sold under the name Drupal support. One is repair: a page goes down, a form stops sending, a ticket goes out, someone digs in, and the fire gets put out. The other is the quiet, continuous care that keeps most of those fires from starting at all. Both are honest work, but they lead to very different years for your site.
We build our plans around the second kind. The quiet months are the deliverable. You should be able to go a full quarter without anyone on your team thinking about your website, and that is the sign the people looking after it are doing their job.
What happens when nothing is happening
On every site we support, there is a continuous background rhythm your team never sees. Each week we run through Drupal core and contrib security advisories, triage the ones that affect your modules, and ship the patches that matter before they become a problem. Each month we review performance data for the slowest page, the hottest database query, and the largest image on the homepage, and we quietly improve them. Each quarter we test backups by restoring them on a staging copy — because a backup that has never been restored is a promise, not a plan.
You do not get a report about most of this. You get a site that keeps working.
Why "call us when it breaks" costs more
Reactive support looks cheaper on paper because the line item for "nothing happened this month" is hard to sell. In practice it is the expensive option. The sites we inherit from a reactive model almost always carry the same debts: six to twelve months of missed security releases, an abandoned module that needs replacing, a hosting tier that has been under-sized since traffic grew, and a cron job that has been silently failing for weeks. Untangling all of that at once costs several times what it would have cost to keep current.
Keeping current also keeps the conversations small. A security release applied this week is a routine task with a fixed scope. The same update a year later is a project, with testing, coordination, and a deployment window. Steady care is what keeps the work in the first category.
What you should be getting every month
If you are on a support plan with anyone — us or otherwise — there are four things the plan should include by default, not as extras. Security patching within a defined window after each advisory. Monitoring that alerts a human before a visitor does. Performance reviews that are allowed to change things, not just write reports. And a recovery rehearsal at least once a quarter, so "we have backups" becomes "we restored one, and here is how long it took."
Everything else — new features, redesigns, content work — is product work, and it should have its own budget and its own conversation. Support is the contract that keeps your existing investment safe while the product work happens around it.
The shape of our support plans
Our support plans are deliberately simple. A fixed monthly fee, a named person from our team who knows your site, a response-time commitment in writing, and a quarterly check-in where we walk through what changed, what we watched, and what we recommend for the next three months. If you need more hours in a month, we tell you before you ask. If you need fewer, we carry the difference forward. No ticket quotas, no small print.
A support plan should feel like being looked after. That is the bar we hold ourselves to: quiet months, honest check-ins, and a site your team never has to worry about.