Essay / Product & Entrepreneurship
SaaS Pricing Is a Product Decision Before It Is a Finance Decision
Pricing shapes who a SaaS product serves and how customers experience its value. Explore packaging, usage measures and honest tests of willingness to pay.
Put two versions of the same product beside each other. One charges for every person who joins. The other charges for the amount of work completed. The code might be identical, but the product is inviting different behavior. One makes collaboration a purchasing decision. The other makes activity a purchasing decision.
That is why I see SaaS pricing as part of product design. It decides which customer can start, what they hesitate to do, and when they have to reconsider the relationship. The invoice comes later; the incentives are present from the first interaction.
This is not a formula for choosing a price. It is a way to make the assumptions visible before they harden into plans, permissions, and billing code.
A price is also an interface between the product and the market.
Choose the relationship before the number
Imagine a hypothetical service that helps small businesses organize recurring administrative work. Its users might value fewer missed deadlines, less manual coordination, or a clearer picture of outstanding tasks. Those outcomes are related, but they do not imply the same pricing measure.
Charging per task seems easy to implement. It may also encourage customers to combine unrelated work into fewer tasks or avoid recording small obligations. Charging per user might discourage inviting the external collaborator who would make the workflow useful. A flat subscription removes those particular frictions but can fit very different customers unevenly.
None of those observations proves that a measure is wrong. Each is a hypothesis about behavior. The important step is to ask what the measure rewards and what customers must understand to predict their bill. A metric that is technically convenient can still be difficult to connect to value.
For an early concept such as FiscoBud, I would keep possible pricing structures in that hypothesis category. A product idea does not establish willingness to pay, a sustainable business model, or a preferred billing unit by itself.
A value measure must be understandable
A useful pricing measure needs a credible connection to the job the customer is buying. It also needs to be observable. If customers cannot estimate their usage or inspect how it was counted, they are being asked to trust a calculation they cannot verify.
Consider charging for an automated action. Does a failed attempt count? Does a retry count again? What about an action started by a teammate, a scheduled process, or an integration? These are product questions because the answers affect confidence in using the feature.
Stripe’s usage-based billing documentation describes implementation options for billing around measured usage. Those mechanisms can help record and charge for a chosen unit. They cannot establish that the unit is fair, legible, or aligned with a particular customer’s value. That choice requires evidence from the product and its market.
The interface should therefore make the unit visible before a limit becomes a surprise. A usage view needs enough detail to explain the total and enough restraint to remain understandable. If the billing explanation requires a support call every month, the pricing model has created operational work.
Packaging describes whom the product serves
A plan is a promise about a coherent way to use the product. It should help a customer recognize their situation, not merely distribute a long list of checkmarks across three columns.
An individual working alone may need a reliable core workflow. A team may need shared ownership and review. A larger organization may need different administration and procurement arrangements. Those distinctions can justify packages when they reflect actual differences in how the work happens.
The temptation is to invent packages before learning those differences. Features then become arbitrary upgrade triggers. A basic plan may technically contain the advertised capability while lacking the one supporting feature required to use it sensibly. That is a confusing product boundary, even if the comparison table looks tidy.
I would map a complete customer journey through each proposed package. Can someone finish the promised job? Where does an upgrade appear? Is the reason connected to a new level of value or merely to a missing piece of the original promise? This exercise can reveal packaging problems before billing is implemented.
Predictability is part of the experience
Some customers can tolerate variable costs because the expense follows a measurable business activity. Others need a stable commitment before they can adopt a tool. The same nominal price can therefore feel very different depending on how uncertain the final bill is.
Usage alerts, spending controls, and clear limits can reduce that uncertainty, but they need explicit behavior. Does reaching a limit pause work, reject new work, or continue under an agreed overage rule? A limit that silently interrupts an important process is a product failure. A limit that never constrains anything may not provide the reassurance its interface suggests.
Annual billing adds another choice. It exchanges a longer commitment for a different commercial arrangement, but it does not repair weak product value. Before encouraging a long commitment, the product should make the included service, renewal behavior, and relevant terms easy to understand.
The engineering consequence is that billing state cannot live only on a pricing page. Entitlements, usage, notifications, and access need a consistent interpretation across the application. Pricing simplicity at the surface requires deliberate state handling underneath.
Test willingness to pay with consequential evidence
Asking whether somebody likes a proposed price is easy. Interpreting the answer is harder. A friendly reaction in an interview may reflect interest, politeness, or an imagined future need. It does not necessarily predict a purchase.
A stronger conversation explores the current alternative. What do people do today? Who owns the problem? Who can authorize spending? What would need to change for a purchase to happen? These questions can reveal that a seemingly small subscription requires a budget owner, a security review, or a change in team process.
When the product is ready for a real offer, make that offer honestly. Distinguish an exploratory discussion, a nonbinding expression of interest, and an actual paid agreement. Do not turn one category into another in the evidence log.
A useful experiment records the customer segment, the package, the price presented, the decision, and the reasons given. A handful of conversations can expose assumptions without producing a universal demand curve. Treat the result as evidence of a particular situation, then decide what to test next.
Complexity has a maintenance cost
Every special discount, grandfathered entitlement, and negotiated exception adds a state the product may need to preserve. Some exceptions are commercially worthwhile. They should still be visible as operating commitments rather than scattered conditions in the code.
Before introducing another plan, ask how support will explain it, how a customer will change between plans, and how the application will handle a failed renewal. What happens to data when an entitlement changes? Which actions remain available? Can someone export their work without first resolving an unrelated upgrade decision?
These questions connect pricing to web engineering’s state boundaries. A pricing change can affect permissions, scheduled jobs, customer communication, and historical records. It deserves the same care as another change to the product’s behavior.
A simple price is valuable only when the rules behind it remain understandable during change.
Keep the model revisable
Early pricing should be specific enough to test and documented enough to change responsibly. Record why a measure was chosen, which customer it serves, and what evidence would challenge the choice. Otherwise a provisional decision can become permanent because nobody remembers the original uncertainty.
Review product behavior alongside revenue. Are customers avoiding useful collaboration? Are they surprised by usage? Do upgrades correspond to a meaningful expansion in the job being done? Those observations can reveal a mismatch that a headline conversion number conceals.
The aim is not to remove every tension between value, cost, and willingness to pay. It is to understand those tensions well enough to design a coherent relationship. When pricing helps the right customer understand what they receive and how the commitment changes, it is doing product work long before the first invoice is generated.