Why Browser Extensions Are Becoming Their Own Acquisition Category
Chrome extensions used to be a side project category β something a solo developer built over a weekend and forgot about. That's changed. AI-powered extensions, productivity tools, and SEO/marketing plugins now generate real recurring revenue, and buyers who previously only looked at SaaS or content sites are starting to treat browser extensions as a distinct asset class with its own economics.
The appeal is real: extensions ride on top of an existing distribution channel (the Chrome Web Store, Firefox Add-ons, Edge Add-ons), they're cheap to run, and a well-ranked extension can keep acquiring users organically with almost no paid marketing spend. The risk is just as real β this is a category where the thing you're buying can lose most of its value overnight if you mishandle the transfer or the underlying platform changes its rules. This guide walks through what to actually check before you commit capital.
What You're Actually Buying: Distribution, Not Just Code
With a SaaS product, you're mostly buying a codebase, a customer list, and a subscription mechanism. With a browser extension, the codebase is often the smallest part of the value. What you're really acquiring is:
- Store ranking and search visibility inside the Chrome Web Store (or equivalent), which took time and reviews to build and can't be rebuilt instantly if lost.
- An installed user base that already trusts the extension enough to have it running in their browser β a much higher bar than a website visit.
- Review history and rating, which acts like a trust signal the way backlinks do for a website.
- Permission grants, meaning users have already accepted whatever access the extension requests β changing that access later can trigger uninstalls.
This distinction matters because due diligence for an extension needs to weight store-side signals as heavily as financial statements β a healthy P&L attached to a declining install base is a business in decline, not a stable one.
The First Filter: Manifest V3 Compliance
Before you look at revenue at all, check whether the extension has migrated to Manifest V3 (MV3). Google deprecated Manifest V2 and has been progressively removing MV2 extensions from the Chrome Web Store and disabling them in Chrome itself. An extension still running on MV2 isn't just outdated β it's a business with a countdown clock on it.
In practice, MV2 holdouts trade at a meaningful discount (industry commentary puts it in the 10-20% range) because the buyer inherits the migration work and the risk that some background-script-dependent features simply can't be ported as-is. If a seller tells you "the migration is almost done," ask to see it merged and deployed, not promised.
The Metrics That Actually Move Valuation
Extensions get valued on a different scorecard than websites or SaaS tools. These are the numbers to pull before you go further:
| Metric | Why it matters | Signal to watch for |
|---|---|---|
| Weekly active users (WAU) | Closest proxy to real engagement β installs alone are vanity | Installs far above WAU suggests a churny or abandoned user base |
| Store rating and review count | Acts as a trust and ranking signal inside the store's algorithm | Below roughly 4.3 stars, or under ~100 reviews, weakens defensibility |
| Monthly churn (for subscription extensions) | Determines whether revenue is durable or one-time | Churn above ~5%/month should lower the multiple you're willing to pay |
| Revenue mix | Subscription, one-time purchase, or ad-based β each has different durability | Ad-based revenue is the most exposed to policy and market shifts |
| Permission footprint | Broad permissions (e.g. reading all site data) invite more platform scrutiny | Extensions with minimal, justified permissions are lower-risk assets |
None of these numbers should be taken on trust β ask for a read-only view into the Chrome Web Store developer dashboard before you go deep into negotiation. If a seller won't grant that, treat it as a data point in itself.
A Due Diligence Checklist Built for Extensions
- Financials: 12-24 months of actual revenue by source (subscription, one-time, ads), not projections. A revenue spike in the weeks before listing deserves a direct question.
- Codebase: request a code review or have a technical advisor check for unused permissions, hardcoded API keys, dependency on deprecated APIs, and whether the build is reproducible from source.
- Store standing: full review history, any past suspensions or policy strikes, and current MV3 status.
- Backend dependencies: does the extension rely on a third-party API whose pricing or terms could change? Who owns that account β the seller or a service they resell?
- Team dependency: is there a single developer whose departure would leave nobody able to ship updates or respond to a store policy flag?
- Legal: privacy policy accuracy versus actual data collection, and GDPR/CCPA posture if the extension processes personal data. (This is a starting checklist, not legal advice β loop in counsel for anything contractual.)
A seller who can produce clean answers on all six points within a few days is telling you something useful before you've spent anything on formal diligence.
How Extension Businesses Get Valued
Valuation approaches differ by monetization model, and buyers should treat any multiple as a negotiation starting point rather than a fixed formula:
| Monetization model | What typically drives the multiple | Durability |
|---|---|---|
| Subscription (SaaS-style) | Recurring revenue, low churn, expansion potential | Highest β predictable cash flow if churn stays low |
| Seat-based / team pricing | Account concentration and renewal rates | High, but watch customer concentration |
| One-time purchase | Install velocity and review sentiment | Lower β no guarantee of repeat revenue |
| Advertising-supported | Fill rate, eCPM trend, and WAU stability | Most exposed to platform and market shifts |
The Transfer Day Most Buyers Don't Plan For
This is where extension deals differ most from a typical website or SaaS acquisition, and it's the step first-time buyers most often underestimate:
- 1. Developer account transfer β ownership of the Chrome Web Store listing moves at the developer-account level, not just a code repository handoff. Confirm in writing exactly how this happens and test it before the public announcement.
- 2. API keys and backend infrastructure β if the extension calls a backend service, rotate credentials and confirm the new owner controls billing before old keys are revoked.
- 3. Domain and OAuth client IDs β many extensions authenticate through an OAuth client tied to a specific domain; moving domains without updating this can break login for every existing user.
- 4. Privacy policy and support inbox β these need to point to the new owner immediately, since store reviewers and users will use them to verify the change.
- 5. Timeline β budget at least a week for the transfer alone, separate from due diligence, and don't announce anything to users until both sides confirm the handoff is complete.
Get any one of these wrong and you can inherit an extension stripped of the ranking and trust equity you actually paid for.
Red Flags Specific to Extension Deals
- A ranking or install spike in the weeks before listing with no clear, verifiable explanation.
- Reluctance to grant read-only access to the Chrome Web Store dashboard or analytics before a signed letter of intent.
- Heavy reliance on a single traffic or distribution channel (for example, one influencer or one SEO ranking) for most new installs.
- Permissions that go well beyond what the extension's stated function requires β a sign the app could face future store policy action.
- No documented process for how updates get built, tested, and shipped, meaning the business depends entirely on one person's undocumented workflow.
Key Takeaways
- Weight store-side signals (ranking, reviews, MV3 status) as heavily as the P&L β a shrinking install base makes even strong current revenue fragile.
- Insist on read-only dashboard access before serious negotiation; a seller's unwillingness is itself useful information.
- Budget real time and a clear runbook for the account and API transfer β this is where deals quietly lose most of their value.
- Treat any revenue multiple as a starting point for negotiation, adjusted for churn, concentration, and platform dependency β not a number to accept at face value.
