.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
What Is Cost Plus Pricing a Comprehensive Guide for SaaS Executives
Cost-plus pricing looks simple: calculate the cost to serve a customer, add a markup, and quote the total. For a software executive facing cloud bills, support demands, and pressure to protect gross margin, that logic can feel responsible. It also carries an appealing promise: every deal should pay for itself.
The problem is that SaaS buyers do not purchase our infrastructure bill. They purchase faster sales cycles, fewer outages, cleaner workflows, better compliance, or access to a system their teams rely on every day. A price built mainly from our cost can undercharge high-value customers, overcharge low-value ones, and make every efficiency gain harder to keep.
Monetizely's position is clear: SaaS companies should not use cost-plus as their primary pricing model. Cost should set a disciplined price floor and protect against expensive usage, while packages and customer-facing metrics should reflect the value customers receive.
Cost-plus pricing pays the supplier's bill, not the buyer's value
Cost-plus pricing sets price by taking an identified cost base and adding a predetermined markup. In its simplest form:
Price = Cost × (1 + Markup)
A related version starts with a target gross margin:
Price = Cost ÷ (1 - Target Gross Margin)
The distinction matters. A 70% gross-margin target does not mean adding 70% to cost. If it costs $100 to serve an account, a 70% markup yields a $170 price and a 41.2% gross margin. Reaching a 70% gross margin requires a price of $333.
In government contracting, cost-reimbursement arrangements pay allowable incurred costs up to an agreed ceiling, with specific forms of fee layered on top. The Federal Acquisition Regulation treats such contracts as appropriate only when requirements or cost estimates are too uncertain for fixed pricing, and it prohibits cost-reimbursement contracts for commercial products and services. As of March 13, 2026, that is a useful warning for SaaS leaders: cost-plus was built for uncertainty in delivery, not for repeatable commercial software.
The comparison below clarifies why the distinction is more than accounting.
Exhibit 1. Cost-plus and SaaS pricing answer different commercial questions
| Decision | Cost-plus pricing asks | A SaaS executive must answer |
|---|---|---|
| Starting point | What did it cost us to serve this account? | What job is the customer paying us to do? |
| Customer-facing logic | Costs plus a markup | A unit the buyer can understand, forecast, and connect to value |
| Margin control | Raise price when cost rises | Set a floor, redesign the meter, or limit costly usage |
| Incentive | Recover supplier cost | Expand adoption while rewarding efficient delivery |
| Main risk | The vendor absorbs too much cost | The buyer sees a bill unrelated to outcomes or use |
Cost-plus is therefore a financial control, not a full commercial strategy.
A classic SaaS product combines account-specific costs with shared costs. A customer may use more storage, create more API calls, or require a premium support tier. Those are real serving costs. Yet the core product also rests on shared code, security operations, product development, sales capacity, and a cloud platform built for many customers.
Allocating all of those expenses to each account can produce a number, but not necessarily a useful price. A $30,000 annual account might appear unprofitable if we load a large share of R&D and sales expense into its cost base. The same account can become highly attractive once the installed base grows and fixed costs spread across more customers. The customer's value did not change merely because our allocation changed.
Cost-plus also creates an awkward incentive. When a provider's price rises automatically with its own cost, the customer bears some of the burden of inefficient architecture, weak vendor procurement, or an overly generous service model. Buyers rightly resist that arrangement unless they are funding uncertain custom work.
A well-run SaaS company separates two questions:
- What is the incremental cost of serving one more unit of use?
- What does that unit mean to the customer?
- What minimum economics must the account clear after discounts, support, and third-party costs?
Only the third question belongs directly to cost-plus logic. The first two determine the price design.
Executives often use “markup” and “gross margin” interchangeably during pricing reviews. They are not interchangeable, and the error can create false confidence in a new rate card.
The table below holds unit cost at $100 and shows the price required for different gross-margin targets.
Exhibit 2. A fixed markup produces less margin than most SaaS leaders expect
| Unit cost | Markup on cost | Customer price | Gross profit | Gross margin |
|---|---|---|---|---|
| $100 | 60% | $160 | $60 | 37.5% |
| $100 | 100% | $200 | $100 | 50.0% |
| $100 | 150% | $250 | $150 | 60.0% |
| $100 | 233% | $333 | $233 | 70.0% |
| $100 | 400% | $500 | $400 | 80.0% |
The practical implication is direct: a company that wants a 70% gross margin must price at roughly 3.33 times its relevant cost, not 1.70 times.
Even that calculation should not dictate the list price. Consider two customers that each cost $100 per month to serve. One uses a workflow product to coordinate a five-person internal team; the other uses the same product to manage a regulated process that prevents delays on multimillion-dollar transactions. A single cost-plus rate treats those customers as economically equal when their willingness to pay is plainly different.
The market's most durable SaaS models do not ignore cost. They make a more disciplined choice: they charge on units that customers can plan around and that broadly scale with product value, while internal teams monitor the cost of delivering those units.
Four current pricing pages illustrate the pattern.
Exhibit 3. Established SaaS vendors use customer-facing meters, not account-cost invoices
| Vendor | Published commercial structure as of September 7, 2026 | What the customer is buying | Pricing lesson |
|---|---|---|---|
| Salesforce | Sales Cloud lists plans from $25 per user per month for Starter to $350 per user per month for Unlimited, billed annually for higher tiers. | User access, product depth, and enterprise capability | The seat remains useful when value rises with the number of people working in the system. |
| Atlassian | Jira lists Standard at $7.91 and Premium at $14.54 per user per month, with plan-level differences in support, storage, automation, and controls. | Collaboration capacity plus a level of reliability and administration | Tiers let the vendor capture higher willingness to pay without claiming that every premium customer costs more to host. |
| Datadog | Infrastructure Monitoring starts at $15 per host per month for Pro with an annual commitment, or $18 on demand; Enterprise starts at $23 per host per month annually. | Observability across monitored infrastructure | A host is a visible operating unit that scales with the customer's monitored environment. |
| Snowflake | Customers pay for consumption across compute, storage, and data transfer; total cost is credits consumed multiplied by the credit price in the customer's agreement. | Computing and data-platform use | Resource-based pricing can be appropriate when the resource is central to the service and usage can be measured cleanly. |
The common thread is not a single meter. Salesforce and Atlassian emphasize seats and packages; Datadog ties price to hosts; Snowflake charges for consumption. Each model gives the buyer a recognizable unit and gives the vendor a way to manage economics without exposing its internal cost ledger.
Snowflake comes closest to a cost-informed design because compute usage has a direct infrastructure component. Yet even Snowflake does not present each buyer with the cloud-provider bill plus a markup. It sets credit rates by agreement and separates compute, storage, and transfer into defined commercial units.
The Monetizely 5-Step Pricing Framework puts cost-plus in context by ordering the decisions that create a workable SaaS price. The five steps are goals and segmentation, packaging, pricing metric, price points, and operationalization. The sequence matters because price is not the first decision. We first decide what the business must achieve and which buyers matter; then build offers for those buyers; select the unit to charge on; set rates; and make the model work in product, billing, sales, and finance. As discussed in Monetizing Agentic AI, the discipline prevents a company from using a number - including a cost calculation - as a substitute for commercial judgment.
A company seeking rapid adoption may accept lower initial margins in a new segment. A mature category leader may prioritize expansion revenue and gross-margin protection. Those are legitimate choices, but “recover our cost” is not a growth strategy.
Segmentation changes the answer further. A 20-person company may need basic workflow management with self-service support. A 5,000-person enterprise may require audit controls, integrations, data residency, procurement support, and a service-level agreement. Charging both accounts cost plus the same markup ignores why the larger buyer accepts a higher price.
Packages should separate different needs before rates separate different budgets
Good packages make value differences visible. Basic buyers should not be forced to fund enterprise controls they will never use, and large customers should not need a custom discount merely to buy the governance, support, or scale they require.
Atlassian's Jira plans show the principle in practice. The published Standard, Premium, and Enterprise offers differentiate not merely by user count, but also through support, uptime commitments, storage, automation capacity, and administration. As of September 7, 2026, Jira Premium advertises a 99.9% uptime SLA, while Enterprise advertises a 99.95% SLA.
Cost still belongs in package design, but as a constraint. If a premium support offer requires named technical resources, its price must cover that commitment. The offer should be defined by a customer need, not by an internal staffing allocation.
The meter should follow value while containing costly behavior
The pricing metric is the unit a customer sees on an order form and invoice. A useful metric meets four tests:
A metric should pass all four tests before it becomes customer-facing. Cost-plus often passes the economic-protection test, but fails the other three.
The stronger answer for a product with uneven serving costs is a named primary meter with explicit guardrails. A data platform may charge by credits while applying storage and transfer rates. An observability product can charge per host, then price exceptionally data-heavy services separately. A collaboration platform can charge per seat, while reserving high-touch implementation for a defined services package.
That architecture is not a retreat into a vague hybrid. The primary meter remains clear. Additional charges appear only where they protect the economics of a specific, measurable cost driver.
Cost belongs in the rate floor, discount rules, and overage design
Cost-plus becomes valuable after the customer-facing design is set. We recommend using it in three tightly defined places:
A floor is different from a list price. Suppose a workflow platform costs $1,200 per year to serve a customer and needs a 70% gross-margin floor. The account must generate at least $4,000 in annual revenue before support costs or commissions. A list price of $4,000 may still be wrong if the customer receives $25,000 in annual value and comparable buyers accept $10,000. The floor blocks a bad deal; it does not define the best deal.
The next exhibit shows how cost should shape decisions without becoming the invoice logic.
Exhibit 5. Cost should govern exceptions, not replace the core pricing model
| Situation | Primary customer-facing price | Internal cost rule | Executive action |
|---|---|---|---|
| Standard multi-user SaaS | Per seat or account tier | Monitor cost per active account | Hold list price to value and segment fit |
| Infrastructure-heavy product | Per host, credit, GB, or transaction | Track unit cost by usage band | Set included use and overage rates that preserve margin |
| Enterprise plan with advanced support | Annual platform fee plus seats or another primary meter | Price named support and service commitments separately | Require approval for nonstandard support terms |
| Custom implementation | Fixed scope or time-based services fee | Estimate delivery cost before contracting | Keep custom work out of the recurring software price |
The discipline is simple: use cost to decide what we can profitably offer, and use customer value to decide what we ask customers to pay.
A sound rate card can fail if product events, billing rules, and sales terms tell different stories. Monetizely's view is that operational work deserves the same executive attention as the pricing decision itself.
The operating model should make five facts visible every month:
A customer should never need to understand our cloud architecture to validate an invoice. They should be able to see the purchased package, the included allowance, the measured usage, and the contract rate. That standard protects trust while preserving our ability to manage margin.
Cost-plus pricing solves a real problem: it prevents us from selling a dollar of service for less than a dollar of cost. On its own, however, it mistakes financial recovery for pricing strategy. SaaS earns the right to durable margins by turning repeatable software into a clear customer benefit, then charging on a unit that makes that benefit legible.
The companies that scale do not abandon cost discipline. They place it behind a commercially intelligible offer. Salesforce makes the user and edition central. Atlassian combines seats with plan-based capability. Datadog makes monitored infrastructure the unit. Snowflake applies consumption units to a resource-intensive platform. None asks the customer to audit its internal cost base before deciding whether the product is worth buying.
Monetizely's position is therefore committed: price SaaS on value-aligned units, use packages to capture meaningful differences in willingness to pay, and enforce cost-derived floors so growth does not dilute margin.
Make the primary pricing metric a board-level product decision. Assign one executive owner across product, finance, sales, and billing rather than allowing each function to optimize its own local preference.
Set a three-year pricing objective before approving a new rate card. Choose whether the next phase prioritizes adoption, expansion, margin improvement, or movement into a higher-value segment, then evaluate the model against that declared objective.
Create one company-wide definition of an economically healthy customer. Use it in annual planning, sales compensation, product investment, and renewal reviews so teams do not celebrate ARR that cannot support the business.
Review pricing architecture after major changes in product capability or target segment. A new enterprise control layer, a shift from self-service to sales-led acquisition, or a major expansion in customer use cases can make an old package structure obsolete before the price itself looks wrong.
Footnotes
- Monetizing Agentic AI. https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- U.S. Federal Acquisition Regulation, Subpart 16.3, “Cost-Reimbursement Contracts,” effective March 13, 2026. (acquisition.gov)
- Salesforce, “Sales Cloud Pricing,” accessed September 7, 2026. (salesforce.com)
- Atlassian, “Jira Pricing,” accessed September 7, 2026. (atlassian.com)
- Datadog, “Pricing - Infrastructure Monitoring,” accessed September 7, 2026. (datadoghq.com)
- Snowflake, “Pricing Calculator Help and FAQs,” accessed September 7, 2026. (snowflake.com)