> ## 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.

# How the margin compounds

> The recovery isn't a one-time event. Every new subscriber acquired post-migration routes through the same lower fee structure from day one.

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 app-store billing at 15–30%
* New subs on app-store billing at 15–30%

After migration:

* Existing migrated subs on web: **6% Recurr take** in Y1 (3.5% platform + 2.5% performance fee), **3.5% Recurr take** in Y2+, plus your country-specific Stripe processing
* Existing un-migrated subs still on app-store billing (untouched)
* **New subs acquired through web channels**: **3.5% Recurr take** from day one (no migration performance fee on new web subs), plus Stripe processing

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

<Note>
  **Assumptions in this section.** US-based app on Stripe (2.9% + $0.30/txn), $17 ARPU. At \$17 ARPU the per-transaction flat fee adds \~1.76 points to the Stripe percentage basis, so all-in Stripe is \~4.66%. Your live [Migration Audit](https://recurr.dev/audit) uses your country-specific rate and actual ARPU.
</Note>

A migrated app's web acquisition runs at roughly **8% all-in on a new subscriber** (3.5% Recurr platform + \~4.66% Stripe at \$17 ARPU, US baseline) instead of the 22% blended store fee. A campaign that was barely profitable at a 22% take can run materially deeper into the LTV curve when the take drops to \~8%.

Concretely: if a subscriber's lifetime value is $200 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 recovers margin permanently for the lifetime of each subscription (see [where the recovery comes from](/opportunity/where-recovery-comes-from) for the worked numbers)
* **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.

<Note>
  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.
</Note>

[The migration framework →](/framework/pilots-and-waves)