Pricing · Decision guide
Compare what light, typical and heavy customers would pay under a flat fee, a usage price and a hybrid, what that means for monthly revenue and contribution with the same customers, and what each model takes to run.
Every path against today — select one to see exactly what changes
These are bill comparisons with the same customers under every plan. They show who pays more or less and where plans cross, not whether customers will stay, convert or use more. Usage and hybrid pricing need reliable metering first; that work, not the formula, is usually the real cost.
Who this is for Software and service companies with recurring customers, deciding how the bill should be calculated.
Optional. Answers decide which paths meet your hard constraints; "not sure" keeps a requirement unresolved instead of guessing.
Your current approach, the alternatives and a smaller reversible pilot — all with the same inputs and horizon.
Current approach
Every customer pays the same monthly fee, whatever their usage.
Main uncertainty: Whether heavy users are profitable at the flat fee — check contribution at the heavy level.
Alternative
Customers pay a price per billable unit, with no base fee.
Main uncertainty: Customer response to a usage bill — the model holds usage constant.
Alternative
Customers pay a base fee that includes an allowance, and a unit price for usage above it.
Main uncertainty: Where to set the allowance — see the break-even table and the usage shares.
Smaller reversible pilot
Existing customers stay on the flat fee. New customers are quoted the hybrid plan for twelve weeks, with usage tracked manually.
Main uncertainty: Revenue shown is the current plan: the pilot changes only new customers' prices, and its effect is what the pilot measures.
Person-hours are everyone's effort added up, not calendar time. Valued staff time is hours × the value of an hour: an economic cost, not a bill.
| Path | Setup effort | Ongoing effort per week | Setup cash | Ongoing cash per month | Cash over the horizon | Incl. valued staff time | Weeks to go live |
|---|---|---|---|---|---|---|---|
| Flat fee | 0 h | 1 h | $0 | $0 | $0 | $3,710 | now |
| Usage-based | 74 h | 2 h | $0 | $50 | $550 | $14,550 | 7 |
| Hybrid: base fee plus usage above an allowance | 72 h | 1.5 h | $0 | $50 | $550 | $12,205 | 7 |
| Pilot: quote the new model to new customers only | 11 h | 1 h | $0 | $0 | $0 | $5,740 | 14 |
Horizon: 12 months. Change the assumptions, compare any path with your current approach, combine steps and export a plan with the interactive tool (JavaScript).
Finance · every week from week 1 · 1 h / week
Gains: Simplest to sell and bill; Predictable for customers and for you
Sacrifices: Light users subsidise heavy users; Revenue does not follow cost when usage grows
Must be true: Variable cost at heavy usage stays well below the fee
Engineering · weeks 1–4 · 40 h
Engineering · weeks 5–6 · 16 h
Founder · weeks 6–7 · 6 h
Engineering · weeks 5–6 · 12 h
Finance · every week from week 1 · 2 h / week
Vendor or partner (cash only) · every week from week 5 · $50 / month
Support · every week from week 7 · 2 h / week
Gains: Price follows value and cost; Low entry price for small customers
Sacrifices: Less predictable revenue and bills; Customers may ration usage; Metering and billing work
Must be true: Customers can understand and check their usage; Metering is accurate enough to bill from
Engineering · weeks 1–4 · 40 h
Engineering · weeks 5–6 · 16 h
Founder · weeks 6–7 · 6 h
Engineering · weeks 5–6 · 10 h
Finance · every week from week 1 · 1.5 h / week
Vendor or partner (cash only) · every week from week 5 · $50 / month
Support · every week from week 7 · 1.5 h / week
Gains: Predictable base revenue; Heavy usage is paid for
Sacrifices: Two numbers to explain; Metering and billing work
Must be true: Most customers stay inside or near the allowance; Overage is visible before the invoice arrives
Finance · every week from week 1 · 1 h / week
Founder · weeks 1–1 · 3 h
Finance · every week from week 2 · 1.5 h / week
Founder · weeks 2–7 · 6 h
Founder · weeks 14–14 · 2 h
Gains: No change for existing customers; Real acceptance data; Little engineering work
Sacrifices: Manual tracking effort; Small sample; Two price lists for a while
Must be true: Enough new customers in twelve weeks to learn something
Before comparing prices, define the billable unit — whatever you meter: an API call, an active seat in a month, an order processed, a gigabyte stored. Every usage input on this page is per customer per month in that unit.
The model splits customers into three usage levels (light, typical, heavy) with shares you set. For each plan it calculates the bill at each level, the monthly revenue across your customers, the variable cost of serving that usage, and the contribution (revenue minus variable cost). Implementation work is counted separately, as hours and cash.
What the model holds constant. The same customers, with the same usage, under every plan. It does not predict churn, conversion, expansion or changes in usage caused by the new price. Those are exactly the things the pilot tests.
The break-even table shows the usage level at which two plans produce the same bill — a fact about the formulas, not about customer preference.
If you do not know your variable cost per unit or how usage is distributed across customers, measure that first — the comparison is only as good as those two inputs. If a few customers make up most of your revenue, talk to them individually before any model change.
Specific, dated practices — not whole-company models. Paths marked as an adaptation are WeCaseStudy's adaptation for your context, not a claim that the company used this exact workflow.
Calculations: formula family pricing, version 1. Decision version 1. How the numbers are made
