build brief
Move from flat monthly plans to usage-based billing
Why this order
Meter design gates everything downstream: fences, invoicing, and the migration conversation are all expressions of what you choose to measure. New signups go first because they carry no grandfathering risk and generate the elasticity data the existing-base decision needs. The riskiest unknown retires first; each phase funds the next with evidence.
Suggested implementation order
- 01
Define the meter before touching plans
Pick the one or two usage dimensions that track value delivered, not effort consumed. Every downstream choice (price fences, invoicing, grandfathering mechanics) inherits this decision, which is why it goes first and gets validated against real usage data from your current accounts.
Done when: A named meter with 90 days of backfilled usage for your top 20 accounts.
- 02
Ship usage-based pricing to new signups only
New signups are the clean cohort: no migration risk, no grandfathering logic, and finance keeps forecastable revenue from the existing base while real elasticity data accumulates. Stripe metered subscriptions handle the billing mechanics without a custom invoicing layer.
Done when: New-signup plans live behind a flag, with usage visible on the customer dashboard.
- 03
Decide the existing-base story from evidence
After a full billing cycle of new-cohort data, the migration question stops being a debate. Model the top accounts against the meter, identify who wins and who loses, and only then design an opt-in path. The anti-goal holds until the data says otherwise.
Done when: A migration recommendation memo grounded in one cycle of real usage revenue.
Scope & non-goals
in scope
- Meter definition + backfill
- Stripe metered subscriptions
- New-signup plan flag
- Usage dashboard
deferred
- Existing-account migration
- Committed-use discounts
- Usage alerts + budgets
non-goals
- Repricing existing customers this quarter
- A custom invoicing engine
Sharpens after refine
This brief reasons from your input alone. When your coding agent runs
/ritual refine against the repo, it adds the two sections that need
your code:
- Codebase anchors — each phase pins to the real files it touches.
- Review gates — the read-this-first checks that block review, grounded in your architecture.
Refine also surfaces the constraints your architecture already imposes and raises readiness.