Pricing your SaaS from infrastructure cost: floors, margins, and metering

Quick answer

Infrastructure cost sets the floor, not the price. Compute cost to serve per plan tier, including allocated shared infrastructure and support, then require a gross margin target (commonly 75 to 85 percent for SaaS) as the minimum viable price. Choose a pricing metric correlated with the cost driver: per seat works when cost tracks users, per unit of usage works when cost tracks volume. Cap or meter the dimension that drives cost, or a small number of heavy customers will consume the margin of the entire plan.

Cost-plus pricing is bad strategy: customers pay for value, not for your instance bill. But a price below cost to serve is worse than bad strategy, and most SaaS companies discover the problem only when a large customer arrives on a flat plan and eats a quarter of the infrastructure budget. The discipline is to know the floor precisely and then price above it based on value.

Compute cost to serve per plan

Start by attributing cost per tenant, then aggregate by plan tier. Include four things: direct infrastructure consumed by that tenant, an allocated share of common infrastructure, third-party per-seat or per-call costs, and support cost, which is not infrastructure but belongs in cost to serve.

Plan	Price/mo	Median cost to serve	P90 cost	Median margin
Starter	29 USD	4.10 USD	9.80 USD	86%
Growth	149 USD	21.40 USD	68.00 USD	86%
Scale	599 USD	147.00 USD	512.00 USD	75%

The P90 column is the one that matters. Median margin on the Scale plan looks healthy at 75 percent, but the customer at the 90th percentile costs 512 USD against a 599 USD price, a 15 percent margin. If 10 percent of Scale customers look like that, they are consuming most of the plan's contribution. Averages hide this completely, which is why cost to serve must be measured as a distribution.

Find the margin destroyers

Every usage-based product has a tail of customers whose behavior is orders of magnitude off the norm: the tenant with 400 GB of stored documents on a plan designed for 5 GB, the one polling an endpoint every second, the one running a report that scans the entire dataset nightly. Rank tenants by cost to serve divided by revenue and look at the worst twenty.

Usually there are three responses and you need all of them. Fix the engineering inefficiency where the cost is avoidable, such as adding an index or caching a report. Meter or cap the dimension where the usage is legitimate but unbounded. Move the customer to a plan that reflects their consumption where neither applies. The measurement technique is covered incost per tenant.

Choose a pricing metric that tracks cost

The pricing metric should correlate with what actually drives your cost, or the two curves diverge and margin erodes as you grow.

Per seat works when cost scales with people: collaboration tools, CRMs, anything where each user adds roughly the same load. It fails badly when one seat can generate unlimited load, which is the situation for most data and automation products. Per unit of usage, API calls, gigabytes processed, documents indexed, jobs run, aligns naturally with infrastructure cost but is harder for customers to forecast. A hybrid, a platform fee plus metered usage above an included allowance, is the common compromise and generally the right one when cost is driven by volume rather than headcount.

Set the floor from the distribution, not the median

Price a flat plan against the P75 or P90 cost to serve, not the median, because customers self-select and the ones who choose an unlimited plan are disproportionately heavy users. If median cost is 21 USD but P90 is 68 USD, a 79 USD plan that looked comfortable at 73 percent margin is actually at 14 percent margin for a tenth of its customers, and that tenth will grow over time as heavy users discover the plan.

Include cost in feature decisions

Features have a cost to serve too. Unlimited history retention, real-time sync, high-resolution exports, and per-customer isolated infrastructure all add recurring cost per customer. Before adding a feature to a tier, compute the incremental monthly cost per tenant and check the tier still clears the margin target. Features shipped into the wrong tier are a common and hard-to-reverse source of margin decay, because pulling a capability back from existing customers is far harder than pricing it correctly initially.

Re-run the analysis quarterly

Cost to serve moves. Usage patterns change, features ship, efficiency work lands, and commitment coverage shifts the underlying rates. Re-compute per-plan cost to serve and the tenant distribution every quarter, and treat a sustained margin decline on any plan as a pricing or engineering action rather than an observation.

Know the cost of a feature before it ships

The cheapest time to discover that a feature adds 6 USD per tenant per month is while it is still a pull request. C3X prices the Terraform for new infrastructure before merge, which lets a team divide the monthly delta by expected tenants and check the number against the plan's margin target before the feature reaches customers and becomes difficult to reprice. Seecost per customer for the metric itself.

FAQ

Should infrastructure cost determine SaaS pricing?

It should set the floor, not the price. Customers pay for value, so cost-plus pricing leaves money on the table, but pricing below cost to serve is worse. Compute cost to serve per plan tier including allocated shared infrastructure and support, apply a gross margin target commonly between 75 and 85 percent, and treat the result as the minimum viable price.

Why measure cost to serve as a distribution rather than an average?

Because averages hide margin destroyers. A plan priced at 599 USD with a median cost to serve of 147 USD looks like 75 percent margin, but if the 90th percentile customer costs 512 USD they run at 15 percent margin, and a tenth of customers like that can consume most of the plan's contribution. Track median and P90 separately.

How do I find the customers destroying margin?

Rank tenants by cost to serve divided by revenue and examine the worst twenty. Typical culprits are tenants storing hundreds of gigabytes on a plan designed for a few, polling endpoints every second, or running full-dataset reports nightly. Respond with engineering fixes where cost is avoidable, metering or caps where usage is legitimate but unbounded, and plan migration where neither applies.

What pricing metric should I choose?

One that correlates with the actual cost driver. Per seat works when each user adds roughly equal load, as in collaboration tools, and fails when one seat can generate unlimited load, as in most data and automation products. Per unit of usage aligns with infrastructure cost but is harder to forecast, so a platform fee plus metered usage above an included allowance is usually the right compromise.

Should a flat plan be priced against median or P90 cost to serve?

P75 or P90. Customers self-select, and those choosing an unlimited or flat plan are disproportionately heavy users, so the population drifts toward the expensive tail over time. Pricing against the median produces a plan that looks profitable at launch and steadily erodes as heavy users discover it.

How should features be evaluated against margin?

Compute the incremental monthly cost to serve per tenant before adding a feature to a tier, then confirm the tier still clears its margin target. Unlimited retention, real-time sync, high-resolution exports, and per-customer isolation all add recurring cost. Features placed in the wrong tier are hard to reverse, since removing a capability from existing customers is far harder than pricing it correctly up front.

What to do next

Check a feature against your margin target before it ships. C3X prices new infrastructure from Terraform in the pull request. See the quickstart.