Product6 min read
Price changes without surprises
Raising prices is not the hard part. Knowing exactly who pays more, by how much, before anyone gets an invoice is. Here is how versioned plans make that routine.
Most companies change prices far less often than they should, and the reason is not courage. It is visibility. Nobody can say with confidence which customers will pay more, by how much, and when.
Plans are data, and data has versions
In Tessera a plan is a document: a base fee, a list of meters and the tiers on each one. Every edit creates a new version. Customers stay on the version they signed up for until you decide otherwise.
await tessera.plans.update("growth", {
meters: [{ meter: "api.requests", tiers: [[1e6, 5], [1e7, 4.5], [Infinity, 3.5]], per: 1000 }],
});
// => { id: "plan_growth_v4", previous: "plan_growth_v3", migrated: 0 }
Nothing changes for existing customers yet. That is the point.
Preview before you migrate
The preview runs last period's real usage through the new version and compares every invoice line.
| Change | Customers | Median change | Largest change |
|---|---|---|---|
| Pays less | 118 | -4.1% | -11.0% |
| Pays more | 294 | +6.8% | +21.3% |
| No change | 1,006 | 0% | 0% |
Sort by largest change and you have a call list for your account team before a single email goes out.
The preview turns a pricing debate into a spreadsheet everyone can read.
A migration plan that works
- Move new signups to the new version on day one.
- Give existing customers notice with their own projected invoice attached.
- Migrate on each customer's renewal date, not on one big day.
- Keep the old version available for contracts that say so.
What to watch afterwards
Track expansion and churn by plan version for two full cycles. If churn on the new version stays flat while revenue per customer rises, you priced it right. If not, the old version is still there, and moving back is one call.