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.
Source-backed example
Mozilla's Add-on Policies require AMO listings to disclose when payment is required to enable any add-on functionality.
Source-reported evidence
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.
Attributed to the cited source; GrowthDex has not independently verified it. Use this as context, not as a forecast, benchmark, or recommended target.
Evidence scope: claims and metrics are attributed to the linked source; GrowthDex has not independently replicated the reported result. Check the original context and validate fit before applying it. Read the evidence methodology.
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.
How to do it
- Choose one target segment and define the exact next action this tactic should prompt.
- Adapt the tactic to Marketplaces and Revenue, using evidence from Firefox Extension Workshop: Add-on Policies as context—not as a promised result.
- Record a baseline for: Qualified prospects who complete the intended paid action. Set a guardrail that would make you pause the test.
- Run a narrow pilot and choose a test window that fits the normal decision or use cycle; do not scale before you have observed the full cycle.
- Compare the signal with its baseline. Scale only if the intended action improves without crossing the guardrail; otherwise revise one variable or stop and record what you learned.
Compare a stack for your situation
Compare source-backed tactics against your product, stage, budget and channel strengths, then choose one experiment to test.
Explore the context
Did you launch this experiment?
Report a launch to help us understand which growth ideas founders put into practice.
Apply this with an operator
Connect activation, customer value, retention, and referral into one measurable loop.
SOURCE HUB
More tactics from Firefox Extension Workshop: Add-on Policies
Explore related GrowthDex examples and evidence connected to Firefox Extension Workshop: Add-on Policies.
Open Firefox Extension Workshop: Add-on Policies source hub