MAU pricing — billing by monthly active users — markets itself as startup-friendly: cheap while small, pay for what you use. The mechanics deserve a harder look: it is a meter on your success, and the bill it produces behaves very differently from a scoped license as your product grows. This guide examines the cost curve honestly, including when MAU is the right call.
1. How the meter behaves
The friendly case is real: at launch, with modest users, MAU pricing is genuinely affordable — that is its pitch and it is true. The behavior that matters arrives with success: every user your product wins raises the bill, every month, forever. A viral quarter lands as an SDK invoice. Growth — the thing the whole company is organized around — becomes the price driver of a line item in infrastructure.
| Scenario | MAU meter | Scoped license |
|---|---|---|
| Launch, small base | Low cost | Scoped to what ships |
| Steady growth | Bill grows with the curve | License holds |
| Viral quarter | A surprise for finance | No change |
| Adding a platform | Second meter + integration | Scoped when added |
| Year-two forecast | User-count forecasting | Roadmap forecasting |
2. The year-two math
The honest comparison is not quote versus quote but year-two total versus year-two total. Take your growth projection — the case you are building toward — and run it through both models: the metered bill at your projected MAU, against the scoped license with your platform plan. Then run the flat case for honesty. In the flat case the shapes converge; in the growth case — the case you intend — they diverge sharply, and the divergence compounds monthly.
3. What the license includes, either way
Price shape matters less than contents. Feature-by-feature, ask what the base carries: the AI production set, HDR and 4K, the platform family, deployment postures, and the support model. Missing rows become builds or add-ons, and they cost the same under either pricing shape — the metered model simply adds its growth tax on top. Get the included-feature list in writing from every vendor; it is the denominator of every price you are quoted.
4. When MAU is the right call
Genuinely: when the product’s future is genuinely small or genuinely uncertain — a market test, a proof of concept with a defined ceiling, a product where user growth is capped by design. The meter is fair when the thing being metered is bounded. The failure mode is choosing the meter while planning the growth — betting against your own roadmap because the launch price was friendly. Align the pricing shape with the trajectory you actually intend.
5. Why teams pick Meishe
| Advantage | What it means |
|---|---|
| Scoped, not metered. Platforms and deployment define the license | user growth is not a price driver. |
| The production set included. AI features, HDR, and 4K are in the toolkit, not in a tier above it. | |
| A family that prices as you grow into it. Web and desktop editions scope on when the roadmap asks. | |
| Named engineers, included. A dedicated project team and free upgrades through the cooperation period. | |
| A vendor that scopes with you. The quote conversation happens with people who read your requirements. |
One last note on negotiation posture: vendors read teams that arrive with year-two math as teams that will read the contract. The written curve, the tier questions, and the included-feature list change the conversation’s temperature — precision at evaluation buys precision at renewal, from every vendor.
One more note on the psychology of meters: teams under MAU pricing begin optimizing around the meter — gating features, gating users, timing launches — which is energy spent managing the vendor’s curve instead of the product’s. Scoped licensing removes the temptation along with the tax.
The year-two worksheet, both models, your curve, in writing — one afternoon of math that prices the next two years honestly.
One final thought on the negotiation window: the best time to discuss pricing shape is before signature, when alternatives are live and switching costs are zero; the worst is at renewal, when they are not. Teams that read the shape early negotiate from choice; teams that read it late negotiate from position — theirs.
The worksheet, both models, the curve: run it once at evaluation, and the meter never surprises anyone who signed it.
The quiet summary of everything above: requirements you can count, architectures you can verify, artifacts you can file, and a fortnight you can defend. That is the whole method — small enough to repeat, strong enough to trust, and yours to run against every SDK decision your product will ever face.
And one closing line on the meter’s quietest cost: it teaches teams to think small about their own product — every feature gated, every launch timed, every cohort measured against the invoice. Scoped licensing teaches the opposite lesson, and products learn the lesson their pricing teaches.
And one truly last line: the pricing model is the vendor’s theory of your product — metered says you will stay small, scoped says you are building. Sign the theory you believe.
And the last note on model hygiene: revisit the projection annually — the curve you priced against changes as the product finds its market, and a pricing decision kept current is a pricing decision that never surprises.
And one closing habit that prices itself: set a calendar reminder for the next projection review — the annual ten minutes that keeps the model matched to the market, and keeps the invoice boring.
FAQ
Is MAU pricing a trap?
It is a shape, well-suited to bounded products and costly for growing ones. The trap is only the mismatch — choosing a meter while planning the growth that feeds it.
How do we compare quotes across shapes?
Year-two totals on your projected curve, plus the included-feature list from each vendor in writing. The starting number is the least predictive figure in SDK economics.
Can we renegotiate when the meter grows?
At renewal, with switching costs at their peak — the meter’s leverage grows with your integration. The renegotiation window is worst exactly when you need it most.
What should we get in writing from any vendor?
Tier or scope boundaries, the included features, the support model with names, the upgrade policy, and the renewal position on your content.
Where do we start?
Send both vendors your projected curve and ask for year-two math. The model that answers comfortably is the model built for products like yours.