Mobile subscription apps leak about 22% of their subscription revenue every year to store fees — based on a typical blended rate across a mobile app's subscriber base. That's 1.8% of annual revenue every month.
Mobile never owned its commercial layer explains why this is now a structural problem mobile subscription companies have to fix.
This is the companion piece — what we built, what it does, and who we built it for.
It's written for founders weighing whether app-to-web subscriber migration is something they should be looking at, and what they'd actually be buying if they engaged us.
What app-to-web subscriber migration is
A working definition:
App-to-web subscriber migration is the operational work of moving existing mobile subscribers from App Store or Play Store billing onto web subscription rails — without breaking access, churning subscribers, or stepping outside store policy.
Three properties worth naming, because each one is where the category often gets confused with something else:
- It's about existing subscribers. Web-to-app — acquiring on the web and delivering the experience in the app — is the parallel pattern for new subscribers, and both surfaces run naturally together once the base is on web rails. Migration is the move that brings your current paying base across.
- It runs cohort by cohort, not as a cutover. A blast migration is an unforced churn event. A controlled migration is an engineering project: pick a cohort, design the offer, measure against an IAP holdout, decide whether to scale based on what the data says.
- It's permitted by the platforms. Apple's guideline 3.1.3(b) explicitly allows qualifying apps to direct subscribers to web purchase. The DMA designated Apple a gatekeeper. Korea passed an alternative-billing law. The policy ceiling has moved; what's left is operational execution.
Why most apps haven't migrated yet
Spotify, Netflix, and a growing number of apps already run their subscriptions on the web. The apps that have moved are exceptional in one specific way: they had the engineering capacity to build the migration system themselves.
The work isn't in the primitives. Stripe handles the billing. The work is in everything around it:
- Entitlement sync — keeping subscription state in sync between web billing and the app so the subscriber experience stays smooth and access is never interrupted
- Cohort selection — which subscribers to invite first, based on plan, tenure, region, engagement
- Offer design — what to give a cohort to make the move worth it, without inducing cross-cohort envy or training subscribers to wait for discounts
- IAP holdouts — running matched controls so you can measure migration as a treatment effect, not a vibe
- Compliance posture — staying inside guideline 3.1.3(b), Play Store policy, regional rules
- Support readiness — equipping the support team for the questions a payment-rails change generates
- Billing reconciliation — keeping the books clean when subscribers temporarily exist on two billing systems
- Wave management — sequencing waves, expanding cohorts only after the prior wave clears agreed thresholds
Solving all of this is months of dedicated engineering work that most subscription companies can't justify against feature-roadmap pressure. The work doesn't get built, the migration doesn't happen, and the margin keeps leaking.
Recurr is what we built to bring that work to all apps — as a managed system, not a build-it-yourself toolkit.
The Controlled Migration Framework
The methodology has a name: the Controlled Migration Framework. Four stages:
- Model — model the migration economics for your specific app. Eligible cohorts, expected adoption, fee recovery, payback. The Migration Assessment is the artifact.
- Pilot — run the framework end-to-end against a small set of cohorts with matched IAP holdouts. The pilot quantifies what migration looks like for your app, not generally.
- Migrate — scale the framework across the eligible base, cohort by cohort, adjusting based on what each wave teaches.
- Manage — once subscribers are on web rails, the operating model changes. Cancel deflection, win-back, pricing experimentation, payment recovery — the lifecycle plays the store sandbox blocked are now available.
Wave-based, threshold-gated, measured against controls. No blast cutovers. If a wave underperforms, the threshold doesn't clear, and we don't expand.
The offer — Pilot, then Migration
Most engagements start with a Pilot — a bounded experiment, two weeks end to end, from $10,000. We run a small set of cohorts against matched IAP holdouts. Offer designed. Outreach sent. Results measured over a defined window.
The Pilot quantifies the migration opportunity for your specific app. It produces subscriber-level data from your own base, not industry benchmarks. There's no obligation to proceed to full Migration after — the Pilot's purpose is to give you the data to decide.
If you proceed, the Migration phase scales the framework across the eligible base, cohort by cohort. The full program — Pilot through Migration — typically runs ten to twelve weeks end to end.
For qualified apps, the Migration fee runs less than a month of current store fees, structured to recoup in cash within the first two migration waves as store float unwinds. The recovered margin then compounds for as long as those subscribers remain on web rails.
Ongoing: the platform fee is 2% of subscription revenue (3% premium in the migration year, reflecting the migration work) plus Stripe's standard fees — call it ~5% all-in for the US, versus 15–30% on store rails.
Functionally: the Pilot is the experiment that tells you whether full Migration is worth doing for your app. The Migration is the work that captures the value the Pilot quantified.
The Migration Assessment is where the dollar-level math gets calibrated — recovered margin, payback period, cash unlock — against your specific subscriber base.
Who Recurr is for
Recurr is for mobile subscription apps where:
- Store-billing fees are meaningful margin leakage, not a rounding error. Typically $1M ARR and up, with a real subscriber base on store rails.
- The team is open to a measured posture. The framework runs cohort by cohort against controls; the program runs ten to twelve weeks. We'll match that pace.
- The work fits a done-for-you engagement. Recurr brings the methodology, the engineering, and the strategic recommendations — cohort selection, offer design, wave sequencing — calibrated to your specific app. Your team brings the subscriber knowledge, the brand voice, and the final approval on each wave.
Every month a migration is delayed costs roughly 1.8% of annual subscription revenue. That cost doesn't pause; it compounds for as long as the rails stay where they are.
— Matt
