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
No source used for this note establishes a customer count at which an early price becomes valid. 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.
Billing software can represent flat-rate, per-seat, tiered and usage-based models. Stripe documents those mechanisms, but its documentation does 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, Stripe Quotes can be revised and later converted into an invoice or subscription. That is a documented Stripe capability, not evidence that quotes improve negotiation or suit every early sale.
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. And do not borrow a monetary range from somebody else’s first hundred customers; no such range is supported here.
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 run the value-metric invoice test.
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, observed 2026-07-28. Documents Stripe model types; it does not identify a winning price or model.
- Stripe Quotes, observed 2026-07-28. Documents quote behaviour in Stripe; it does not prove a sales outcome. Check the current Stripe pages before configuring billing or quotes.