Skip to main content
Recurr is built for mobile subscription apps that already have a meaningful book of paying subscribers on Apple or Google Play. The strongest fit is usually a subscription app doing roughly $1M to $20M ARR, with enough app-store exposure that moving a portion of the book to web billing changes the economics. The sponsor is often a CEO, founder, or CFO, but the fit is about the business shape: a real paid book, a reachable subscriber base, and a reason to own the web rail.

​
Strong fit

Material store revenue

The app-store fee line is large enough that migration is worth executive attention.

Subscriber trust

Subscribers recognize the brand and are likely to act on a clear, branded migration path.

A web rail exists or can exist

Stripe is the default rail. Existing Stripe or Paddle infrastructure usually improves fit.

Central access model

RevenueCat, Adapty, Stripe, Paddle, Firebase, or a custom backend can recognize web subscription state.

​
Weaker fit

Recurr is usually not the right first step when:
  • The app is pre-revenue or still searching for product-market fit
  • The app has only a small number of paid subscribers
  • There is no reliable way to identify or reach subscribers
  • Access is entirely StoreKit-only with no backend or entitlement provider to integrate with
  • The team wants a discount-led migration campaign

​
Existing web billing is a positive signal

If you already sell on web, the work changes from establishing a new rail to extending the rail you already have. Existing web billing often makes the migration easier to scope and gives Oikos a stronger operating base after migration.

​
Buyer posture

Recurr is not a generic payment processor or a paywall builder. It is for teams that want a managed path from store billing to web billing, followed by an operating layer for the web book.