Pricing Approaches: Choose a Price and Unit
A seller can calculate a perfectly tidy markup and still hesitate before showing the price to a buyer. The arithmetic says the offer pays for itself. The buyer compares it with another offer, asks what the monthly bill will be, and decides whether the benefit is worth paying for. Those are different questions, and a single percentage cannot answer all of them.
Suppose a small team is setting the price for a reporting service. It needs to cover the cost of running the service, but some customers will use it much more than others. A rival quotes a lower monthly figure without including the same amount of service. The team now needs two decisions: what price makes sense for the offer, and what the customer will be charged for. Treating those decisions separately makes the alternatives easier to judge.
My starting point would be to calculate a cost floor, ask what specific benefit the intended buyer expects, and compare competing offers on equal terms. Only then would I choose a flat fee, a price per user, a usage charge, or a combination. Stripe’s product pricing guidance brings costs, customer value, competitor prices, and business objectives into the pricing decision. None of those inputs supplies a universal number for this particular seller.
Decide what the price must accomplish
Before choosing an approach, define the sale. What exactly does the buyer receive, for how long, and under what limits? A monthly fee for access to a tool means something different from a monthly fee that includes support, training, and a fixed amount of work. If the offer is not defined, a price comparison is mostly a comparison of labels.
The next question is the business objective. A seller trying to cover a predictable service cost may accept a different price from one trying to reach a wider set of customers quickly. A seller that can serve many additional customers at modest extra cost may also make a different choice from one that must add staff for each new account. These are conditions to write down before arguing over a markup. Stripe advises aligning price with business goals and the market, because the same price can serve one objective while frustrating another.
I would also specify the buyer, rather than speak of “the market” as if every customer bought the same thing. For the illustrative reporting service, a manager who needs one occasional report and a team that uses reports every day may see very different value in the same feature. If the team wants both customers, one flat offer may force a poor compromise. If it wants only the frequent user, the occasional buyer’s reluctance should not automatically pull the price down.
That framing prevents a common decision error: making cost, competitors, and customer value compete to be the one true formula. Each answers a different question. Cost asks what the seller must recover. Customer value asks what the buyer sees as worth paying for. Competing offers show what else the buyer can choose. The business objective says which trade-off the seller is willing to make.
Use cost to find a floor, then test the floor
Cost-based pricing begins with a measured cost base and adds a markup. In a cost-plus calculation, the selling price is cost plus cost multiplied by the chosen markup, as Stripe’s cost and value pricing guide explains. This is a useful starting point when the seller can identify the costs of providing an offer and needs a clear reason for the minimum price it proposes. The calculation does not tell the seller whether a buyer wants the offer at that price.
Consider an illustrative calculation, not a market price or a recommended markup. Assume the reporting service costs $2,000 each month to keep available, plus $20 for each active customer account that month. If the seller expects 100 active accounts, the $2,000 becomes $20 per account; adding the $20 account cost produces a $40 cost base per account. A 25% markup on cost adds $10, giving a proposed price of $50 per account per month. The $10 is 25% of the $40 cost base, but only 20% of the $50 selling price. Calling the markup a 25% margin would hide that difference.
The account count matters as much as the percentage. At 50 active accounts, the same assumptions allocate $40 of the monthly fixed cost to each account. Total assumed cost is then $60 per account, while a $50 price would bring in only $2,500 against $3,000 in monthly costs. The shortfall is $500 for that month. The calculation has not failed; its original assumption of 100 accounts has. A seller should show the expected account count beside the cost-plus price and ask whether a lower count would make the offer untenable.
The cost base also needs a boundary. If the illustrative $20 includes only routine delivery while difficult accounts require additional work, the $50 price has less room than it appears to have. If a seller excludes a cost because another part of the business pays it, the calculation may still help with a particular decision, but it should not be described as the full cost of the offer. The practical question is: which costs change when this customer buys, and which continuing costs must the whole customer base support?
I would use cost-plus as the main pricing approach when the offer is fairly standard, costs are understood, and buyers have little reason to pay a premium for a particular seller. Even there, the markup is a proposed number, not a guarantee of a viable price. If the necessary cost-based price is higher than buyers will accept, changing the markup cannot solve the underlying mismatch. The seller must change the offer, its costs, the customers it serves, or its expectation of profit.
Let customer value set the ambition, with a clear limit
Value-based pricing starts with the value a customer perceives, rather than with the seller’s cost, according to Stripe’s comparison of the two approaches. The word “perceives” matters. A seller can believe a service is valuable because it has sophisticated features; a buyer may care only whether those features improve a job the buyer actually has to do. I would ask about that job before using a claimed saving or benefit to justify a higher price.
Extend the illustrative reporting-service example. Suppose one buyer estimates that the service would release five hours of staff time each month and values an hour at $30. The arithmetic suggests a possible $150 monthly benefit. It does not establish that the buyer would pay $150: the time may not be recoverable as cash, the estimate may be uncertain, and the buyer may need to keep some of the benefit to make a purchase worthwhile. A second buyer who uses the service only once a month might see little benefit at all. The same delivery cost can therefore support very different pricing opportunities.
For a value-led price, I would identify the customer’s specific use, ask what the customer would do without the offer, and estimate the difference the offer makes. If the claimed value depends on five hours saved, the seller needs to know whose hours they are and what those hours can be used for. If the benefit is convenience rather than a measurable saving, I would describe the convenience plainly instead of assigning it an invented cash value. The resulting estimate gives a range to consider, not a right to charge the entire amount.
Stripe describes cost and value as possible lower and upper boundaries for a combined approach. In the example, the seller may need more than $40 per account at the expected volume while a frequent user’s perceived benefit could be substantially higher. That leaves room to choose a price. If the intended buyer sees only $30 of monthly benefit and the seller needs $50, there is no workable price between those two figures for the offer as described. Better wording on a price page cannot create value the buyer does not receive.
I would lead with value when buyers can name a meaningful result that differs across customers and the seller can connect the offer to that result. The cost is more work: the seller must understand buyers closely enough to distinguish a real benefit from a hopeful claim. A cost figure comes from the seller’s records; an estimate of buyer value has to survive a conversation with the buyer. When that understanding is missing, a confident value-based price is premature.
Compare rival prices as complete offers
A competitor’s price is useful context, but it is rarely a complete answer. Stripe’s product pricing guidance calls for interpreting competitor prices alongside value and the seller’s own aims. I would first write down what the competing price buys: the service included, its limits, the billing period, and the unit being charged. Only then would I decide whether the rival really offers a cheaper substitute.
Imagine, still illustratively, that a rival advertises $45 per month and the reporting service proposes $50. If the rival’s price covers one user while the $50 offer covers a whole team, the headline figures are not comparable. If both offers serve one user but one includes work the buyer does not need, that extra work may not justify a higher price for this buyer. The point is to compare what the same buyer would pay for the same relevant use, rather than to copy the nearest number found on a pricing page.
Where two offers solve essentially the same problem on similar terms, the competitor’s price deserves substantial weight. A seller charging more should be able to name the difference a buyer would receive and care about. Where the offers differ materially, matching a rival’s number can erase a useful distinction or make a sound offer uneconomic. The competitor’s price is a constraint to investigate, not a price to inherit.
This comparison can also reveal a problem with the offer itself. If buyers repeatedly prefer a simpler competing package, adding more features to defend a higher price may increase cost without increasing perceived value. A narrower package could be the better decision. Conversely, if customers ask for the work that the cheaper rival leaves out, the seller has a reason to keep that work visible in the offer and its price.
Choose a charging unit buyers can understand
After selecting a price range, decide what triggers a charge. Stripe’s pricing-model documentation describes flat-rate, per-seat, tiered, and usage-based structures. These are ways to collect a price, not answers to how much a buyer values the offer. A seller could use the same cost and customer-value reasoning with any of them.
A flat rate gives the buyer one stated amount for a defined period or package. I would favor it when customers receive roughly similar service and a predictable bill helps them decide. The seller then carries the risk that a heavy user consumes more than the price anticipated. The package therefore needs a clear description of what is included; otherwise “flat” can quietly become unlimited work at a fixed price.
A per-seat charge makes the number of users the billing unit. It fits best when an additional user represents a meaningful increase in access or benefit. If the value comes from a shared team result, however, a seat price may make inviting another colleague feel like a separate purchase. A seller should decide whether that consequence supports or frustrates how customers are meant to use the product. The illustrative reporting service might choose a team fee if shared reports are central, even if it could technically count logins.
A tiered structure changes the price as a defined quantity or level changes. The essential decision is what boundary moves a buyer into another tier. If a seller offers a lower unit price after more activity, the buyer needs to understand how the bill changes at that boundary. A tier can accommodate different levels of use, but a tier whose threshold is hard to explain will make the price harder to trust. I would use tiers only when the underlying difference is real enough to describe in a sentence.
Usage-based pricing charges for measured activity. It can fit an offer whose cost or buyer benefit rises with use, provided the seller can define the unit and the buyer can anticipate a reasonable range of bills. For the illustrative service, “reports generated” might be a possible unit, but only if one report means a consistent thing. A buyer who cannot predict the charge may limit use even when the service would help. The seller gains closer alignment with activity at the cost of a less certain bill for the buyer.
A seller can also combine charging mechanics, as Stripe’s pricing-model guidance allows. A base fee with an additional usage charge, for example, could cover continuing availability while letting heavier use add to the bill. I would choose such a combination only if both parts have a distinct purpose the buyer can understand. Adding several meters merely because they can be measured makes comparison and budgeting harder.
Make the choice with one worked offer
Return to the illustrative reporting service with its assumed $2,000 monthly fixed cost, $20 cost per active account, and 100 expected accounts. The $40 cost base per account and $50 cost-plus proposal provide a starting point. The next decision is whether the intended customer receives enough benefit to accept $50 and whether that benefit changes substantially with team size or report volume. The answer cannot be calculated from the cost ledger alone.
If the intended buyer is a small team whose members share the same reports, I would first offer a defined monthly team package at a price above the expected cost floor. A flat package makes the purchase easy to understand and avoids charging each colleague for looking at the same work. I would specify the included service, so the seller knows what the $50 illustration covers. The cost of this choice is that unusually heavy accounts may be underpriced; the seller would need to watch whether the original cost assumptions hold for them.
If heavier use clearly creates more work and buyers can recognize a reliable unit, I would then consider a base fee plus a usage charge beyond an included amount. That changes the bargain: the base pays for access, while exceptional activity raises the bill. Before choosing a rate, I would work through an ordinary month and a busy month from the buyer’s point of view. A charging model is easier to defend when the buyer can reproduce the invoice from the published terms.
If the buyer’s perceived benefit falls below the price needed to cover this offer, I would not hide the gap in a complicated tier. I would reduce what is included, serve a buyer who needs more, or reconsider the cost structure. A pricing model can distribute a charge differently; it cannot make an offer valuable to someone who has no use for it. That is the practical limit of every approach in this article.
Revisit price when the offer or market changes
An initial price rests on assumptions about costs, customer benefit, competing choices, and business aims. Those assumptions can change. Stripe advises considering pricing changes alongside the market and business model. I would revisit the price when the seller changes what is included, when the cost of serving the intended buyer changes, or when customers start comparing the offer with a different alternative.
The first task is to identify what moved. If account costs rose, recalculate the floor. If buyers use only a small part of the package, revisit the offer before raising its price. If a competitor’s apparent discount is really a smaller scope of service, explain the difference rather than matching the headline. If buyers reliably receive greater value than expected, there may be room to charge more, but the seller should still name the value the buyer keeps.
I would change one element of the price story at a time when possible: the amount, the included service, or the billing unit. Otherwise, the seller may not know which change helped or hurt. The goal is a price the buyer can understand and the seller can sustain under realistic use, rather than a number that looks precise only because it came from a formula.