Subscriber-side risks
What could affect end-users on a migration cohort.Double billing
Risk: Subscriber pays Apple/Google AND web in the same period — migration runs while existing app-store subscription is still active. Response: Migration offers explicitly cancel the existing app-store subscription before the web subscription activates. Identity bridge confirms the cancellation succeeded before the web charge fires. If for any reason both bills land in the same period, Recurr’s CX layer refunds the duplicated charge automatically — the subscriber sees one charge, not two.Migration confusion
Risk: Subscriber doesn’t understand why they’re being asked to switch billing — perceives it as suspicious or as the app raising prices. Response: Migration emails come from the customer’s domain (not Recurr’s), with the customer’s branding. The email explains the rationale clearly — usually price protection or expanded features on web. Recurr’s CX layer staffs the help center + ticket interface for subscriber questions, with macros pre-built for the common cases.Failed checkout
Risk: Subscriber attempts to migrate but checkout fails — card declined, regional payment issue, technical error. Response: Failed-checkout subscribers stay on app-store rails, untouched. The migration offer can re-fire on a later wave once the issue is understood. Stripe’s smart retries handle most card-decline cases; Recurr’s checkout supports local payment methods via Stripe (Apple Pay, Google Pay, region-specific methods) to reduce friction.Entitlement collision
Risk: Subscriber arrives at the app after migration and their entitlement check fails — they paid on web but the app still sees the (now-cancelled) Apple receipt. Response: Recurr writes the new web subscription state to the customer’s entitlement system (RevenueCat, Adapty, or custom backend) BEFORE the app-store cancellation lands. The handover is atomic from the app’s perspective. If a race condition produces a brief mismatch, the entitlement system has both records — the customer’s resolution logic decides; Recurr’s events surface the state for diagnosis.Identity bridge — subscriber doesn’t complete verification
Risk: Subscriber clicks the migration link, lands at branded checkout, but doesn’t complete the identity step (e.g., abandons partway, fails to re-verify email, hits an OAuth flow they can’t navigate). Response: This is a user-behavior outcome, not a Recurr-mechanic failure. The identity bridge resolves automatically for ~99% of subscribers — the bridge’s job is to match the subscriber’s app account to the web checkout session. Where the mechanic works but the subscriber doesn’t complete, the subscription simply isn’t migrated; the subscriber stays on app-store rails, untouched. Recurr’s CX layer holds re-engagement state for these cases and routes the small remainder to the customer’s team when customer-specific judgement is needed (e.g., long-tenure subscriber who needs human help). No subscription state corruption; no double-billing; no support-queue tsunami.Loss of accumulated benefits
Risk: Subscriber has long tenure on app-store rails — Apple Loyalty discount (15% rate after year one), grandfather pricing, family-share access — and the migration is perceived as losing those benefits. Response: Migration offers preserve the subscriber’s current price. Apple’s loyalty rate becomes the customer’s margin, not the subscriber’s price.Customer-side risks
What could affect the customer’s business.Migration cohort underperforms
Risk: A migration wave produces churn or conversion outcomes worse than the holdout baseline. The thesis breaks. Response: Every migration runs against a matched store-billing holdout. Wave-level gates pause the program if outcomes degrade — Recurr doesn’t proceed to the next wave until the current one clears. The Controlled Migration Framework is designed so the worst case is “first wave underperforms; we pause and reassess” rather than “we migrated 50% of the base and discovered a problem.”Store-policy reaction
Risk: Apple or Google reacts negatively to the migration — app removed, search rank affected, ad credits revoked. Response: Recurr’s migration mechanic operates entirely outside the app — email from the customer’s domain, web checkout on the customer’s server, Stripe Connect for payment. There is no in-app communication about the web option, so Apple’s policy enforcement (3.1.3(b) and similar) doesn’t apply to the migration flow. The customer’s app remains fully compliant; the in-app billing option stays preserved. See Apple compliance → for the policy mechanics.Vendor dependency / what if Recurr disappears
Risk: Recurr fails as a business or is unable to continue operations. The customer’s migrated subscribers stop being billed correctly. Response: The customer’s Stripe Connect account is in their name — not Recurr’s. Subscriptions live in the customer’s Stripe account directly. Recurr is the operational interface for managing them; if Recurr ceases to operate, subscriptions continue billing through Stripe uninterrupted, and account control transitions to the customer via Stripe’s standard platform-disconnection process (direct for Stripe Standard Connect engagements, mediated through Stripe support for embedded-dashboard engagements). This is structural, not contractual — no migration of data required to recover. See portability and reversibility →.Data export / portability
Risk: Customer wants to leave Recurr after migration; needs to extract subscriber state, history, and operational data. Response: All subscriber + subscription state exports as CSV or JSON via the dashboard. Historical webhook events can be replayed to any HTTPS endpoint via the Replay API. The customer’s Stripe account already holds the billing data directly. There is no data lock-in.Cash-flow timing mismatch
Risk: Customer migrates a cohort expecting near-term cash flow but Stripe payouts land slower than expected for their region. Response: Stripe payout schedules are configurable per Stripe account; most regions support 2-day payouts. The migration analysis confirms the customer’s specific payout schedule before pilot kickoff so cash-flow modeling reflects reality.Recurr-side risks
What Recurr itself is exposed to operationally.Operational capacity (pre-customer phase)
Risk: Founder-led delivery limits concurrent customer count. As the customer base grows, capacity becomes a bottleneck. Response: Design Partner Program is bounded by capacity intentionally — the founder runs migrations directly for the first cohort. Engineering team scales alongside customer count. Customers in the early cohort get higher founder touch as a perk, not a stretched-thin service experience.Compliance scope expansion
Risk: Customer base spans regulations Recurr hasn’t formally certified against (GDPR, CCPA, SOC 2, HIPAA-adjacent cases). Response: Recurr’s current compliance posture is GDPR + CCPA-aligned. SOC 2 Type I targets alongside customer-#1 deployment; Type II 12 months after. Customer-specific compliance needs are scoped during Migration Review — engagement doesn’t begin until alignment is confirmed.Stripe Connect dependency
Risk: Stripe changes Connect terms, pricing, or capability in ways that affect Recurr’s customers. Response: Recurr maintains direct technical relationship with Stripe’s partnership team. Material Connect changes propagate to customers with advance notice. Stripe is structurally critical to Recurr’s model — diversification of payment rail is not in scope.What’s not yet quantified
Honest pre-customer framing:- Conversion rate per migration wave — Recurr models 40% conservative / 55% base / 70% optimistic for first-wave migration rate. Even at the conservative 40% case, the program self-funds. Real-world data lands with customer-#1 outcomes.
- Customer-specific incident response calibration — formal customer-specific incident response SLAs finalise per-MSA. The framework above is what Recurr operates against operationally.
- Multi-region failover guarantees — currently single-region (US-East). Multi-region active failover scoped for post-customer-5.
Cross-references
- Reliability → — service level commitments, error modes, on-call
- Compliance posture → — SOC 2, GDPR, regulatory
- Portability + reversibility → — data export, exit
- Controlled Migration Framework → — wave-by-wave gating