You send a proposal on Tuesday. On Friday, you add migration help, soften a limit and change the billing cadence. Two buyers object for different reasons. A month later, the notes say only “pricing felt wrong.” Nothing in that record can guide the next quote.
“First 100” is a frame, not proof
Treat the first hundred customers as a planning horizon, not a point at which your price is proven. A self-serve utility and an assisted workflow can learn at different speeds because the offers, buyers and service boundaries differ. Count accounts if it helps operations; do not use the count as a licence to stop examining the offer.
Stripe documents flat-rate, per-seat, tiered and usage-based models, but those mechanisms do not tell you which commercial model will work for your product. That decision still depends on buyer language, package scope and cost evidence.
Give every offer a version
Before another quote leaves your inbox, freeze the current offer in a pricing hypothesis log:
| Field | Record | What it protects |
|---|---|---|
| Version and date | A stable label and the date first shown | Prevents a later offer from rewriting history |
| Buyer job | The work the buyer is trying to complete | Keeps unlike cohorts apart |
| Package | Outcome, limits, cadence and exclusions | Stops scope changes from looking like price reactions |
| Billing unit | Account, seat, usage unit or another named basis | Exposes what actually changes the bill |
| Service boundary | Setup, migration and manual exceptions included or excluded | Makes founder labour visible without inventing a margin |
| Buyer evidence | Question, objection or acceptance condition, kept separate from interpretation | Preserves what happened instead of a vague label |
| Revision trigger | The evidence that would justify the next change | Prevents nervous mid-cohort editing |
If formal proposals matter to your process, preserve the quote state as well as its terms. Under Stripe’s quote lifecycle, an open quote is finalized and ordinary edits are limited to its expiration date. Changing the offer uses the separate revision or duplication path: an open quote can be revised, and a draft, open or accepted quote can be duplicated into a new draft.
Accepted Stripe quotes can generate an invoice, subscription or subscription schedule, depending on their terms. Access also matters: finalizing, downloading or accepting live quotes for one-time invoices requires Invoicing Plus, as documented in Stripe’s quote guidance. Those capabilities preserve formal terms; they do not establish whether a buyer will accept the offer.
Illustrative pricing log — fictional, not PBT or customer data
The three entries below contain no observed prices, customers, revenue or results. They show how to keep the offer and the interpretation separate.
| Buyer situation | Offer hypothesis | Evidence the founder would collect | Possible next reading |
|---|---|---|---|
| Owner-operator, self-serve setup | One recurring package covers the standard job | Questions cluster around getting the first file accepted | Inspect setup clarity before assuming the amount is the objection |
| Agency, mixed client files | The package includes assisted migration | Each migration introduces different cleanup work | Bound the input or separate migration from recurring access |
| Team with approvals | A separate package includes roles and approval history | Questions focus on control, rollout and responsibility | Test whether the package resolves operational risk before changing price |
“Too expensive” and “too expensive for one report a quarter” are not the same record. Keep the buyer’s sentence in one field and your interpretation in another. You may still be wrong, but you will know what you are revising.
Revise when the offer becomes hard to explain
- Language mismatch: the intended buyer cannot connect the package to a current job, cost or risk.
- Scope leakage: accepted work repeatedly requires unnamed setup or manual handling.
- Package confusion: comparable buyers cannot tell which version covers the ordinary workflow.
- Cohort drift: the offer attracts work the product was not meant to support.
- Billing-unit distortion: the unresolved question is what should change the bill, not the amount itself.
These are possible responses, not market laws. The right move might be a narrower promise, a separate service, a different package or a deliberate refusal. It is not automatically a discount or increase.
Ignore polished tier names, annual-discount choreography and a competitor-price spreadsheet if you cannot reconstruct your own last offer. Do not build a complicated billing configuration to compensate for a package you still change in conversation. Someone else’s early price range cannot tell you what your own package includes.
Freeze the next offer before it leaves
Write four lines in the pricing log: the comparable cohort, the unchanged package boundary, the one proposed change and the evidence you will preserve. If the unresolved question is the billing unit, leave the amount alone and work through the fictional file journal and reconstructed invoice subtotal, including the duplicate, reversal and cap rules.
Next move: freeze today’s version. Change one commercial hypothesis in the next comparable offer, not three variables halfway through the conversation.
Sources behind the pricing assumptions
- Stripe pricing models, documentation checked 2026-09-14. Documents Stripe model types; it does not identify a winning price or model.
- Stripe Quotes, documentation checked 2026-09-14. Documents quote states and what acceptance creates; it does not prove a sales outcome.
- Stripe quote revision and duplication, documentation checked 2026-09-14. Describes the open-quote revision path and Invoicing Plus requirement for live one-time invoice quote actions. Check current account access before relying on these capabilities.