You built an app, but the pricing page is still blank. You may copy a competitor or add three plans. You may make everything free until “later.” None of those choices tells you what your first customer values.
Your first price is a test, not a permanent answer. Choose one result, one understandable billing unit, and one offer you can explain in a sentence. Then ask real people to make a real buying decision.
What are you really pricing?
You are not pricing the number of files, prompts, or hours it took to build the app. You are pricing access to a useful result.
A scheduling tool may save a tutor three message exchanges for every booking. A document tool may turn a one-hour review into a ten-minute check. Name that change before choosing a number.
Value sentence: This app helps [customer] get [result] without [current cost, delay, or risk].
If the result is unclear, the price will also feel arbitrary. Return to the first customer journey before building a pricing table.
Which unit should the customer pay for?
The billing unit is the thing that changes the bill. It may be one account, one team member, one completed job, or a measured amount of use.
Stripe's pricing guide calls this a value metric. A useful metric grows with customer value, is easy to understand, is hard to manipulate, and matches how the customer expects to budget.
| Billing unit | When it can fit | Main question |
|---|---|---|
| Flat monthly price | One customer gets similar value each month | Is the offer simple enough to explain? |
| Per person | More team members create more value | Will customers avoid inviting their team? |
| Per result | The app completes a clear job | Can both sides verify the result? |
| By usage | Customer value rises with real use | Can the customer predict the bill? |
Do not invent a unit because it is easy for your database to count. Choose one the customer can understand before reading a help page.
How do costs affect the first price?
Your costs create a floor, not the full price. List the cost that rises when one customer uses the product more:
- AI model calls
- Payment fees
- Email, storage, or other outside services
- Manual support or review time
Estimate a normal customer and a heavy customer. If heavy use costs more than the price, change the offer. Add a fair limit, choose a cheaper method, or combine a base price with measured use. Do not hide an unpredictable bill behind vague wording.
The guide AI API Costs: Set Limits Before the Bill Arrives shows how to measure the AI part per feature and customer result.
What should you ask potential customers?
“Would you pay $20?” produces weak evidence. People can say yes without giving anything up. Ask about past behavior and then present a real offer.
- Ask what they do now.
- Ask what the current method costs in time, money, missed work, or risk.
- Ask who controls the budget.
- Show the exact result and price.
- Ask for the next real step: a paid pilot, checkout, or written purchase approval.
An objection is useful data. Record whether the problem is weak, the result is unclear, the unit feels unfair, or the amount is too high. These require different changes.
How many plans should you start with?
Start with the fewest choices that match customers you actually know. For many early products, one paid offer and a clear limit are easier to learn from than three invented tiers.
Add another plan only when a real group needs a different result, limit, or buying process. Stripe's overview of SaaS pricing models recommends simple, clear pricing and a model tied to the value customers receive.
A free tier is also a plan. It needs a purpose, a support cost, and a path to a paid result. Do not add it only because other products have one.
What should the first offer include?
- One sentence that names the customer and result
- One price and billing period or billing event
- The usage or account limit in plain language
- What happens when the limit is reached
- How cancellation, refunds, and data access work
- A way to contact you before buying
Show the full amount before payment. If usage can change the bill, show how customers can see their current use.
What should you ask your coding AI?
Copy this request: Do not build billing yet. Review this customer result, expected usage, and variable costs. Compare a flat price, per-result price, and base-plus-usage price. Explain what the customer pays for and how the app measures it. Name one way each option could feel unfair and the data needed to test it. Do not invent customer demand.
The AI can compare mechanics. It cannot tell you what a real customer values without evidence from that customer.
How do you know the first price is ready?
| Check | Pass condition |
|---|---|
| Result | The customer can repeat the promised outcome |
| Unit | The customer understands what changes the bill |
| Cost | Normal and heavy use have been estimated |
| Decision | At least one real buyer accepted or clearly refused the offer |
| Learning | You recorded why the buyer decided |
Change one part at a time. If you change the customer, result, unit, and amount together, you will not know what improved the decision.
What should you read next?
- Your App's First Customer Journey: What to Build First
- Prevent Duplicate Charges in Your First Payment Flow
- AI API Costs: Set Limits Before the Bill Arrives
Compare the hosting cost behind your offer on JustDeploy Pricing.