Match the model to the product
Start with the extension’s main use and its existing constraints. For each model, consider what would change for users: access to features, data use, permissions and support.
Subscription or paid features
Suitable when ongoing or premium utility is clear, access controls are maintainable and the payment experience can be supported.
Affiliate, search or licensing
Requires careful partner selection, contract review, transparent behavior and alignment with browser-store and user expectations.
Advertising or sponsorship
Needs visible disclosure, appropriate placement, privacy controls and a user experience that does not undermine the product.
Compare models by the decision still open
| Model | Product and user question | Implementation and ownership to clarify |
|---|---|---|
| Subscription or paid features | Which continuing or premium benefit would someone pay for, and what must stay available to existing users? | Access checks, billing and support owners; use the paid-access decisions below for expiry and failure behavior. |
| Affiliate or search partnership | Which user action and direct benefit would the proposal serve? What would change in the extension’s main task? | Partner eligibility and terms, proposed behavior and disclosures need review before an integration is included. |
| Advertising or sponsorship | Where would a placement appear, and how would it affect the task users installed the extension to perform? | Placement, information shown, data handling and responsibility for later creative or vendor changes. |
| Licensing | Who would use the licensed product or component, and which rights and materials would they need? | Permitted use, delivery materials, updates, maintenance and the owner of support obligations. |
If an answer is missing, keep that model open for review rather than treating it as a revenue forecast. These are questions about the models already listed here; naming one does not confirm partner availability or platform acceptance.
Keep paid access and failure states with the chosen model. Agreed implementation can then be scoped through development. A contact and a short monetization question are enough to start.
Choose the paid boundary before the payment flow
Describe the benefit the user pays for and when they receive it. Compare possible access models with the product’s operating costs and support obligations.
| Product situation | Model to consider | Decision to record |
|---|---|---|
| Users receive continuing value and the service has ongoing costs | Recurring paid access | Which functions stop when access ends, and what happens to saved data? |
| A feature provides a durable, discrete benefit | One-time access | Which future versions and support are included, and what remains usable? |
| The core task stays free while additional value is optional | Free core with paid features | What stays free for existing users, and where is the paid boundary explained? |
Check access states, including failures
Define what a free user can do. If a trial is proposed, specify its start and end behavior. For paid access, decide how the product checks whether a user can use the purchased feature. Expired access and a cancelled subscription may need different behavior under the chosen terms. Also decide what remains available when the device is offline or the access check fails.
An illustrative product specification could keep local notes readable when a server cannot confirm access to a paid export feature. It would explain the temporary problem and offer a retry. A confirmed payment with a missing feature would use a separate support path so the user is not immediately sent to purchase again. The product owner chooses these behaviors; implementation is scoped separately.
Assign responsibility for billing records, product access and support before implementation. Keep failed payment, missing entitlement and a network error distinguishable in the user-facing messages.
For Chrome, payment required for basic functionality must be clear in the description people see before installing. Google’s payment policy sets that disclosure requirement. An affiliate proposal needs its own review: Chrome’s affiliate policy also addresses disclosure, related user action and direct user benefit. Naming a model does not establish that a particular implementation is acceptable.
The agreed behavior and unresolved decisions can form a request for technical integration.
What we review
The review scope is agreed for your project. It can cover:
- PRODUCT
Value and audience
What the extension does, who uses it, how often the value occurs and what users might reasonably pay for.
- EXPERIENCE
Trust and friction
Where monetization appears, what changes for existing users and how choices or paid boundaries are communicated.
- POLICY
Disclosure and platform fit
Permissions, data use, store rules, partner behavior and legal questions that need current, appropriate review.
- SYSTEM
Technical integration
Payments, entitlements, remote configuration, APIs, reporting, failure modes, security and maintenance ownership.
From review to implementation
- Document the current product. Establish utility, audience, architecture, store position and existing obligations.
- Compare viable models. Assess tradeoffs and reject options that conflict with product value or policy boundaries.
- Design the experience. Define access, disclosure, consent, failure and support flows.
- Confirm vendors and responsibilities. Agree who owns partner contracts, billing, data processing, reporting and customer support.
- Implement and verify. Build the agreed integration and test technical acceptance criteria without promising financial performance.
What to send first
Send the extension listing or a short product description. Explain its main use and the monetization question you want to resolve. If you have audience or revenue figures, include the metric, source and period; if you do not, say so. Mention any model or partner you are already considering and which features must stay free for existing users.