Designing a mobile game economy: the muffins case
How I designed Grimoire Culinaire's internal economy: 80 muffins/month, rewarded ads, free trial, and pricing mistakes.
Why an internal currency exists at all
Every AI action in Grimoire Culinaire has a real server-side cost. An internal currency makes that cost visible without exposing the user to unreadable cent-level pricing.
Muffins are not only a monetization mechanic. They make the cost understandable, controllable and integrable into the product design itself.
How the monthly allowance was calibrated
The free plan has to be generous enough to enable real use, but not enough to replace the paid plan. The free tier eventually landed at 80 muffins/month, with 500 for Plus and 1500 for Pro.
In V0.4, 150 muffins/month on free made upgrades almost useless. The rebalance was driven both by product behavior and by cost structure.
The most important rule: reserve before debit
When an AI action starts, muffins are reserved immediately. If the call fails or returns something unusable, everything gets rolled back.
That rule forced a precise architecture: immutable ledger, reserved/debited states, failure handling, provider fallback without doubling costs.
Rewarded ads and referrals
Rewarded ads add a usage path for free users: 5 muffins per view, up to 3 times per day. Referrals add a growth layer without blowing up the economy.
This cannot be bolted on late. You need quotas, ceilings and clear attribution logic from the beginning.
The real risk: the AI bill
Provider costs are not stable. Models change, prices move, APIs can be deprecated.
Any AI-dependent economy has to model the scenario where costs double. Muffins and provider fallback do not remove the risk; they make it manageable.