Skip to main content
Krodox
Back to writing

What a website actually costs to run

Krodox Team August 6th, 2026 Webplo PHP

Anyone who hosts websites for other people eventually asks the same question: what does one site actually cost us? It sounds like an accounting problem. It is really an architecture problem, and most people answer it wrong on the first attempt.

The usual mistake is to divide the hosting bill by the number of sites. That number is easy to produce and tells you almost nothing, because it mixes two costs that behave completely differently — and because it leaves out several line items that are frequently larger than hosting.

Two buckets, never one

Every cost in a hosting business falls into one of two categories, and keeping them apart is the whole discipline.

Fixed cost is what you pay before the first customer arrives. Your application servers, your database, your monitoring, your server-management tooling, your transactional email provider. If you had zero customers tomorrow, you would still pay it. It does not move when you add a site.

Marginal cost is what one additional site adds. A slice of a shared server, the payment-processor fee on that customer's subscription, the bandwidth their visitors consume.

Cost per site is not one number. It is:

cost per site  =  fixed cost / number of sites  +  marginal cost per site

The first term collapses as you grow. The second does not. Which means cost per site is not a property of your architecture — it is a property of your scale. Early on, the first term dominates so completely that the second is noise. A platform with $1,500/month of fixed cost and eight customers is paying nearly $190 per site regardless of how efficient the hosting is.

This is why "cost per site" quoted without a site count is meaningless, and why efficiency work on the second term is almost always premature when the first term is still large.

The line items people forget

Marginal cost is where the surprises live. A reasonably complete checklist:

  • Hosting slice — the server the site runs on, divided by how many sites share it
  • Payment processing — typically ~2.9% plus a fixed per-transaction fee
  • CDN bandwidth and requests — often free at low volume, rarely free forever
  • Transactional email — password resets, notifications, receipts
  • Content generation — if AI writes the initial content, the tokens are a real one-time cost
  • Domain registration — usually passed through, but check whether you absorb the first year
  • Backups — snapshot storage is commonly billed as a percentage of the instance
  • Failed provisions — sites that were built and abandoned still consumed resources

The one that surprises people most is payment processing. On a low-priced subscription it frequently exceeds hosting. At $20/month, the flat $0.30 alone is 1.5% of revenue, and the percentage fee takes the total to roughly 4.4%. If your hosting slice is a dollar or two — which it should be on any sensibly packed server — then your payment processor costs more than your infrastructure.

That inversion is worth sitting with, because it tells you where optimisation effort belongs. Halving your hosting cost might save a few cents per site. Moving a customer to a higher-priced plan changes the arithmetic entirely.

Two architectures, two cost curves

Here the accounting stops being generic, because the way you host determines the shape of both terms.

The static model

Generate the site once as plain HTML, CSS, images and JavaScript. Push it to object storage. Serve it through a CDN. There is no application server, no database, no PHP or Node process running per request.

The economics are exceptional. Marginal cost approaches storage and bandwidth alone — fractions of a cent per site per month. There is no server to size, no worker pool to exhaust, no per-site database. Ten thousand sites cost approximately ten thousand times almost nothing. It scales close to linearly and the failure modes are mild: a CDN edge is far harder to knock over than an application server.

What you give up is everything that requires code to run when a visitor arrives.

A static site cannot process a form on its own. It cannot take a booking, issue an invoice, check availability, hold a session, run a search across its own content, or show anything that differs by visitor. Every one of those needs a backend somewhere — so in practice static platforms either bolt on third-party services for each capability, or run a separate application that the static sites talk to. That application is a fixed cost, and it quietly reintroduces much of what the static model was supposed to avoid.

The other constraint is editing. If a merchant changes their opening hours, something must regenerate and redeploy the affected pages. That pipeline is itself infrastructure, and its cost and complexity grow with how granular and immediate you want edits to feel.

The application model

Run each site as a real application — a web server, a language runtime, a database or content layer, executing on request.

Marginal cost is genuinely higher. Sites consume memory and CPU, not just disk. Density is bounded by concurrency rather than storage: what limits you is how many requests can be served simultaneously, which is a function of worker memory, opcode caching, and CPU. A site that occupies a hundred megabytes of disk might need considerably more RAM under load, and you size servers for the peak, not the average.

The compensation is that everything a small business actually wants is already possible. Forms submit. Bookings write to a database. Invoices generate. Content is editable in place and live immediately, because there is nothing to rebuild. Search works. Sessions exist. Adding a capability is application code, not a new third-party dependency and a new integration to maintain.

There is also a middle path worth knowing: an application-backed platform can cache aggressively enough that most requests never execute code at all. Full-page caching at the application or edge layer means a typical visitor is served a stored response, and the runtime only engages for the requests that genuinely need it. That recovers much of the static model's efficiency while keeping the capability. It is not free — cache invalidation is a real engineering problem, and a misconfigured cache can consume far more storage than the sites themselves — but it substantially narrows the gap.

Why backend code is a business question, not a technical one

It is tempting to treat this as a purely technical trade-off. It is not. The presence or absence of a backend determines what you can sell, and to whom.

For the merchant, a backend is the difference between a brochure and a tool. A restaurant that can take bookings, a clinic that can manage appointments, a trades business that can issue an estimate — these are the things that make a website part of how the business runs rather than an obligation it maintains. Businesses churn off brochures. They rarely churn off something their week depends on.

For the platform, capability is what supports pricing. A static brochure competes on price against every other brochure, and that is a race with a known ending. A platform that owns the merchant's bookings, invoices or customer records is providing something with switching costs, and can price accordingly. The higher price then pays for the infrastructure that made it possible — which is the point that makes the whole model work.

This is the honest version of the trade-off, and it is worth stating plainly rather than pretending one architecture simply wins:

Static hosting optimises the cost line. Application hosting optimises the revenue line.

At a $10/month price point, marginal cost matters enormously and static is likely the only structure that works. At $30 or $80, marginal cost is a rounding error against the fixed and development costs, and the constraint is what you can offer rather than what you can afford to run. The architecture should follow the price point, not the other way around.

Actually doing the calculation

A worked method, using illustrative numbers:

1. Total your fixed monthly cost. Every server that is not tenant hosting, plus every subscription — management tooling, monitoring, email, error tracking. Suppose it comes to $1,000/month.

2. Calculate your hosting slice. Take the monthly cost of one tenant server and divide by how many sites it holds comfortably — measured under real load, not guessed. A $40 server holding 20 sites is $2.00 per site. Be honest here: a server that technically fits 50 sites but degrades at 20 holds 20.

3. Add the other marginal costs. Payment processing on your actual price point, CDN beyond any free tier, per-site email volume.

4. Combine.

cost per site (at N sites)  =  $1,000 / N  +  marginal

5. Find your break-even. The site count where revenue covers everything:

N = total fixed cost / (price − marginal cost per site)

With $1,000 fixed, a $30 price and $2 marginal, that is 36 sites. Add $250/month of new fixed cost — one more tool, one more server — and break-even moves to 45. Every fixed cost you add has a price denominated in customers, and that is a far more useful way to evaluate a subscription than its monthly figure.

6. Then include development separately. Whatever you spend building the product is not a cost of serving a customer, and folding it into per-site cost will make a healthy product look unprofitable. Track it as its own line. It changes when you are self-funding; it does not change what a site costs.

The conclusion most people reach too late

Run this exercise honestly and it usually produces the same finding: infrastructure is not where the money goes.

For most platforms at most stages, development and payroll dwarf hosting by an order of magnitude, and fixed cost divided by a small customer count dwarfs marginal cost by another. A weekend spent making tenant hosting 30% cheaper might save a few dollars a month. The same weekend spent on the thing that adds ten customers changes the business.

That is not an argument for wasteful infrastructure. Efficient hosting is worth having, unit economics that work at scale are worth designing for early, and a platform that cannot serve its customers reliably has no economics at all. But it is an argument for knowing which number you are actually optimising — and for calculating cost per site properly, so that you find out which one that is.