What Does It Cost to Maintain a Website or a System?

Almost every enquiry we get has a budget for building something. Very few have a budget for keeping it running. That is why companies pay for the same website, or the same system, every few years.

Maintenance isn't a fee for waiting until something breaks. It's the work that keeps working software working while the world underneath it changes.

What maintenance actually consists of

Dependency and platform updates

Your site or application sits on other people's code: a framework, libraries, a runtime, a payment provider, an email gateway. Those things ship new versions, retire old ones and patch security holes whether or not you have time for it.

Updated a little at a time, that's hours. Deferred for three years, it becomes a project: the version you're on is no longer supported, and the jump to the current one crosses several major releases, each with its own breaking changes.

Security

Disclosed vulnerabilities in popular packages are public — scanners sweep the internet for them within days. Maintenance is the point at which somebody actually reads those advisories and decides which ones apply to you.

Then there's rotating keys and tokens, reviewing access after someone leaves, and checking that backups genuinely restore. A backup nobody has ever restored isn't a backup; it's an assumption.

Monitoring and response

Somebody has to know that something fell over before a customer tells you. That means uptime alerts, error collection, logs, provider quotas — and a person on the other end of those alerts.

The small changes nobody calls a project

A new price, a new form field, a change to the terms, another user in the CRM, a copy fix, a new report for the accountant. Individually they take minutes. Across a year they're a real line item — and they decide whether the system keeps up with the business or starts holding it back.

Integration drift

If something is connected to something else — and today almost everything is — that something else will change. APIs get new versions, old ones are switched off, providers change data formats or rate limits. Your integration didn't break by itself: it broke because the other side moved on. Watching for that is part of the work on integrations.

Hosting and services

Server, database, CDN, domain, certificates, transactional email, analytics, licences. This is the one part most companies do have in the budget — and usually the smallest.

Why this isn't the line to save on

The cost of maintenance can't be avoided. It can only be postponed, and postponing makes it grow:

• Deferred updates turn into a migration that costs several times the sum of the updates you skipped.
• Deferred security costs exactly nothing until it costs a great deal, usually alongside a duty to report a data breach.
• Deferred small changes teach your team that "the website can't be changed", so a spreadsheet appears next to the system. Then a second one. That's the start of a company whose data lives in five places and trusts none of them.
• Deferred knowledge. After two years of no contact, nobody remembers why that part looks so strange. The first change after a long gap is expensive because it starts with reading your own history.

The most expensive version is always the same: a system runs unattended until cheap changes become impossible, and then the only proposal anyone wants to make is "let's rebuild it". Sometimes a rewrite genuinely is the answer, but rarely because it was the cheapest route.

How to plan for it

You don't have to guess. Three decisions before the project starts, rather than after.

1. Agree what's covered and what's new scope. The line is simple and worth writing down: maintenance means "what worked keeps working". A new feature is new scope. Without that line, every conversation about the invoice is a negotiation.

2. Agree response times, not just a number of hours. "Eight hours a month" means little if the store is down on a Friday evening. A sensible agreement says how quickly someone responds to an outage versus an ordinary request — and what separates the two.

3. Agree who owns the access. Repository, hosting, domain, provider accounts, API keys. They should belong to your company, with your contractor holding access — not the other way round. That one clause decides whether you have options in two years.

A reasonable starting point for budgeting: set aside somewhere in the mid-teens to mid-twenties percent of the build cost per year for maintenance and small improvements. A simple brochure site needs less; a system with integrations and payments needs more. That isn't a quote — it's the line in the plan that stops you being surprised.

What to do if you already have something nobody is looking after

Start with an inventory, not a rebuild. Write down what runs on what, who holds access, when it was last updated, whether backups restore, and what happens if it falls over tomorrow. That usually produces a short list of urgent things and a much longer list of things that can wait — which is good news, because it means the work can be staged.

We do that review as a small standalone piece of work, with no commitment to build anything afterwards. If you don't know what state your software is in, send us a note and we'll go through it with you.