# The extension page should survive the update, not just the install > Why partial rollouts, honest permission updates, signed package uploads, stable Firefox IDs, visible rejection fallbacks, and rollback-ready approved versions make extension growth less fragile after day one. - Canonical HTML: https://growth.iangoh.com/blog/the-extension-page-should-survive-the-update-not-just-the-install/ - Published: 2026-06-07 - Updated: 2026-06-07T05:06:41.503Z - Categories: brand trust, retention, SEO - Niches: SaaS, AI products, developer tools, consumer apps, browser extensions ## On this page - Roll out to part of the base before you ask the whole base to trust you again - Permission changes need product copy, not only code review - The update path itself has to look defensible - Firefox makes version identity and fallback visible earlier than most teams expect - The old approved version is part of the growth system ## Start with these related tactics - [Chrome Web Store partial rollout after 10,000 active users](/growth-ideas/chrome-web-store-partial-rollout-after-10000-active-users/): Use Chrome's percentage rollout only after the extension has real scale, then increase the rollout without another review while you watch for breakage. - [Chrome Web Store permission-change copy before forced re-accept](/growth-ideas/chrome-web-store-permission-change-copy-before-forced-reaccept/): 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. - [Chrome Web Store Verified CRX uploads before scale](/growth-ideas/chrome-web-store-verified-crx-uploads-before-scale/): Opt into Verified CRX uploads before the extension becomes business-critical so every package update has to be signed with your own key. A lot of extension teams spend all their care on the install moment. That is understandable. The listing, the screenshots, the review count, and the permission prompt all sit right there in front of the buyer. But the trust test usually keeps going after the install. The next update can widen permissions, break sync, fail review, or force a rushed rollback. If that system is loose, the page that looked convincing on day one starts feeling unreliable on day thirty. The extension page should survive the update, not just the install. ## Roll out to part of the base before you ask the whole base to trust you again [Chrome Web Store partial rollout after 10,000 active users](/growth-ideas/chrome-web-store-partial-rollout-after-10000-active-users/) is the cleanest post-install growth move in the batch. Once an extension has real usage, Chrome lets the team widen a release in stages instead of betting the whole installed base on one push. That belongs next to [Chrome Web Store parallel beta channel before wide push](/growth-ideas/chrome-web-store-parallel-beta-channel-before-wide-push/). One tactic gives you a separate lane. The other gives you a safer ramp. The operational lesson is simple. Do not let the main listing become the first place you learn that a release hurts real users. ## Permission changes need product copy, not only code review [Chrome Web Store permission-change copy before forced re-accept](/growth-ideas/chrome-web-store-permission-change-copy-before-forced-reaccept/) is the most human tactic here. Chrome warns that users must accept added permissions or disable the extension. That means the real job is not only shipping the new capability. The real job is explaining why the extension now needs that extra reach before the prompt lands. I would read that beside [Chrome Web Store single-purpose and permission justification](/growth-ideas/chrome-web-store-single-purpose-and-permission-justification/) and [Firefox Add-ons privacy policy in listing details](/growth-ideas/firefox-add-ons-privacy-policy-in-listing-details/). Permission trust is cumulative. Every update either strengthens the story or makes the old story look less true. ## The update path itself has to look defensible [Chrome Web Store Verified CRX uploads before scale](/growth-ideas/chrome-web-store-verified-crx-uploads-before-scale/) matters because a maintained extension is not only judged by features. It is judged by whether the builder seems capable of protecting the thing after it is installed. Signed package uploads are backend plumbing, but they answer a plain buyer question: could somebody hijack the update path and ship malware under this name? That sounds technical, but the trust effect is public. It is in the same family as [GitHub release asset verification in install docs](/growth-ideas/github-release-asset-verification-in-install-docs/). When the distribution channel looks serious, the product feels more serious too. ## Firefox makes version identity and fallback visible earlier than most teams expect [Firefox add-on ID in manifest before session-dependent APIs](/growth-ideas/firefox-add-on-id-in-manifest-before-session-dependent-apis/) looks like a developer-experience detail until you have to debug a login, sync, or native-messaging path that keeps changing shape. Set the ID early and the product stays legible across testing, signing, and later updates. Then pair it with [Firefox review rejection falls back to the last approved version](/growth-ideas/firefox-review-rejection-falls-back-to-last-approved-version/). Mozilla is unusually blunt here. If the new version is rejected, buyers either see the last approved version or they see nothing at all because the listing can disappear from AMO search and direct links. That turns version hygiene into a discovery problem, not just a QA problem. ## The old approved version is part of the growth system [Firefox approved-version rollback within 24 hours](/growth-ideas/firefox-approved-version-rollback-within-24-hours/) is my favorite reminder in the batch. The previous approved version is not dead history. It is a live recovery asset. Mozilla can push users back to it, and Firefox checks for extension updates within roughly a day by default. That belongs with [GitHub release stays pre-release until the path is safe](/growth-ideas/github-release-stays-pre-release-until-the-path-is-safe/) and [the Chrome Web Store page should survive the release channel](/blog/the-chrome-web-store-page-should-survive-the-release-channel/). The product does not become more trustworthy because the team hopes nothing breaks. It becomes more trustworthy because recovery is already designed into the release path. This cluster is strongest for browser extensions, AI copilots, developer tools, SaaS add-ons, and consumer utilities that keep asking for trust after install through updates, permissions, and marketplace availability. If you want help tightening extension release trust, update paths, and crawlable product surfaces, the advisory CTA is here: [work with Ian Goh](https://iangoh.com/advisory). ## Related GrowthDex tactics - [Chrome Web Store partial rollout after 10,000 active users](/growth-ideas/chrome-web-store-partial-rollout-after-10000-active-users/) - Marketplaces, Retention, Operations - [Chrome Web Store permission-change copy before forced re-accept](/growth-ideas/chrome-web-store-permission-change-copy-before-forced-reaccept/) - Marketplaces, Copywriting, Retention - [Chrome Web Store Verified CRX uploads before scale](/growth-ideas/chrome-web-store-verified-crx-uploads-before-scale/) - Marketplaces, Security, Brand - [Firefox add-on ID in manifest before session-dependent APIs](/growth-ideas/firefox-add-on-id-in-manifest-before-session-dependent-apis/) - Product, Developer Experience, Retention - [Firefox review rejection falls back to the last approved version](/growth-ideas/firefox-review-rejection-falls-back-to-last-approved-version/) - Marketplaces, SEO, Brand - [Firefox approved-version rollback within 24 hours](/growth-ideas/firefox-approved-version-rollback-within-24-hours/) - Retention, Operations, Brand ## Essay chronology - [Newer essay: The marketplace starts when the founder knocks](/blog/the-marketplace-starts-when-the-founder-knocks/) - marketplaces, founder-led growth, trust - [Older essay: The marketplace gets faster when the seller is live](/blog/the-marketplace-gets-faster-when-the-seller-is-live/) - marketplaces, live commerce, community-led growth ## Keep reading - [The Chrome Web Store page should survive the release channel](/blog/the-chrome-web-store-page-should-survive-the-release-channel/) - marketplaces, SEO, brand trust - [The Safari extension page should finish the setup before the install](/blog/the-safari-extension-page-should-finish-the-setup-before-the-install/) - marketplaces, SEO, brand trust - [The Firefox Add-ons page should remove the surprise before install](/blog/the-firefox-add-ons-page-should-remove-the-surprise-before-install/) - marketplaces, SEO, brand trust ## Continue through the blog - [SaaS](/blog/#path-saas) - 3 essays in this path - [AI products](/blog/#path-ai-products) - 3 essays in this path - [developer tools](/blog/#path-developer-tools) - 3 essays in this path ## Sources - [Chrome for Developers: Update your Chrome Web Store item](https://developer.chrome.com/docs/webstore/update) · [GrowthDex source hub](/sources/chrome-for-developers-update-your-chrome-web-store-item-developer-chrome/) - [Firefox Extension Workshop: Extensions and the add-on ID](https://extensionworkshop.com/documentation/develop/extensions-and-the-add-on-id/) · [GrowthDex source hub](/sources/firefox-extension-workshop-extensions-and-the-add-on-id-extensionworksho/) - [Firefox Extension Workshop: What does review rejection mean to users?](https://extensionworkshop.com/documentation/publish/what-does-review-rejection-mean-to-users/) · [GrowthDex source hub](/sources/firefox-extension-workshop-what-does-review-rejection-mean-to-users-exte/) - [Firefox Extension Workshop: Version Rollback](https://extensionworkshop.com/documentation/publish/version-rollback/) · [GrowthDex source hub](/sources/firefox-extension-workshop-version-rollback-extensionworkshop-com/) ## Editing notes - Kept the essay on one claim: extension trust is tested again at update time, not only at install time. - Used concrete mechanics like rollout percentages, permission re-accept prompts, signed CRX uploads, manifest IDs, AMO fallback behavior, and rollback timing instead of generic release language. - Linked the batch to existing Chrome, Firefox, GitHub, and prior browser-extension essays so the piece reads like one operating system for update trust. - Cut any inflated security theater and closed on the product categories where post-install trust actually changes growth. ## Advisory If you want help turning this into a growth system, Ian Goh offers advisory at https://iangoh.com/advisory.