Which Startup Costs Should Sit in Cost of Revenue?

What cost of revenue means

Cost of revenue is the cost of delivering the product to the users you have now and getting paid for that usage.

That definition is much more useful for founders than starting from accounting terminology alone. It keeps the question practical. Which costs grow because customers use the product? Which costs grow because the company itself is getting bigger? Which costs belong to a feature, and which belong to the organization around it?

In Stavia, the current structure reflects that logic well. The cost-of-revenue layer includes payment processing, flat variable cost for paid users, flat variable cost for free or trial users when relevant, Product usage APIs, and Generative AI APIs. Each of these belongs close to margin because each of them is tied to serving the product, not to running the company around it.

What usually belongs there

A useful cost-of-revenue layer usually begins with the product itself, not with the payment processor.

For many software businesses, the first real cost-of-revenue question is: what changes when one more user uses the product? Sometimes that answer is simple. A startup may have a flat serving cost per active paid user. Sometimes it is more usage-heavy. Product APIs, verification tools, data providers, messaging, or AI features may scale with usage caps, feature adoption, or plan mix. In that kind of business, the cost-of-revenue layer needs to be closer to product behavior than to a generic hosting assumption.

Then there is non-paid usage. This is one of the places where early-stage models often become too optimistic. A free or trial user can consume real product-serving resources before the company has enough paid revenue to support them. The current Stavia logic models that explicitly through separate non-paid variable cost and non-paid buckets inside usage-based API and AI cost logic. That is important because trial and free serving cost affects company-level margin even when paid-user unit economics still look healthy.

Payment processing belongs here too, but it is easier to understand once the broader logic is clear. It is part of cost of revenue because it scales with collecting payments from customers.

Examples from real software businesses

Public company filings are useful here because they show how different software businesses really describe cost of revenue.

Twilio is a good example of an API-heavy business. In its 2025 annual report, Twilio says cost of revenue consists primarily of fees paid to network service providers, and also includes cloud infrastructure fees and customer-support personnel costs. That is what cost of revenue looks like when the product depends heavily on third-party networks and infrastructure. See Twilio annual reports.

HubSpot is a cleaner subscription-software example. HubSpot says cost of subscription revenue consists primarily of managed hosting providers and other third-party services, and it explicitly notes that it expects hosting scale benefits over time relative to subscription revenue. That is much closer to the classic SaaS story founders often have in mind when they think about high gross margins. See HubSpot annual reports.

Datadog shows a third pattern. In its 2025 filing, cost of revenue increased primarily because of third-party cloud infrastructure hosting and software costs, plus related personnel costs. That is a good example of a usage-heavy SaaS product where infrastructure intensity matters directly to margin. See Datadog annual reports.

These examples are useful because they show that cost of revenue is not one universal list. It depends on what kind of product you run and how it is delivered.

What should stay outside

A cost can feel closely connected to the product and still belong outside cost of revenue.

Payroll is the clearest example. Product and engineering salaries are critical to the business, but they are still driven by hiring decisions, roadmap timing, and company structure. That is why payroll sits outside cost of revenue in this model.

Recurring overhead stays outside too. Software subscriptions, accounting, insurance, admin services, and similar costs matter for burn, but they do not usually scale in the direct "this customer used the product today" way that cost of revenue is trying to capture. The same is true for one-time costs such as legal setup, launch work, or project-based implementation. They are real costs, but they do not belong close to gross margin.

Acquisition spend is another common source of confusion. It is customer-related, but it is still growth spend rather than cost of delivery.

The gray areas

The hardest classification cases usually come from costs that sit between product and company.

One common mistake is pushing product and engineering payroll toward cost of revenue because the work feels essential to delivery. In practice, that makes gross margin too heavy and hides hiring decisions that should stay visible elsewhere.

Another is burying usage-based product cost in overhead. If the cost scales with plan limits, utilization, or user behavior, it belongs much closer to gross margin than a general company-running expense.

Free and trial usage is another frequent blind spot. The company may show attractive paid-user economics and still carry a meaningful margin problem because non-paid users are expensive to serve.

And finally, founders often keep flat assumptions too long. A simple per-user line is useful in the beginning, but once a product becomes meaningfully usage-driven, it is better to model it as usage-based cost instead of leaving it as a flat dial forever.

How it changes margins

This classification work matters because each of these views is trying to answer a different business question.

Monthly Forecast and P&L use total cost of revenue. That means company-level gross margin includes all product-serving cost, including free or trial serving cost where it exists. That is the right lens for understanding the business as a whole. If a startup is expensive to run because non-paid users consume a lot of product resources, company margin should show it.

Monthly Forecast

P&L

P&L takes the same logic and presents it more formally. Revenue minus total cost of revenue becomes gross profit. Everything else sits below that as operating expense. This is where good classification starts to matter a lot. If product-serving cost is misclassified, the founder ends up trusting the wrong gross margin. If payroll or overhead is pushed too close to margin, the business can look structurally weaker than it really is.

Unit Economics

Unit economics answers a narrower question. In Stavia, the unit-economics view focuses on paid-serving cost only: processing, paid flat variable cost, paid product usage, and paid AI cost. Free or trial-only serving cost is excluded from that per-paid-subscriber view. That makes unit margin useful for pricing and contribution decisions, while company gross margin still captures the wider burden of the business.

This is also the point where benchmarking becomes useful. Benchmarkit's 2025 SaaS data shows median total gross margin at 77% and median subscription gross margin at 81%, but public cloud/software companies still vary widely. The BVP Cloud Index currently shows examples such as AppFolio at 63.5%, Atlassian at 85.0%, and Adobe at 89.6% gross margin. That spread matters. It shows why founders should benchmark against comparable business models, not against one generic SaaS number. See Benchmarkit benchmarks and the BVP Cloud Index.

For AI-heavy products, the range can be much lower. BVP's 2025 State of AI says the AI “Supernovas” it surveyed averaged only 25% gross margins. That is a useful reminder that once a startup becomes inference-heavy, normal SaaS margins stop being a safe assumption. See BVP State of AI.

In Stavia

A good workflow is to start with the question behind the cost.

If the cost comes from serving and monetizing the product, it probably belongs in cost of revenue. Use payment processing for revenue collection, flat per-user lines for simple serving costs, and Product usage or Generative AI APIs when product behavior is more usage-driven.

If the cost comes from running the company, it probably belongs elsewhere. Payroll goes in Team. Recurring non-payroll overhead goes into SG&A. Lumpy or project-style work goes into one-time costs. Acquisition lives in its own logic.

That keeps the model aligned with how the business actually behaves. It also keeps the output views more trustworthy, because Monthly Forecast, P&L, and Unit Economics are reading from the right layers.

Conclusion

A clean definition for product-serving cost does more than tidy up the model.

It makes gross margin readable. It makes unit economics more honest. It helps the founder separate the cost of serving the product from the cost of building the company around it.

That is exactly the kind of distinction that makes a startup model useful.