Revenue grew 40 percent this year and the cloud bill grew 70 percent. Everyone is pleased about the first number and nobody has drawn the two lines on the same chart. When SaaS infrastructure cost rises faster than revenue, every new customer makes your margins slightly worse, and growth quietly stops being the solution to your financial problems.
This is uncomfortable precisely because it hides during good periods. Absolute revenue climbing masks deteriorating unit economics for a long time, usually until a fundraise or a board meeting forces someone to compute gross margin properly.
Why SaaS infrastructure cost outpaces revenue
Four mechanisms drive this, and most companies have all four running at once.
The first is that early architecture assumed a smaller product. Decisions made when you had fifty customers, a single database, a simple job queue, no data retention policy, remain in place at five thousand customers where they are dramatically more expensive.
The second is that heavy users are usually not paying more. Under flat or seat based pricing, the customer generating forty times the average load pays the same as everyone else. Your costs scale with usage while your revenue scales with headcount, and those diverge permanently.
The third is accumulation. Nobody deletes anything. Logs, backups, old versions, analytics events, and abandoned environments persist because storage feels cheap per gigabyte and nobody owns the total.
The fourth is that nobody is accountable for the bill. Engineers optimise for reliability and delivery speed, which are the right incentives, and neither has any relationship to cost. Without an owner, spend only goes one direction.
Find your SaaS infrastructure cost per customer
The single most valuable thing you can do is calculate cost per tenant. Most SaaS companies cannot, which means they are pricing and negotiating blind.
Tag every resource by customer where you can, and allocate shared costs by a reasonable proxy such as requests, storage, or compute time. It does not need to be perfect. Approximately right is transformative compared with having no idea at all.
What surfaces is nearly always the same shape. A small number of accounts consume a disproportionate share of resources, and some of them are on your cheapest plan. Occasionally a customer costs more to serve than they pay, which is a fact worth knowing before you renew them at the same price or, worse, offer a discount to keep them.
This data also changes engineering priorities. Optimisation work that seemed like housekeeping becomes obviously valuable when you can say a specific query pattern costs a measurable amount monthly.
It changes sales conversations too, in a way finance teams appreciate more than anyone. When a large prospect asks for a discount, knowing roughly what they will cost to serve turns a negotiation based on instinct into one based on a floor you can defend. Companies without this number routinely sign enterprise deals that look impressive on the revenue line and are close to break even once infrastructure is accounted for, and nobody discovers it because cost of goods sold never gets attributed back to individual contracts.
Read More - Customers Send Angry Emails When They Cross a Tier: How to Fix SaaS Pricing
Where SaaS infrastructure cost usually concentrates
Before optimising anything, look at where spend concentrates. The pattern repeats across most SaaS businesses:
- Over provisioned compute. Instances sized for a traffic peak that happens twice a year, running continuously. Frequently the single largest line.
- Data transfer. Especially between availability zones and regions. Invisible in architecture diagrams and substantial on the invoice.
- Storage nobody owns. Old snapshots, orphaned volumes, log retention set to forever because no one chose a number.
- Non production environments. Staging, demo, and test environments running at production scale around the clock, used during office hours.
- Managed service premiums. Convenient services carrying a large markup, chosen for speed and never revisited once volume grew.
- Inefficient queries at scale. A query that was fine at a hundred customers, executing millions of times a day at five thousand.
The order matters. Teams often start with code optimisation because it is intellectually interesting, when turning off idle non production environments overnight delivers a bigger saving in an afternoon.
The AI feature that quietly changed your economics
Worth singling out because it has caught a lot of teams in the past eighteen months. Traditional software features have near zero marginal cost: once built, serving one more user costs almost nothing. AI features break that assumption completely, because every invocation carries a real compute cost that recurs forever.
The trap is how it looks during development. A team builds an AI summarisation feature, tests it with a few hundred calls, sees a negligible bill, and ships it to everyone on every plan as a differentiator. Six months later it is being called millions of times a month and has become one of the largest lines on the invoice, sitting inside a flat priced plan that never accounted for it.
What makes this worse than ordinary cost growth is that usage is unbounded by design. You encouraged adoption, adoption succeeded, and every success now costs money in direct proportion. Traditional optimisation does not help much either, since the cost is inherent to the work rather than to inefficiency in your code.
Before launching anything AI powered broadly, calculate cost per invocation and multiply by a realistic adoption scenario, not your test volume. Then decide deliberately whether it belongs in the base plan, in a higher tier, or metered as its own usage component. Retrofitting a charge onto a feature customers already treat as included is considerably harder than pricing it correctly at launch.
Fix the pricing, not just the servers
Engineering optimisation has a floor. If your pricing does not scale with the cost to serve, you can only postpone the problem, and every optimisation you win gets consumed by the next cohort of heavy users.
This is the connection between SaaS infrastructure cost and pricing model that gets missed. A customer generating heavy load should pay more than one generating almost none, and flat or seat based pricing makes that structurally impossible. It is one reason usage based and hybrid models keep gaining ground, with around 61 percent of SaaS companies now using usage based pricing in some form.
You do not need a full pricing migration to benefit. Introducing usage components for the specific resources that drive your costs, storage volume, API calls, processing minutes, aligns revenue with spend for the accounts that matter most, while leaving the base package familiar.
Read More - Backdoors Hit Popular Plugins in 2026: How to Audit WordPress Plugin Security
Make SaaS infrastructure cost visible to the people creating it
The durable fix is organisational rather than technical. Costs grow because the people making architectural decisions never see the financial consequence.
Give engineering teams visibility into what their services cost, monthly, broken down in a way they can act on. Not as a blame exercise, as information. Most engineers will optimise willingly once they can see that a particular design decision costs a meaningful amount every month, because it becomes a solvable problem rather than an abstract concern.
Add cost to the criteria for architectural decisions alongside reliability and delivery speed, and review the largest line items quarterly with someone accountable for the total. This is the difference between a one off cost reduction project that gets undone within a year and a business where the numbers stay under control as you grow.
If your architecture is the constraint, our SaaS development team works on multi tenant architecture and cost efficiency, and our custom software team handles the metering needed to allocate costs properly. Related reading: SaaS product engineering, repricing away from seats, and SaaS for scaling enterprises.
Frequently Asked Questions
What gross margin should a SaaS business target?
Software businesses typically aim for 70 to 80 percent or higher, though genuinely compute heavy products including many AI features run lower and that can be fine if pricing reflects it. The more useful signal than the absolute number is the direction: margin improving as you scale is healthy, margin deteriorating means your unit economics are working against you.
How do I calculate cost per customer?
Tag resources by tenant where your architecture allows, then allocate shared infrastructure using a proxy such as request volume, storage consumed, or compute time. Precision is less important than doing it at all, since the goal is identifying which accounts are disproportionately expensive rather than producing an auditable figure.
Is moving off the cloud the answer?
Occasionally, for businesses with large, stable, predictable workloads where the cloud premium is substantial. For most SaaS companies the operational burden of running your own infrastructure outweighs the saving, and the same money spent on right sizing, storage lifecycle policies, and query optimisation returns more with far less risk.
What is the quickest win?
Shut down non production environments outside working hours and delete orphaned storage. Both are low risk, require no architectural change, and often cut a noticeable percentage of the bill within days. Do these before starting any code level optimisation project.
Should engineers see the cloud bill?
Yes, broken down by service in a form they can act on. Costs grow unchecked mainly because the people making design decisions never see the financial consequence of them. Presented as information rather than blame, most teams optimise willingly once a specific decision is shown to carry a specific recurring cost.
How does AI change infrastructure costs?
Significantly, because inference costs scale with usage in a way traditional software features do not. A feature that is cheap in testing can become a major line item at scale, and it is one of the strongest arguments for usage based pricing components. Model the cost per invocation before launching anything AI powered broadly.
Can we fix this without changing pricing?
Partly, and only for a while. Engineering optimisation reduces the absolute number, and if your pricing does not scale with cost to serve, the underlying divergence returns as you grow. Optimisation buys time to address the pricing model, which is where the durable fix lives.
Talk to our team if your infrastructure economics are getting worse as you grow.