> ## 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. # Why Recurr > How a dedicated migration platform compares to alternatives: building it yourself, using in-app paywall tooling, or running migration through a general subscription platform. Store-to-web subscriber migration is a specific operational discipline — not a feature of any existing tool. The alternatives buyers usually weigh against a dedicated migration platform fall into four categories. This page covers each honestly: what it costs, where it breaks, and when it's the right path instead. ## Compared to building it yourself The honest path: identify the work, scope the engineering investment, and decide whether it fits your roadmap. **What "build it yourself" actually requires:** * **Cohort labelling** — selecting which subscribers receive migration offers and when, against tenure / plan / geo / engagement criteria * **Identity bridge** — matching subscribers between app accounts and web checkout without breaking entitlement * **Migration email flow** — wave-conditional sends from your domain, with the messaging variants needed for different cohorts * **Branded checkout on your subdomain** — Stripe Checkout configured for subscription billing with the correct trial / pricing / coupon logic per cohort * **Entitlement sync** — writing web subscription state back to your entitlement system (RevenueCat, Adapty, or custom) without breaking the app's runtime check * **Wave-level gating** — measurement infrastructure to compare migrated vs. matched store-billing holdout, with the discipline to pause if outcomes degrade * **Subscriber-facing CX** — help center articles, ticket capture, macros for the common migration questions * **Operational rhythm** — sequencing waves, handling exceptions, managing cohort-level retries That's a 3-6 month engineering project for a competent team, plus ongoing operational load. The math: at $1M ARR with 22% blended app-store fees, every month of delay costs ~$18K in store fees that Recurr would have eliminated. **When build-it-yourself is the right path:** in-house engineering is genuinely available, the project is treated as a strategic priority (not a side initiative), and you're comfortable with the operational ownership going forward. **When it's not:** the project keeps slipping because it's not the team's top priority, or the operational complexity exceeds what you'd want to maintain in-house. ## Compared to in-app paywall tooling In-app paywall tools (the category that includes the major vendors here) optimise the **in-app subscription experience** — paywall variants, free-trial flows, A/B testing of in-app conversion. They sit between your app and Apple/Google in-app billing. **What they do well:** * A/B test paywall designs in-app * Funnel tracking through the in-app subscription flow * Trial-conversion optimization * Cross-platform paywall consistency **What they don't address:** * Moving existing subscribers OFF in-app billing onto direct web billing * The cohort orchestration, identity bridge, and operational rhythm of migration * Entitlement sync between web subscriptions and the app In-app paywall tooling and Recurr are **complementary, not competitive**. The paywall vendor optimises in-app conversion at the top of the funnel; Recurr migrates the existing subscriber base off in-app rails afterward. Many migration customers continue using their paywall tooling for new-sub acquisition while running migration through Recurr for existing subs. **When in-app paywall tooling alone is enough:** the business is acquiring net-new subscribers and there's no existing book worth migrating off store fees. Pre-migration apps under \$1M ARR usually fit this profile. ## Compared to a general subscription billing platform General subscription platforms (the category that handles SaaS subscription billing — recurring invoicing, dunning, plan management) provide the rails for web subscriptions but don't include the migration mechanic itself. **What they do well:** * Recurring subscription billing on web * Customer billing portal * Dunning / payment recovery * Revenue recognition reporting **What they don't address:** * Cohort labelling against tenure / plan / engagement / geo * Wave-by-wave migration with matched holdouts * Subscriber-facing migration email flow * Identity bridge between app accounts and web checkout * Entitlement sync to the app's RevenueCat / Adapty / custom backend * Migration-specific CX (help center articles, ticket macros, exception handling) General subscription platforms can be the underlying rail for web subscriptions post-migration — Stripe Connect, for example, is exactly that. Recurr **runs on Stripe**, not against it. The web subscriptions Recurr migrates settle to your Stripe Connect account directly. **When a general subscription platform alone is enough:** you're starting from zero, building new web subscriptions from scratch, and there's no existing app-store base to migrate. The migration mechanic isn't needed because there's nothing to migrate. ## Compared to a generic vendor stack The "cobble it together" path: pick a paywall vendor, an entitlement vendor, an email vendor, a billing portal vendor, a CDP, a help-center vendor, and integrate them yourself. **What this looks like:** * 6-8 vendor relationships to manage * N integration touchpoints between vendors * Data continuity between motions (e.g., exit-survey data from Cancel deflections feeding Winbacks) requires custom integration work * Each vendor optimises for their slice; nobody owns the migration outcome **When the vendor-stack path is the right call:** you have a strong internal RevOps or growth-engineering function that can run multi-vendor integration projects with discipline. Otherwise the integration tax exceeds the migration savings. ## When NOT Recurr The honest cases where another path is right: * \*\*Sub-$1M ARR apps** — Apple's Small Business Program rates at 15% all in-app billing; the migration ROI is weaker. Recurr's wedge target is $1M+ ARR where the 30% / 15% blended fee makes migration economically obvious. * **Apps with heavy organic store-install dependency** — apps that rely on Apple's App of the Day, search rank, or ad-credit relationship have residual store-policy exposure that doesn't apply to paid-acquisition-heavy apps. Recurr's ICP skews paid-acquisition. * **Apps with no reachable subscriber base** — anonymous-auth apps without email or another owned channel can't run migration outreach. Reachability is the first ICP filter. * **Pre-product apps** — Recurr is for apps with an existing app-store subscriber base. If you haven't shipped the app yet, you're acquiring new subscribers; migration isn't the right framing. ## What Recurr does that other paths don't Three things define a dedicated migration platform: 1. **Cohort orchestration as a discipline** — wave-by-wave with matched store-billing holdouts, gates on retention, the operational rhythm to pause and adjust per wave 2. **First-party data continuity across motions** — exit-survey data captured at Cancel deflection feeds Winback personalisation; same platform, no integration tax between motions 3. **Founder-led delivery during the early phase** — Design Partner Program perks tied to scarcity; the engagement isn't "configure the dashboard yourself" The economic case: at the Recurr ICP (subscription mobile apps, \$1M+ ARR, reachable base), every month of delay costs more in unrecovered store fees than a migration project costs end-to-end. [Run the audit →](https://recurr.dev/audit) [How it works →](/getting-started/how-it-works) [Pricing →](/working-with/pricing-model)