All posts
May 15, 2026Matthew Vanmidde8 min read

What Recurr does, and who it's for

Recurr moves mobile subscription apps from store-billing leakage onto owned web rails — the first journey in a per-subscriber growth platform. The framework, the engagement, and the economics.

Store billing costs a typical mobile subscription app about 22% of its recurring revenue — a blended rate across plan mix, store mix, and fee tiers. Month by month, that's about 1.8% of annual revenue going to the stores.

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 store-to-web subscriber migration is something they should be looking at, and what they'd actually be buying if they engaged us.

One framing before the detail: migration is where Recurr starts, not where it ends. The platform we're building runs on the rails migration puts in place — real-time growth decisions made for each subscriber, one at a time, across their whole life with the app. This piece is about the first journey, the one you'd buy today.

What store-to-web subscriber migration is

A working definition:

Store-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:

  1. 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.
  2. 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 a store-billing holdout, decide whether to scale based on what the data says.
  3. It's permitted by the platforms. Apple's guideline 3.1.3(b) explicitly allows qualifying apps to direct subscribers to web purchase — that's the permission this work runs on. The broader climate keeps moving the same direction (the DMA in the EU, Korea's alternative-billing law), but the mechanic doesn't depend on any of it: it runs entirely outside the app. 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
  • Store-billing 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:

  • Audit — model the migration economics for your specific app. Eligible cohorts, expected adoption, fee recovery, the cash the stores currently hold in settlement. It starts with the free self-serve audit and deepens from there — the Migration Hub is where it lands.
  • Pilot — run the framework end-to-end against a small set of cohorts with matched store-billing 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.
  • Compound — once subscribers are on rails you own, a different operating model opens up. The per-subscriber motions web SaaS has compounded on for a decade — cancel deflection, win-back, pricing that adapts to each subscriber, payment recovery — were never reachable inside the store sandbox. This is the direction Recurr is building: Kairos, the decisioning engine that makes those calls for each subscriber, one at a time. Migration is the journey that unlocks it — and it keeps running underneath, because new store cohorts keep maturing into eligibility and move on the same gates at the same 5%.

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 $5,000. We run a small set of cohorts against matched store-billing 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 — Nostos, our managed migration program — scales the framework across the eligible base, cohort by cohort. Covering the base you have today takes about a quarter: a two-week pilot, then a roughly ten-week migration that can compress to about four weeks on strong performance. The eligible base itself never closes, so the program keeps running against each new cohort that matures into it.

The Migration fee is a flat 5% of what each migrated subscriber pays during their first 12 months on web billing — billed monthly as those payments arrive. Nothing is owed for subscribers who stay on the stores. Against a store floor of 15%, that rate is a third of what the stores take, and it's covered every month from the first — there's no payback period to wait through. The recovered margin then compounds for as long as those subscribers remain on web rails. The Pilot is the only cost that comes out of pocket, and it's credited in full against those migration fees.

Ongoing: Oikos, the platform your web book runs on, is a flat 2% of successful payments on the connected web book — and it's included for each migrated subscriber's first 12 months on web. You keep your own Stripe account and pay Stripe's standard processing directly — Recurr runs the engine on top of the rail you own. That's a fraction of the 15–30% store rails take today.

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 Hub is where the dollar-level math gets calibrated — recovered margin, eligible cohorts, the cash released as store settlement unwinds — against your specific subscriber base. It's a private room holding the audit, the migration method, the questions each stakeholder needs answered, the approvals, and the pilot path, so finance, engineering, and legal can each work through their own part without everyone joining the same call.

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 — about ten weeks to cover the base you have today. 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 on store rails costs roughly 1.8% of annual subscription revenue — steady, measurable, and recoverable whenever you start.

Matt

Matthew Vanmidde, Founder of Recurr

Matthew Vanmidde

Founder & CEO, Recurr

Get the migration playbook

How mobile subscription apps move existing app-store subscribers onto direct billing — sequence, cohort selection, retention safeguards, and unit economics worked at $5M ARR.