What it costs to run a SaaS, after you have built it

The build cost is a number you pay once and can plan around. What an MVP costs is the question every founder asks first, and it is the easier of the two — it has an end date.

The running cost does not. It arrives every month whether anyone signed up or not, it compounds with usage, and it is largely decided by architecture choices made during the build, when nobody was thinking about the bill. This is what it actually looks like.

The five lines the bill is made of

Almost every SaaS infrastructure bill decomposes into the same five categories. Knowing which one dominates yours tells you where optimisation is worth anyone's time.

The database is the line that behaves worst. Compute can be scaled down at 3am; a database holding production data cannot, it needs headroom you are paying for even when idle, and migrating it later is the most disruptive piece of work on this list.

Realistic monthly ranges at three stages

These are for a typical B2B SaaS — web application, background jobs, a relational database, no heavy video and no significant model inference. Those two change the shape entirely and are covered below. Figures are in USD, and every one of them is a range because the honest answer depends on choices you have not made yet.

The first row surprises people, and it should be treated as a warning rather than good news. Free tiers make the first months feel free, and the jump from the first row to the second is not gradual — it happens the week you cross a free-tier limit, and it arrives as a bill, not a notification you acted on.

The line that surprises people: egress

Bandwidth out of a cloud provider is billed, bandwidth in usually is not, and the rate is high relative to what the same traffic costs anywhere else. For a text-heavy B2B app this is a rounding error. For anything serving images, video, exports or large API responses it can quietly become the largest single line.

It is also the line with the largest spread between providers. Object storage with no egress fees — Cloudflare R2 built its pitch on exactly this — versus per-gigabyte egress on a traditional provider is a difference of orders of magnitude at volume, for storage that is otherwise interchangeable. Check AWS's own pricing page for the comparison rather than taking anyone's summary of it, including this one.

The practical advice: find out today which line dominates your bill. Most teams have never looked, and are optimising the one they assume rather than the one they are paying for.

The line that grows fastest: inference

If your product calls a language model, that line behaves unlike everything else in a SaaS cost base. It is genuinely variable — it scales with usage rather than with users — so a single enthusiastic customer can cost more than a hundred ordinary ones, and your gross margin becomes a function of how people use the feature.

Rates are published by the vendors — OpenAI and Anthropic both list them — and they have fallen repeatedly, so build the estimate from your own token counts rather than from a figure you read once. What a RAG chatbot costs has the arithmetic worked through end to end.

Two controls matter more than model choice: a hard per-account cap so no single user can run up an unbounded bill, and caching of anything asked repeatedly. Both are cheap to add during the build and awkward to retrofit once usage patterns exist.

Where the money actually leaks

In most audits we run, a meaningful share of the bill is paying for nothing at all. The list is boring and it is always roughly the same:

• Staging environments running 24/7. They are used during working hours in one timezone and billed for all of them. Scheduling them off outside those hours is an afternoon of work.
• A database provisioned for a spike that never came. Over-provisioning is prudent once and then never revisited. Check actual utilisation against what you are paying for.
• Log retention nobody chose. Default retention on a verbose application can cost more than the compute generating it. Decide how far back you genuinely need to search, which is usually weeks rather than a year.
• Environments from abandoned work. A preview deploy, a proof of concept, a migration that was cancelled. These outlive the people who created them.
• Seats on tools for people who left. Not infrastructure, but it sits on the same monthly statement and the same nobody owns it.
• Orphaned storage. Snapshots, old backups and build artefacts accumulate silently because nothing ever deletes them.

None of this is clever engineering. It is an hour with the billing console once a quarter, and it is consistently the highest return per hour available in a cost exercise.

The rule of thumb that survives contact

For a healthy B2B SaaS, infrastructure should be a modest fraction of revenue — public SaaS companies typically report gross margins in the 70–80% range, and the hosting bill is one component of the remainder. If your infrastructure cost is climbing towards a third of revenue, the problem is a pricing or architecture problem, not a procurement one.

That distinction matters because the two have different fixes. A procurement problem is solved with reserved instances and a negotiated contract. An architecture problem — synchronous work that should be queued, queries that scan tables, a design that requires vertical scaling — is solved by changing the system, and the a16z analysis of cloud costs at scale is the well-known argument that this compounds as a company grows.

Our own experience is narrower and points the same way: when a bill is growing faster than usage, the cause is nearly always on the why is my app slow list. Work on the request path that should be a background job, or a query pattern that makes you buy a bigger database every six months.

What this means before you build

Most of the running cost is committed during the build, by people optimising for shipping rather than for the bill. That is usually the correct trade — an MVP that ships late to save $80 a month is a bad trade — but a few decisions are worth making deliberately because they are expensive to reverse:

1. Where the database lives, and whether you can move it later without downtime.
2. Whether heavy work is on the request path or behind a queue. This decides your compute bill more than instance size does.
3. Where files are stored, and what egress costs from there.
4. Whether per-use services have caps, so a bug or a heavy user cannot produce an unbounded invoice.
5. Whether you can actually see per-feature cost, or only one total. You cannot price a feature whose cost you cannot isolate.

The last one gets skipped almost universally and is the one that hurts at the point you want to introduce usage-based pricing.

What we do

Every MVP build we ship includes the deployment, the monitoring and a stack whose running cost we can state before you commit to it — the figure belongs in the conversation before the build, not in a surprise the month after launch. You own the accounts from the first commit, so the bill is yours and visible, never resold through us.

Where a bill is already out of proportion to usage, that is a scale and re-architecture question rather than a vendor one, and it usually resolves to two or three specific changes. Why MVPs break at scale covers the pattern behind most of them.

Frequently asked questions

References

1. R2 pricing — Cloudflare
2. Amazon S3 pricing — Amazon Web Services
3. API pricing — OpenAI
4. Pricing — Anthropic
5. The Cost of Cloud, a Trillion Dollar Paradox — Andreessen Horowitz