SaaS gross margin is the percentage of revenue remaining after direct service-delivery costs are subtracted.
For a cloud product, the difficult part is not the formula. It is deciding which costs belong to delivering the service and allocating those costs consistently across products, customers, and shared infrastructure. Raff Technologies can provide infrastructure used by these workloads, but the business still needs a repeatable way to connect VMs, databases, storage, third-party services, and operational support with customer revenue.
A 1 percentage-point margin change can materially affect how much revenue remains for product development, sales, administration, and future infrastructure investment. This guide explains how to define SaaS cost of goods sold, calculate infrastructure cost per customer, choose an allocation method, and interpret margin movement without sacrificing reliability. It complements SaaS Infrastructure Cost: From MVP to Series A, which covers stage-based budgeting rather than customer-level unit economics.
SaaS gross margin measures delivery efficiency
Gross profit and gross margin answer related but different questions.
Gross profit = recognized revenue - SaaS COGS Gross margin percentage = (recognized revenue - SaaS COGS) / recognized revenue x 100
Gross profit is a currency amount. Gross margin is the percentage of revenue left after direct delivery costs.
An illustrative monthly example:
| Item | Amount |
|---|---|
| Recognized subscription revenue | $60,000 |
| Production infrastructure | $7,000 |
| Direct third-party service usage | $3,000 |
| Customer support and service delivery | $5,000 |
| Total SaaS COGS | $15,000 |
| Gross profit | $45,000 |
| Gross margin | 75% |
The 75% result is not automatically good or bad. It must be interpreted against the product model, customer segment, support requirements, infrastructure intensity, and the company's accounting policy.
Industry sources often use roughly 70% to 85% as a reference range for SaaS gross margin, but products with heavy data processing, media delivery, human service, or dedicated customer infrastructure may operate differently. A benchmark should start an investigation, not replace one.
Gross margin should also remain separate from net margin. Sales, marketing, general administration, and most new-product research typically appear below gross profit rather than inside the direct cost of delivering the existing service.
SaaS COGS needs an explicit policy
SaaS cost of goods sold is the direct cost required to deliver and maintain the service for current customers. The exact classification varies by company and accounting policy, so finance and accounting ownership matters.
A practical policy can begin with this decision table:
| Cost | Usually included in SaaS COGS | Policy judgment required |
|---|---|---|
| Production compute | Yes | Separate product and internal workloads |
| Production databases and caches | Yes | Allocate shared clusters consistently |
| Customer file storage and egress | Yes | Attribute by tenant when measurable |
| Backups and production recovery | Usually | Separate operational protection from broad business continuity |
| Third-party APIs used to deliver the product | Yes | Exclude internal productivity tools |
| Customer support | Often | Define which support roles are direct delivery |
| Reliability and production operations labor | Often | Allocate only the delivery-related portion |
| Payment processing | Often | Treatment depends on finance policy |
| Development and staging infrastructure | Sometimes | Distinguish cost to produce from cost to serve |
| New feature development | Usually no | Normally research and development expense |
| Sales and marketing | No | Operating expense |
| General administration | No | Operating expense |
The goal is not to find one universal classification. It is to make the company's classification stable enough that one month can be compared with another.
Three rules improve consistency:
- Use recognized revenue and costs from the same period.
- Document which labor, infrastructure, and vendor costs are included.
- Do not change the policy merely to improve the reported percentage.
A management dashboard may use a broader operational measure than the official financial statements. Label it clearly. For example, infrastructure contribution margin or cost to serve can be useful internal metrics without being presented as accounting-approved gross margin.
Infrastructure cost per customer is an operational unit cost
Infrastructure cost per customer connects cloud spend to a measurable business unit.
Infrastructure cost per active customer = attributable monthly infrastructure cost / active customers in the same period
Suppose the product has $9,000 of attributable monthly infrastructure cost and 300 active paying customers:
$9,000 / 300 = $30 per active customer
That number becomes useful only when the denominator matches how value and cost are created.
| Unit | Appropriate when | Main limitation |
|---|---|---|
| Active customer | Accounts have broadly similar usage | Hides large customer differences |
| Paid tenant | One organization maps to one workload boundary | Seats and usage may vary widely |
| Active seat | Cost grows with users | Data and compute may not follow seats |
| Transaction or job | Processing drives infrastructure | Requires reliable event counts |
| 1,000 API requests | Request volume drives compute | Ignores storage and support |
| GB stored or transferred | Data is the dominant cost | Ignores fixed platform cost |
| Workload or product | Portfolio decisions matter | Does not show individual customer economics |
Choose one primary unit and one or two diagnostic units. A B2B application might track cost per paid tenant, storage per tenant, and support hours per tenant. An API product might track cost per million successful requests and cost per customer segment.
Do not divide total company cloud spend by all registered accounts. Use customers that received service during the same period, and exclude old, inactive, internal, or free accounts unless the metric intentionally includes them.
Allocation methods create different answers
Cloud costs usually fall into four groups:
| Cost group | Example | Preferred treatment |
|---|---|---|
| Direct customer cost | Dedicated VM or customer-specific storage | Assign directly |
| Direct product cost | Product-specific app and database resources | Assign to the product, then its customers |
| Shared platform cost | Monitoring, load balancing, shared database, backups | Allocate by a documented driver |
| Unallocated cost | Unknown owner or missing metadata | Keep visible until resolved |
The decision framework should use the simplest defensible method.
| Allocation method | Choose it when | Example | Risk |
|---|---|---|---|
| Direct attribution | The resource belongs to one customer or product | Dedicated tenant VM | Most accurate, but only for isolated resources |
| Usage-based allocation | Reliable usage data exists | Requests, CPU time, GB stored, egress | Measurement can become complex |
| Revenue-weighted allocation | Shared cost supports customers with different contract values | Enterprise platform overhead | Revenue may not reflect technical consumption |
| Equal allocation | Customers use a genuinely similar service | Small homogeneous tenant base | Penalizes light users and hides heavy users |
| Capacity-weighted allocation | Reserved capacity is divided intentionally | Database or worker pool | Requires a stable capacity model |
| Keep as shared overhead | No fair driver exists yet | Internal monitoring platform | Customer cost remains incomplete |
Use direct attribution first. Allocate measurable shared costs second. Keep the remaining shared or unknown amount visible instead of forcing false precision.
A practical allocation sequence is:
Direct customer costs + allocated product costs + allocated shared platform costs = attributable cost to serve Attributable cost to serve / selected business unit = unit cost
For shared infrastructure, the driver should reflect causation where practical. Storage can follow bytes retained, API processing can follow requests or execution time, and support can follow recorded service effort. Equal allocation is acceptable for a small, homogeneous customer base, but it should be replaced when usage differences become material.
Customer and workload patterns explain margin movement
A falling gross margin does not always mean the cloud provider became expensive. The cost model may be revealing a product, pricing, or customer-fit problem.
Fixed, variable, and step costs behave differently
| Cost behavior | Example | Margin effect |
|---|---|---|
| Fixed baseline | Minimum production stack | Margin improves as revenue grows |
| Variable | Egress, object storage, API calls | Cost follows usage |
| Step cost | Second app node or larger database tier | Margin drops, then may recover with growth |
| Dedicated customer cost | Isolated environment or custom support | Depends on contract pricing |
| Temporary cost | Migration or launch environment | Should not become permanent baseline |
A step increase may be healthy when it creates capacity for contracted growth or reduces a material reliability risk. It becomes a concern when the additional capacity stays idle or cannot be connected to customer value.
Customer segments can have different economics
One average can hide several businesses inside the same product.
| Segment | Revenue pattern | Cost pattern | Question |
|---|---|---|---|
| Small self-service | Low revenue, low support | Shared infrastructure | Does automation keep delivery cost low? |
| Data-heavy customer | Higher storage and egress | Variable infrastructure | Is usage priced or limited correctly? |
| Enterprise tenant | High contract value | Isolated or customer-specific infrastructure and support | Does the contract cover isolation and service effort? |
| Free or trial user | No current revenue | Compute, storage, and support | Is the acquisition value worth the delivery cost? |
| Legacy plan | Older price | Current service cost | Has cost outgrown the contract? |
Track revenue and cost by segment before changing architecture for the entire customer base.
Margin movement should be decomposed
A useful monthly bridge is:
Prior-period cost to serve + new customers + higher customer usage + storage and retention growth + support and vendor changes + reliability investments * right-sizing and cleanup * customer churn or reduced usage = current-period cost to serve
This separates healthy growth, deliberate reliability spending, temporary projects, and avoidable waste.
Margin improvement should protect reliability
Improving SaaS gross margin is not a mandate to remove every redundancy, backup, or support function. The objective is to reduce cost that does not create customer value or required resilience.
Use these operating priorities:
Repair ownership and allocation first
A large unallocated pool makes optimization unreliable. Apply consistent workload, environment, owner, customer, and lifecycle metadata before drawing customer-level conclusions. The Server Naming Convention guide provides the governance model.
Remove idle and expired infrastructure
Temporary environments, detached storage, old snapshots, and unused services can become permanent COGS. Use Idle Infrastructure Cost for the keep, resize, schedule, archive, or delete decision.
Right-size the constrained layer
Do not resize every component because one role is constrained. Measure app, worker, database, storage, and network behavior separately. A larger VM is appropriate when it solves a measured bottleneck; it is not a substitute for understanding the workload.
Align pricing with expensive usage
When customer cost is driven by storage, egress, jobs, API calls, or premium support, the commercial model should acknowledge that driver. Options include usage allowances, paid overages, higher tiers, dedicated-environment pricing, or explicit service packages.
Review retention and third-party services
Logs, backups, objects, API vendors, observability, and support tools can grow without a matching pricing decision. Retention and vendor reviews should follow customer, recovery, compliance, and operational requirements.
Preserve recovery and service commitments
A higher reported margin is not an improvement when it depends on untested backups, insufficient capacity, or reduced customer support that increases churn and incidents.
Raff cost attribution starts with workload metadata
Raff customers can build a unit-cost model by combining current billing or account data with a maintained resource inventory.
A practical inventory maps each resource to:
- stable resource ID;
- workload or product;
- production or non-production environment;
- owner;
- customer or customer segment where appropriate;
- lifecycle state;
- allocation rule;
- recovery and retention policy.
The model can include Raff VMs, Managed Databases, Object Storage, and Data Protection. Use the live pricing page and verified billing records rather than copying plan prices into a permanent spreadsheet without effective dates.
A simple Raff allocation table might look like this:
| Resource | Workload | Allocation |
|---|---|---|
| Shared application VMs | Main SaaS product | Active tenants or request share |
| Dedicated customer VM | Enterprise tenant | Direct to customer |
| Managed database | Main SaaS product | Query, storage, or active-tenant share |
| Object storage | Customer files | Stored bytes by tenant where available |
| Backups | Protected workload | Follow the protected resource allocation |
| Development and staging | Engineering delivery | Separate cost-to-produce pool |
The existing Power BI cloud cost guide explains how to turn a cost ledger and ownership table into a reusable reporting model. Start with a spreadsheet when the resource footprint is small, but preserve stable identifiers and definitions so the model can grow without being rebuilt.
Raff's infrastructure model can make direct resource costs easier to map to workloads. Customer economics still depend on disciplined allocation, product usage data, support effort, and the revenue policy used by the business.
