What does a web app cost per month to run?

This question usually arrives at the end of a build conversation, phrased as an afterthought, and it deserves better than the answer it normally gets. The normal answer is a hosting figure, because hosting has a price list and everything else does not.

The hosting figure is real, and for most small business applications it is also close to irrelevant. It is typically the smallest line in the annual total and the one least likely to surprise you. The lines that decide what the application actually costs are the ones with no price list attached.

Start with the number that is published

Platform pricing is public, so use it rather than guessing. Vercel, as one common example for applications built on modern JavaScript frameworks, publishes a free Hobby tier and a Pro tier at twenty dollars a month per seat. On the published pricing page at the time of writing, Hobby includes one million edge requests, one hundred gigabytes of data transfer, one million function invocations and four hours of active CPU per month. Pro raises those to ten million edge requests and one terabyte of transfer, then bills overage at two dollars per additional million requests and fifteen cents per additional gigabyte.

Two things follow from those numbers and they matter more than the numbers themselves. The first is that a small business application with a few hundred internal users does not come close to the Pro allowances, so the platform bill is a seat cost rather than a usage cost. The second is that the metered items are the ones that scale with traffic, not with the size of your business, which is why a marketing site with one viral week can cost more to serve than an internal tool used daily for a year.

Treat any figure like this as a snapshot. Vendors restructure pricing, and the specific allowances above are what one vendor published on one day. The shape is what transfers: a flat seat cost, a generous allowance, and metered overage on traffic and compute.

The rest of the infrastructure bill

Hosting is not the whole platform bill. A working application usually also pays for a managed database, file or image storage, transactional email or SMS, error monitoring, and a domain with a certificate. Individually these are small. Together they typically add up to more than the hosting line, and they are easy to forget when the estimate is being written.

The one that catches people is transactional email. It is cheap per message and quietly becomes a dependency with deliverability requirements, a domain to authenticate, and a support burden when a customer says they never received something.

The line that dominates: change

Here is the part that is not on any pricing page. A web application that is being used is a web application that is being changed. A report needs a new column. A supplier changes a file format. A tax rule moves. Somebody joins and the permissions model turns out not to cover their case. None of that is a defect, and all of it is work.

Over a year, for most small business applications, the cost of change exceeds the cost of infrastructure by a wide margin, and it is the number that determines whether the application is worth keeping. Estimating it honestly is difficult, but ignoring it produces a budget that is wrong by an order of magnitude rather than by a percentage.

The useful discipline is to ask, before the build, roughly how often the business rules encoded in the application are expected to change. A stock system in a business with stable suppliers changes rarely. A pricing or compliance tool changes whenever the rules do. Same infrastructure cost, very different annual total.

The maintenance you pay for whether or not you change anything

Even a frozen application accrues work. Dependencies publish security updates. Runtimes reach end of life and stop receiving them. Browsers change behaviour. Certificates renew, usually automatically, until the one time they do not.

This is the cost most often discovered rather than budgeted, typically two years in, when a small change turns out to require a framework upgrade first. Keeping dependencies current continuously is unglamorous and cheaper than the alternative, and it is the same argument as working in small batches everywhere else.

How to get a number you can actually plan with

Take the published platform pricing for the tier you will genuinely be on, add the supporting services individually rather than as a rounded allowance, then add an annual figure for change based on how often the underlying business rules move. If you cannot estimate that last one, that is a signal the scope is not settled yet, which is a problem to solve before the build rather than after it.

It is also worth being honest about the case for not building. If the application would replace a spreadsheet that is working, the running cost is real and the spreadsheet is free, and the argument only holds when the spreadsheet is actively costing something. That threshold is the subject of when a stock spreadsheet starts costing more than it saves, and the reporting version of the same question is in automating manual reporting without buying a BI platform.

For the other half of the budget, the one-off build rather than the monthly run, the ranges and what moves them are set out in how long it takes to build a web app, and the reasons an estimate drifts once work starts are in why software projects take so long. Getting the scope settled first is what keeps both numbers stable, which is the case made in scoping a project before anyone writes code.

If the application in question is a customer-facing site rather than an internal tool, there is a companion question about what a build should cost in the first place. KF Agency covers the Riyadh market version of that in Arabic, in a breakdown of website design cost and steps in Riyadh. It is written in Arabic and covers the commercial side rather than the running cost, which is the half this note is about.

The short version

For a typical small business application, expect the infrastructure to be a modest and fairly predictable monthly figure, and expect the annual total to be dominated by changes nobody could list at the start. Budget for the second one explicitly. An application with no change budget does not stay still, it just decays until it is replaced, which costs more than maintaining it would have.