A website is a subscription, not a purchase

A website is bought once and paid for every month, whether or not an invoice arrives. The running cost is either a small managed amount or a larger unplanned one, discovered on the morning a form stops delivering enquiries. The second kind always lands at the worst moment, because nothing on a site fails politely.

What actually stops working on a site nobody touches?

A site left alone is not frozen; it drifts out of agreement with everything around it, and stays silent until a visitor sees it.

The certificate. It expires on a date nobody watches. When it lapses, the browser puts a warning over your homepage and visitors close the tab. The domain renewal is the second date in that category.

Dependencies. The framework, the plugin, the library the form uses. Updates ship for security among other reasons; a version untouched for two years is not stable but unpatched.

Integrations that stop sending. The form still says thank you and the message goes nowhere: a mail rule changed, a password was rotated, a key expired. This is the most expensive failure here, because the site looks healthy and no error appears.

Content nobody owns. Opening hours, a price list, the number that changed when the line moved. The site is not wrong because it was built badly; it is wrong because the world moved and nobody told the page.

A page that was true two years ago. A delivery zone you dropped, a payment option you removed, a branch that closed. Not broken — confidently out of date, which is worse.

DNS and the records around it. The mail records that keep your address working, the record pointing the domain at the host, verifications for tools connected once. One edit to the wrong line takes the mail down, and whoever made it rarely knows.

Is maintenance the same thing as making changes?

No. Maintenance keeps the site doing what it already does; a change alters what it does. Confusing the two produces both failure modes below.

Renewing a certificate, applying a security update, restoring a backup to prove it restores, confirming the form still lands in an inbox: that is upkeep. It recurs, it is predictable, and it is what a monthly amount buys.

A new page, a second language, another payment method, an integration with the stock system: those are changes. They need a scope, a price and a date. Bundling them into the monthly amount makes the arrangement unprofitable; billing each one by the hour makes you avoid your own site.

Question	Maintenance	A change
Who decides	Whoever is responsible for the site	You, with a reason and a date
Typical item	Certificate, updates, a backup test	A page, a language, an integration
How it is priced	In the monthly amount	Priced before the work starts

What are the two failure modes?

Nobody maintains it. The site is launched and forgotten. It works for a while, then a certificate lapses over a holiday or a form quietly stops, and the first report comes from a customer who could not reach you. The bill for that discovery is not the repair; it is every enquiry that never arrived.

Every small edit is a project. A quote, a meeting and an invoice to change a price. By the third time you stop asking: the price list is three years old, the team sends prices on messaging apps, and the site becomes a brochure nobody consults. Either way the site stops being the version of the truth, so the business builds a second one in chat and spreadsheets.

What should a monthly arrangement contain?

A defensible arrangement is short and specific, and it names what it excludes.

• A person and a channel, with an answer window in working hours — not a round-the-clock promise, but a time by which a fault is acknowledged.
• A routine pass on a calendar: certificate and domain dates checked before expiry, dependencies updated, backups verified by an actual restore, the form tested by sending a message and confirming arrival.
• Monitoring that reports to someone, so an outage is noticed before a customer mentions it.
• A stated number of small corrections, with "small" defined — a text edit, a price, a photo swap — so the boundary is known.
• The rate for everything else, written down now rather than negotiated during an incident.
• The exit: accounts, code, content and a tested restore belong to you, and leaving is a handover rather than a negotiation.
• One page a month saying what changed and what is due. The cheapest proof the arrangement is being used.

In what order do you put this in place?

1. List what the site depends on: host, domain, certificate, business mail, the form's provider, plugins, the stock or payment integration.
2. Move every account into the company's name and give the studio access rather than ownership. Start with the domain.
3. Write two lists on one page, upkeep and changes, with examples, and agree them in writing.
4. Fix the routine pass and its proof: a test message that lands in an inbox you can check.
5. Record the restore procedure and run it once, on a quiet day, before you need it on a bad one.
6. Review it each year against what the site now does; a brochure and a shop do not need the same thing.

Where this goes wrong

• Maintenance bought after the first outage. The arrangement is cheapest when nothing is wrong, which is exactly when nobody signs it.
• An hourly arrangement with no ceiling. You cannot budget for it, so you postpone the small things, and the small things are what become the outage.
• "We will call you when something breaks" makes the customer the monitoring.
• The studio owns the domain and the hosting account. That is leverage, and it surfaces the day you want to leave.
• Nobody owns the words. A site with no content owner is accurate for one season and wrong for the next three.
• Every Arabic correction priced as a change. The second language is then updated last, and after that never.

What this does not cover

This is not a price list, and it names no figures: they differ by stack, traffic and how much you change. It also does not say how often a particular framework must be updated, or what your legal pages must contain. A small static site needs less upkeep than a shop taking payments; a site rebuilt last year needs less than one untouched for four. And upkeep is not insurance against a rebuild: at some point the honest answer is a new site, and maintenance only postpones that decision by keeping the old one trustworthy.

We build websites and keep them on a monthly arrangement that lists what it covers, so the running cost is a line you can read rather than a morning you did not plan.