Skip to main content

Documentation Index

Fetch the complete documentation index at: https://recurr.dev/docs/llms.txt

Use this file to discover all available pages before exploring further.

Migration’s most visible effect is on the P&L. Its second-order effect for growth teams is moving pricing, checkout, attribution, and subscriber communication onto rails the app controls.

​
What’s unblocked now

Same-day pricing changes

Web prices can update without an App Store review cycle. Tests, regional adjustments, and promotional campaigns move faster once the billing rail is web-first.

Regional + currency-native offers

Different price points by geo, with native currency at checkout. Useful where App Store tier mapping does not match willingness to pay.

Granular trials + intro offers

Custom trial lengths, intro pricing structures, and plan-specific incentives outside the constraints of store-native promotional systems.

Lifecycle foundation

Web rails create the foundation for cancel flows, win-backs, upgrades, and recovery. Recurr’s current migration offer does not promise a self-serve lifecycle suite.
The single biggest growth unlock is the change to LTV per channel. A subscriber whose lifetime value was $200 net of store fees becomes a higher-LTV subscriber on web rails, depending on retention, plan mix, store mix, and payment costs. That shift can make campaigns viable that were previously capped by app-store fee drag:
  • Channels with higher CACs become easier to justify when net revenue per subscriber expands
  • Existing channels can run deeper before payback breaks
  • Attribution can be cleaner from click to subscriber when checkout happens on web
The audit’s year-one recovery and steady-state recovery numbers give the first-pass view. The Migration Analysis is where cohort-specific acquisition and retention assumptions get pressure-tested.

​
Lifecycle plays web rails make possible

Some lifecycle work technically runs on app-store rails but is awkward at best:
  • Dunning + payment recovery - Apple and Google handle this their way; web rails let the app control retry cadence, messaging, and recovery offers
  • Plan downgrades + sidegrades - supported cleanly on web; constrained on store
  • Pause / vacation flows - natural on web; limited on store
  • Branded billing emails - your domain, your design, your support links
Migration moves these from “constrained workaround” to “possible on rails you control.” Recurr’s current scope focuses on migration, billing, entitlement sync, cohort operations, and reporting. Broader lifecycle modules are roadmap and partner-scoped.

​
What stays the same

  • Existing acquisition channels keep operating. App Store ads, organic discovery, paid app installs - all unchanged.
  • In-app experience. Identical to today. The app itself doesn’t need to know whether the user is paying via Apple, Google, or web.
  • Subscriber identity. Apple Sign In / Google Sign In can carry forward; the same user has the same identity across rails.

​
What to plan for during migration

The migration window is operationally focused: wave-by-wave, gating-driven, and centered on cohort selection. It is the wrong time to ship a major new pricing strategy or redesigned paywall in parallel. Most growth teams pause major web-paywall changes during active migration, then layer pricing, offer, and regional experiments on top once the migrated base is steady.

​
When migration unlocks something already on your roadmap

If your growth team has a deferred pricing experiment, regional expansion, or lifecycle redesign blocked by store constraints, mention it on the Migration Review. The framework can sequence the migration so the experiment is unblocked at a known point in the timeline.