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.

The audit numbers anchor on what migration recovers from your existing book. The compounding piece is what happens afterwards.

​
What changes structurally

Migration shifts the billing rail. Not just for the subscribers who get migrated — for every subscriber who arrives after you have web rails in place. Before migration:
  • Existing subs on IAP at 15–30%
  • New subs on IAP at 15–30%
After migration:
  • Existing migrated subs on web at 5–8%
  • Existing un-migrated subs still on IAP (untouched)
  • New subs acquired through web channels on web at 5–8% from day one
The compounding is in the third bucket. Web acquisition was always available; what migration unlocks is a safer path to make web subscriptions the default for more of the business — both the migrated existing book and new cohorts acquired through paid, organic, or partnership channels.

​
Why this matters for paid acquisition

The economics of paid acquisition tighten when fees are 5% instead of 22%. A campaign that was barely profitable at a 22% cap can run materially deeper into the LTV curve at 8%. Concretely: if a subscriber’s lifetime value is 200netoftheoldfeestructure,thesamesubscriber′sLTVunderwebrailsiscloserto200 net of the old fee structure, the same subscriber's LTV under web rails is closer to 240–$260 (depending on cohort retention and Y1/Y2+ mix). That’s not a marginal improvement — it shifts which channels and which CACs are economically viable. Apps that move first see compounding in two places:
  • Existing book: the migrated cohort returns 10–25 points of margin for the lifetime of each subscription
  • New cohorts: every dollar of paid acquisition spent post-migration runs on the lower fee structure from the first charge

​
The earlier you start, the longer compounding has to run

For an app expecting to operate for 5+ years, the compounding window is the dominant variable. A migration that takes 12 weeks frees the next 200+ weeks of acquisition + retention to run on web rails. For an app planning a sale in 18 months, compounding still matters — buyers value LTV-based metrics, and the ones that reflect web economics are more attractive than the ones blended with store fees.
The audit shows a multi-year view alongside the year-one figure for exactly this reason. Year one is the entry; later years are where the default rail matters. The full lifetime number depends on retention curves the public audit doesn’t see.
The migration framework →