A December website maintenance review should answer two questions: what did the site actually cost to keep running this year, and what will it cost next year. Everything else — the licence inventory, the incident log, the hours your team never billed anyone for — exists to support those two numbers. Maintenance budget here means the recurring cost of keeping an existing site alive and current: hosting, licences, updates, backups, monitoring, security patching, and the human hours spent on all of it. It is separate from a redesign or a new feature build, and the most common budgeting mistake is letting the two blur together until maintenance quietly absorbs whatever the project budget left behind.
Table of Contents
- Start with what the year actually cost, not what you planned
- Audit the recurring line items one by one
- Read the incident log before you set next year's number
- Build next year's number in three parts
- What December specifically changes
- Make the review produce artefacts, not just a figure
- Frequently Asked Questions
Start with what the year actually cost, not what you planned
Pull twelve months of real spend before you form an opinion. That means invoices from your host, every SaaS and plugin subscription that renewed, the domain and certificate charges, and any third-party developer or agency time. Card statements and your accounting export will surface the subscriptions nobody remembers approving. Then add the internal hours, which is the line most teams skip.
If a developer spent two days in March untangling a plugin conflict, that is a maintenance cost even though no invoice exists. Even a rough reconstruction from ticket history or time tracking gives you a defensible figure. Compare the total against last December's budget. A site that came in 40% over does not necessarily need a bigger budget — it may need a different architecture, a different host, or fewer moving parts.
Audit the recurring line items one by one
Recurring costs drift upward through renewals and forgotten trials, and the only reliable fix is an annual inventory. For each item, record what it costs, when it renews, who owns the account, and whether anything on the site would break without it.
Flag three categories as you go: things nobody uses, things you pay twice for, and things that are now bundled into something else you already buy. Cancelling the first two is usually the fastest saving available in the whole review.
- Hosting and any managed add-ons, including staging environments and bandwidth or visit overages
- Domains and DNS, with their renewal dates and auto-renew status
- TLS certificates, if you pay for them rather than using an automated free issuer
- CMS plugin, theme, and module licences — WordPress premium plugins and paid Drupal services both tend to accumulate
- CDN, email delivery, form handling, search, and any API you call at runtime
Read the incident log before you set next year's number
Unplanned work is the best predictor of next year's cost, and it is the part a spreadsheet of subscriptions cannot show you. Go through the year's support tickets, outage reports, and emergency fixes, and group them by cause rather than by date. Repeated incidents from the same source are a budget decision, not a support problem.
A plugin that breaks on every major CMS release, a host that throttles under traffic spikes, or a custom integration that only one person understands will each keep charging you until you replace them. Price the replacement against the hours the incidents cost this year and the choice usually makes itself. Also note how long things sat broken. If a form was silently failing for three weeks before anyone noticed, that is a monitoring gap, and monitoring is far cheaper than the leads lost.
Build next year's number in three parts
Split the budget into baseline, planned work, and reserve. The baseline is the recurring spend you just inventoried, plus a realistic allowance for price increases — hosting and SaaS tools rarely get cheaper. The planned work is the maintenance you already know is coming. Known work for the year ahead usually includes major CMS version upgrades, PHP or Node runtime updates your host will eventually force, accessibility remediation, content pruning, and the replacement of anything you flagged as end-of-life.
Put dates against them so they compete for calendar time, not just money. The reserve covers what you cannot schedule: emergency security patches, a hosting migration after an outage, a sudden API deprecation. Teams often set it as a percentage of the baseline, and your own incident log is a better guide to the right percentage than any rule of thumb. If you spent nothing unplanned in two years, a thin reserve is reasonable; if you had four emergencies, it is not.
What December specifically changes
Timing matters this month in ways it does not in June. Annual contracts signed in January come up for renewal soon, so this is the window where cancelling or renegotiating still costs you nothing. Check which subscriptions auto-renew and when — the decision date is often weeks before the charge date. December is also peak traffic for retail and gift-adjacent sites, and the worst possible time to deploy a major upgrade.
Many teams run a code freeze through the shopping period and into early January. Schedule the risky work you identified for after the freeze, and use December for the review itself, licence decisions, and documentation. If your budget runs on a calendar fiscal year, remember that unspent money often does not carry over. Spending it on deferred maintenance — a security audit, an accessibility review, documenting the one integration nobody understands — converts a use-it-or-lose-it balance into reduced risk next year.
Make the review produce artefacts, not just a figure
A review that ends with one number is hard to defend and impossible to reuse. Leave behind three documents: the recurring-cost inventory with renewal dates and owners, the planned-work calendar, and a short written rationale for the reserve.
Assign an owner to every recurring item. Orphaned accounts — a licence on a departed employee's email, a domain registered to a former contractor — turn into outages at renewal time, and December is when you have the inventory open anyway. Finally, put next December's review in the calendar now, a few weeks before your earliest January renewal falls due.
Frequently Asked Questions
How much should a website maintenance budget be?
There is no universal figure — it depends on the platform, traffic, integrations, and how much custom code you run. Your own twelve months of actual spend plus unplanned hours is a far better starting point than any published benchmark.
Should maintenance and redesign budgets be separate?
Yes. Keeping them separate stops routine upkeep from being postponed to fund new features, and makes it visible when a site's maintenance cost has grown high enough to justify rebuilding it.
What belongs in the reserve versus the baseline?
Anything you can name and schedule belongs in planned work. The reserve is for incidents you cannot predict, and its size should reflect how many you actually had in the last year or two.
Is December a bad time to do upgrades?
For sites with holiday traffic peaks, yes — many teams freeze deploys and schedule upgrade work for January. The review, licence decisions, and planning are safe to do now.
