What does it cost to run a website or app?

What is the cost of running a website made of?

It is tempting to think of a website as a one-off purchase — you paid, you got it, done. In practice a live website is more like a car: the sticker price is only the start, and after it come fuel, insurance and servicing. A website’s three “services” are the domain, hosting and maintenance.

The domain is the site’s name, and it renews every year. It is the steadiest, most predictable and cheapest of the three. Hosting is the server that serves the site to visitors — and here the range is already wide, as we will see in a moment.

Maintenance is the third component, and it is the one that surprises people. It does not appear on the build quote, it is not visible on the screen, and yet over the life of the system it is usually the largest expense.

Can a website be hosted for free?

Sometimes yes, and genuinely for free. A static site — pages served as they are, with no server side processing each request — can be hosted at no cost or nearly none on services like Cloudflare Pages or Netlify. Many brochure sites, landing pages and blogs fall into exactly this category.

The difference begins the moment the system has to remember things. A database, user login, forms that store data, server-side processing — all of these require infrastructure that runs all the time, and that already costs money. That cost is also not fixed: it grows with the number of visitors and the amount of data stored.

So two systems that look the same to a user can be far apart in running cost. A site that displays information is cheap to run; a system that manages information is not.

Why does maintenance cost money if the site is already built?

Because software does not stay frozen even when no one touches it. Your site rests on layers of code others wrote — libraries, frameworks, security components — and all of them are updated constantly. A version that was fine last year can become vulnerable today.

Three things happen in the background regardless of you: security holes are discovered that need closing, browsers and operating systems change and sometimes break behaviour that worked, and dependencies age until they are no longer supported. Without ongoing maintenance the site does not vanish in a day — it wears down slowly, becomes slow, vulnerable, and eventually broken.

And there is a further cost that is hard to price until it happens: the availability of someone who can fix it. When something goes down the night before an event, the question is not only how much the fix costs, but whether there is anyone to turn to at all. That is the part a build-and-forget site does not cover.

What raises the running cost — and what lowers it?

One word: complexity. The more moving parts a system has, the more there is to maintain and the more that can break. Three factors decide most of the difference.

Dependence on paid third-party services. Every third-party tool the system connects to — maps, mailing, payments, file storage — is one more monthly subscription and one more point of failure. Sometimes it is justified, and sometimes it is a cost that could have been saved.

The number of features. Every extra capability is more code to maintain. A system crammed with features most of which go unused costs more to run — without giving more value. We covered this separately in the article on a system built around how you actually work, not around a list of capabilities.

How the system was built. Clean code with few dependencies, and static pages where possible, is far cheaper to run than code accumulated in a hurry. That is exactly one of the hidden costs of apps built too fast — we went into it in the article I built an app in base44.

So what is the difference between the build cost and the running cost?

The build is a one-off expense: the planning and development up to a live product. Running it is an ongoing expense: hosting, updates, security and support for as long as the system operates. The two are separate — the build is what you invest to get a working product, and running it is what keeps that product alive, secure and up to date afterwards.

The important point is the link between them: the size of the running cost is decided at the build stage. A system built cleanly, minimally and with few dependencies will cost little to run for years; a system built in a hurry, crammed and dependent on ten services, will bill you every month. The cheapest to build is not always the cheapest to run.

And if you are trying to decide whether you need a system at all, or to understand what running an existing one would cost, the fastest way to find out is to send us a short message about what you built.