Where should a new SaaS founder start with pricing?
Start with the offer: who receives which result, under what conditions, and for how long. A price attached to an unclear product is difficult to evaluate. A customer needs to know whether they are buying access to software, a completed task, a team workspace, or a service that includes help from the founder. Those offers can have very different costs and expectations.
Use your audience research to identify the current alternative and the buyer’s decision process. Competitor prices can provide context after you verify the plan, billing period, and included work. They do not reveal that competitor’s costs or establish what your particular customer will accept. Treat your first offer as a hypothesis to investigate.
Which pricing unit fits the customer’s work?
Choose a unit the buyer can understand and that you can measure reliably. Stripe’s recurring-pricing documentation distinguishes flat-rate, per-seat, tiered, and usage-based models. Those are implementation patterns, not a recommendation that a new app should copy the most complicated model. A simple offer may be easier to explain and support while you learn.
Ask how value and cost change together. Charging per user may suit a collaboration workflow, while a report generator may incur substantial costs from one heavy account. If you use credits, explain what consumes them, including retries and failed attempts. A billing unit that surprises the customer can undermine an otherwise useful product.
| Possible unit | Customer question | Founder question |
|---|---|---|
| One workspace per month | Which people and workflows does it include? | Can a heavy workspace make the offer unsustainable? |
| One seat per month | Who counts as a billable user? | Does a seat reflect the cost and value of collaboration? |
| One completed report | What counts as completed, including retries? | Can successful results be measured without duplicate charges? |
| A fixed pilot | What is delivered and what happens when it ends? | Can the agreed scope be delivered with the available support? |
How can you check whether a plan covers its delivery costs?
List the costs that change with usage: model or API requests, processing, storage, delivery, payment expenses, and support effort. Check actual supplier terms and bills before using them in a real plan. Keep fixed overhead and acquisition work visible as well. An allowance that seems generous at average usage may become expensive when a small group uses it heavily.
Consider an entirely fictional report app charging $20 per month for up to 100 completed reports. Suppose each processing attempt costs $0.03, storage and delivery cost $2 per account, payment expense is $1, and allocated support is $5. The invented figures below compare 100 attempts with 500 attempts caused by heavier work or retries. They are arithmetic examples, not vendor rates or a recommended price.
| Processing attempts | Processing cost | Other listed costs | Total listed costs | $20 less listed costs |
|---|---|---|---|---|
| 100 | $3 | $8 | $11 | $9 |
| 500 | $15 | $8 | $23 | −$3 |
What does that cost calculation leave out?
The remaining amount in the example is not profit. It excludes fixed overhead, acquisition, taxes, refunds, and other costs not listed. The support allocation is also an assumption until you observe the time the work takes. Write the exclusions beside the calculation so a simple worksheet does not become a misleading business forecast.
Check how limits interact with the product. A plan capped at completed reports may still allow expensive failed attempts. You may need better reliability, reasonable processing limits, a clearer allowance, or a different offer. Explain the resulting customer-facing limits accurately. Avoid hiding a fragile cost model behind an unlimited promise you cannot sustain.
Should you begin with a free plan, a trial, or a paid pilot?
Choose the option that matches the question you need to answer and the support you can provide. A limited beta can help test a workflow. A trial can let a suitable person evaluate a working product. A paid pilot can make sense when a buyer wants a defined result and needs help introducing the product. Spell out the duration, deliverables, included support, and what happens afterward.
Free access does not establish paid demand, and a heavily assisted pilot does not establish that self-service onboarding works. Keep those observations separate. Our beta-testing guide covers a testing commitment, while the founder-led sales guide covers the discussion around a concrete commercial next step.
How do you learn whether someone will pay?
Present a real, understandable offer to a relevant decision-maker once they can evaluate the workflow. Explain the price, billing period, allowance, access conditions, and current limits. Ask what they would need to decide. Record whether they requested clarification, declined, agreed to a next step, or actually purchased. A hypothetical positive answer belongs in the notes without being counted as a sale.
When traffic is low, a conversation about one clear offer can be more informative than splitting a handful of visits across several price variations. You can revise the offer between documented rounds, while recognizing that different buyers and circumstances prevent a clean causal comparison. Record the offer version so an older quote and a newer public page do not silently conflict.
What should you do when someone says the price is too high?
Explore the decision without arguing away the objection. The person may lack budget, misunderstand the result, need a missing capability, or prefer their existing process. A discount addresses only some of those situations. Ask which part of the offer makes it unsuitable and what alternative they are considering; avoid translating every objection into a request for a cheaper tier.
If you offer an introductory arrangement, state its duration and renewal conditions. Do not promise permanent terms casually or use an invented deadline to force a decision. The pricing-page guide explains how to make units, allowances, and the real commitment visible. The feedback decision log helps separate an explanation problem from a product gap.
Build a pricing record you can revisit
Keep the audience, offer version, unit, price, billing period, limits, known cost assumptions, and actual buyer response together. Add the reason for the next revision and what will stay unchanged for existing customers under their agreed terms. Review usage as well as conversion, because a plan can win customers and still require a better delivery model.
Use the worksheet to write down the assumptions before collecting responses. When you update the offer, align the product, checkout, website, and public profiles. A prepared directory profile should link to the current facts rather than an old introductory claim. Clear pricing makes the next customer conversation easier to assess.