Exit and portability

The exit question is fair, and the architecture should answer it before the contract does. This page covers how Recurr is structured so leaving doesn’t strand the business. The short version: you own the Stripe Connect account, you own the subscriber data, and you own the customer relationship. Recurr operates rails you control, not the other way around.

​

The architectural defence

Recurr uses Stripe Connect Standard — a Stripe account in your company’s name, with Recurr as the platform that takes a fee per transaction. You are the Merchant of Record on every subscription: the named party on the subscriber’s card statement, the legal counterparty, and the entity Stripe pays out. If Recurr disappeared tomorrow:

• Your Stripe account stays live. It’s in your name, with your tax / legal / banking details. You have a Stripe Dashboard login.
• All migrated subscriptions keep running. They settle to your Stripe account on Stripe’s standard schedule. The renewals don’t pause because Recurr does.
• Recurr’s application_fee deductions stop. With no Recurr platform to take them, the full subscription revenue lands in your account net of Stripe’s processing fee only.
• Subscriber-facing surfaces stay on your domain. subscribe.{yourdomain}.com and the billing portal are routed through DNS you control. You can re-point or take down at your discretion.

This isn’t a contractual promise of post-exit support. It’s an architectural fact about who owns what.

​

What’s yours, structurally

Recurr’s product layer adds operations on top of these — cohort definition, wave orchestration, dashboard, performance reporting, lifecycle motions. Removing the product layer doesn’t break the rails underneath.

​

Data export

Subscriber data — subscription state, payment history, event log, cohort assignments, motion outcomes — is exportable at any time during the engagement and during the post-termination window. Standard formats: CSV, JSON, direct push to a warehouse you specify. The API surface (events, subscribers) is the canonical interface; bulk exports run through the same shape. Stripe-side data (charges, balance transactions, payouts, customer records) is queryable directly through your Stripe Dashboard and Stripe API independent of Recurr — your access to it doesn’t depend on a Recurr login.

​

Post-termination support

The MSA covers a wind-down window after notice of termination where Recurr continues to operate the rails — running motions cleanly, surfacing event data, and supporting your team’s transition off the platform. Specifics — notice period, support cadence, post-termination data-access duration — land in the MSA when scope is confirmed. The intent is alignment, not lock-in. If the engagement doesn’t work, the off-ramp is cleaner than the on-ramp.

​

Re-platforming risk

If you decide to migrate off Recurr to another platform — a future internal build, a different vendor, a Stripe-native setup — the technical lift is bounded:

• Subscriptions stay on Stripe. No re-card, no re-billing, no PCI scope shift. The new platform takes over webhook subscriptions; subscribers see no disruption.
• Entitlement source stays where it is. RevenueCat, Adapty, or your custom backend keeps reading subscription state. The source of the webhook events changes; the entitlement check doesn’t.
• DNS stays where it is. subscribe.{yourdomain}.com either re-points or stays on Recurr-managed infra for a transition window — your choice.

The migration to Recurr was the moment subscribers shifted rails (app-store to web). Migrating off Recurr is platform-side only — subscribers don’t see it, the rail doesn’t change, the renewals continue.

​

What we don’t promise

A few things worth being clear on:

• No subscriber transfer to a competitor. Recurr won’t ship your subscriber list to a named competitor as part of an exit. You have it; what you do with it is your call.
• No indemnity against your downstream choices. If you migrate off Recurr to a setup that’s misconfigured, that’s your engineering team’s call to remediate. Recurr’s post-termination support is bounded to the rails it set up.
• No “stay free” runout. If the engagement ends, Recurr’s platform fee stops; so does Recurr’s operation. The rails are yours; running them with a different operator (or yourself) is what comes next.

​

Why this shape matters

Vendor risk is real for early-stage software. The way Recurr addresses it is structural — the customer is Merchant of Record, on a Stripe account in their own name, with subscriber data they already had. The relationship’s continuity doesn’t depend on Recurr’s continuity. This is the same shape Stripe Connect Standard takes for thousands of platforms across industries. The pattern is mature; the legal posture is established. Recurr applies it to subscription migration. Stripe Connect → Risk register →