Back to GrowthDex
Growth idea action plan

Firefox add-on ID in manifest before session-dependent APIs

Set the Firefox add-on ID in `manifest.json` early if the extension depends on stable identity, because temporary IDs reset across sessions and break more than most teams expect.

rare tacticfree budget

Why this can grow a startup

A lot of extension teams discover the add-on ID too late, after sync, redirect, or native-messaging behavior starts acting haunted in development. Mozilla's guidance is useful because it turns the ID into an early architecture choice instead of a release footnote. When the ID is set from the start, the same extension identity can survive development, signing, and production updates. That makes debugging cleaner and keeps session-dependent flows from changing shape every time Firefox restarts.

Company example

Firefox Extension Workshop recommends defining an extension ID in `manifest.json` when development begins, requires a Manifest V3 extension ID before submission to AMO, and notes that temporary IDs change when Firefox restarts if no ID is defined.

Source and metric

Source: Firefox Extension Workshop: Extensions and the add-on ID

Manifest V3 add-ons must define an ID before AMO submission, and temporary Firefox IDs change after restart when no ID is set.

ProductDeveloper ExperienceRetentionbrowser extensionsfirefox add-onsmanifest architectureidentity stability
GrowthDex operator note

When to use it

Use this when Product, Developer Experience, Retention is relevant to browser extensions, firefox add-ons, manifest architecture 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

  1. Read Firefox Extension Workshop: Extensions and the add-on ID and identify what is directly supported.
  2. Choose one channel context: Product, Developer Experience, Retention.
  3. Define the test around Manifest V3 add-ons must define an ID before AMO submission, and temporary Firefox IDs change after restart when no ID is set..
  4. Set an owner, evidence window, and stop condition before launch.

Explore the context

Referral and Retention GrowthProductDeveloper ExperienceRetention

Related tactics

Canny voter export for beta recruitment

Recruit beta users from the people who already voted on the exact request instead of rebuilding the list from CRM notes after the feature is nearly done.

rareProduct, Lifecycle, Retention

Firefox approved-version rollback within 24 hours

Keep the previous approved AMO version rollback-ready, because Mozilla can push users back to it and Firefox checks for extension updates within roughly 24 hours by default.

rareRetention, Operations, Brand

Chrome Web Store permission-change copy before forced re-accept

If an update adds permissions, rewrite the listing, changelog, and support copy before submission so users understand the new ask when Chrome prompts them to accept or disable the extension.

rareMarketplaces, Copywriting, Retention

Double down on the feature users love

Find the one feature that actually causes upgrades, then put disproportionate product effort behind making that feature better.

rareProduct, Retention, Conversion

Superhuman half-love half-blocker roadmap

Split the product roadmap between what current lovers already value and what blocks adjacent users who value the same core benefit.

rareProduct, Retention, Activation

Task-based model routing for AI speed

Route lightweight jobs to smaller fast models and reserve larger models for harder reasoning so the product feels quick without giving up depth where it matters.

rareProduct, Activation, Retention
Advisory bridge

Apply this with an operator

Connect activation, customer value, retention, and referral into one measurable loop.

Work with Ian