Firefox Add-ons paid function disclosed on listing
State on the listing when payment unlocks any feature, so the install does not feel like a bait-and-switch after the review queue clears.
Why this can grow a startup
Extension monetization often fails through surprise rather than price. Mozilla removes the ambiguity here by requiring listings to disclose when payment is needed to enable any functionality. That is a growth advantage if the team leans into it. The buyer can qualify themselves before install, the support queue gets fewer angry "why is this paywalled" threads, and the review surface feels more honest. Clear commercial boundaries beat a clever install spike that turns into churn and one-star reviews.
Company example
Mozilla's Add-on Policies require AMO listings to disclose when payment is required to enable any add-on functionality.
Source and metric
Source: Firefox Extension Workshop: Add-on Policies · Browse Firefox Extension Workshop: Add-on Policies tactics
Mozilla explicitly requires payment disclosure on the AMO listing whenever any functionality needs payment.
When to use it
Use this when Marketplaces, Revenue, Brand is relevant to browser extensions, firefox add-ons, pricing clarity and you can run a bounded test with a free budget.
When not to use it
Do not use it as a substitute for customer evidence, a clear owner, or a measurable stop condition. Local platform rules and market behavior still need checking.
Founder checklist
- Read Firefox Extension Workshop: Add-on Policies and identify what is directly supported.
- Choose one channel context: Marketplaces, Revenue, Brand.
- Define the test around Mozilla explicitly requires payment disclosure on the AMO listing whenever any functionality needs payment..
- Set an owner, evidence window, and stop condition before launch.
Explore the context
Apply this with an operator
Connect activation, customer value, retention, and referral into one measurable loop.