ARTICLE

Designing Products and Benefits in Polar.sh

Polar.sh products connected to multiple developer benefits.

Before creating products in Polar.sh, define the customer right you want to grant. The cleanest billing setup starts from the post-purchase experience.

A Product is the paid package. A Benefit is the access that package grants. A one-time Chrome extension license, a monthly Pro plan, and private repository access can each be modeled as products with different benefits.

For a paid extension, decide what changes after purchase. Does the user unlock sync, export, automation, higher limits, or team features? Those product decisions become entitlement checks in your extension and backend.

License key benefits need explicit rules. Decide whether keys expire, how many activations they allow, whether usage is metered, how refunds affect access, and how a customer can recover a lost key.

GitHub access benefits are useful for templates and private code products. If the customer buys repository access, the purchase flow should make it clear how they claim or accept that access. Manual invites can work early, but automation avoids missed invites later.

Products and benefits do not have to be one-to-one. A lifetime product can grant a license key and repository access. A subscription product can grant only active license validation.

Start simple. For Chrome Extension Kit, the most practical first model is a one-time product with a license-key benefit or repository-access benefit, backed by webhook handling and server-side entitlement checks.

References