Where a flow platform fits in your subscription stack

Subscription apps rarely fail because they picked the wrong billing SDK. They stall when five tools overlap, nobody owns the journey between install and payment, and every experiment waits on a release.

The market has matured into layers: billing and entitlements, paywall presentation, attribution, product analytics, and now journey experimentation. This post maps those layers without a vendor hit piece, shows common stacks by company stage, and explains where a flow platform like Rheo sits relative to RevenueCat, Superwall, Adapty, and your MMP.

Stack layers diagram

Think top to bottom from user action to infrastructure:

┌─────────────────────────────────────────────┐
│  Journey layer (onboarding, flows, branches) │  ← Rheo
├─────────────────────────────────────────────┤
│  Paywall / offer presentation (optional)     │  ← Superwall, Adapty, native
├─────────────────────────────────────────────┤
│  Billing & entitlements                      │  ← RevenueCat, Qonversion, native StoreKit
├─────────────────────────────────────────────┤
│  Attribution & UA                            │  ← AppsFlyer, Adjust, Singular
├─────────────────────────────────────────────┤
│  Product analytics                           │  ← Amplitude, Mixpanel, PostHog
├─────────────────────────────────────────────┤
│  App binary (RN, Swift, Flutter)             │  ← Your codebase + store release
└─────────────────────────────────────────────┘

Not every app buys every box. The mistake is assuming one box replaces three.

What each vendor optimizes

Vendor / category	Primary job	Typical buyer
RevenueCat	Subscriptions, entitlements, receipts, charts	Engineering + finance
Superwall	Paywall templates, paywall A/B, WebView/native paywalls	Growth + eng
Adapty	Paywalls, onboarding builder, subscription analytics	Growth
Apphud / Qonversion	Billing + analytics alternatives	Indie to mid-market
AppsFlyer / Adjust	Install attribution, SKAN, deep links	Marketing
Amplitude / Mixpanel	Event analytics, cohorts	Product
Rheo	Multi-step native flows, branching, flow-level experiments OTA	Growth + product

RevenueCat is the entitlement source of truth. "Is this user pro?" lives here. RevenueCat Experiments focuses on paywall and offering tests tied to their stack.

Superwall / Adapty excel at paywall-centric experimentation and storefront presentation. Many teams start here when the main question is "which paywall design converts?"

Rheo optimizes the journey graph: onboarding screens before the paywall, ATT branches, cancel surveys, win-backs, feedback flows, stories-style sequences. Flow-level A/B tests where the unit of change is a path, not a single paywall template.

Overlap exists. The question is which layer is system of record for which decision.

Common stacks by stage

Indie (solo dev, under 5k MAU)

Layer	Common choice
Billing	RevenueCat free tier
Paywall	RevenueCat Paywalls or simple native
Journeys	Hardcoded RN screens → Rheo when iteration hurts
Attribution	MMP free tier or none
Analytics	RC charts + Firebase

Pain point: no time to ship five onboarding variants. Rheo Indie plan targets experiment velocity at low MAU.

Growth stage (5k-100k MAU, paid UA)

Layer	Common choice
Billing	RevenueCat
Paywall	RevenueCat + Rheo flow paywall step, or Superwall alongside
Journeys	Rheo for onboarding, cancel, win-back OTA
Attribution	AppsFlyer or Adjust
Analytics	Amplitude or Mixpanel + step funnels in Rheo

Pain point: acquisition outpaces funnel optimization. Need same-week experiments on full paths.

Scale (100k+ MAU, multiple squads)

Layer	Common choice
Billing	RevenueCat with server-side webhooks
Paywall	Split: RC for truth, Rheo for journey context
Journeys	Rheo with approvals, localization, trait targeting
Attribution	Enterprise MMP + SKAN expertise
Analytics	Warehouse + product analytics; Rheo for funnel diagnostics

Pain point: coordination between growth, monetization, and core product. Flow platform gives one canvas instead of three repos.

Rheo placement: journey experimentation layer

Rheo does not replace RevenueCat. It does not replace your MMP. It replaces hardcoded navigation trees and slow release cycles for everything between "user opened app" and "entitlement changed."

Rheo owns:

• Screen sequence and branches
• OTA publish of flow changes
• Step-level funnel and flow experiments
• Native rendering of flow screens
• Channels (entry points) and targeting

Rheo does not own:

• Receipt validation (RevenueCat)
• SKAN postbacks (MMP)
• Full product analytics warehouse (Amplitude)
• App Store binary updates

Purchase buttons in a Rheo flow call RevenueCat (or your billing SDK). Events flow to Rheo for funnel metrics and to your analytics stack for cohort analysis. Clean handoff beats duplicating revenue truth.

Decision tree: do you need a flow platform?

Start
  │
  ├─ Onboarding/paywall changes require app release every time?
  │     └─ Yes → Strong signal for remote flows
  │
  ├─ Experiments are paywall-only, one screen?
  │     └─ Yes → Paywall tool may suffice for now
  │     └─ No  → Flow platform for path-level tests
  │
  ├─ Need cancel/win-back/ATT branching in same tool as onboarding?
  │     └─ Yes → Flow platform (Rheo)
  │
  ├─ Team: growth PMs blocked on eng for copy tests?
  │     └─ Yes → Flow platform with visual editor
  │
  └─ Already on Adapty Flow Builder / Superwall for full journeys?
        └─ Compare: native rendering, RN support, experiment depth, stack fit

Honest answer: if you ship one paywall and rarely touch onboarding, RevenueCat plus a paywall specialist may be enough until growth becomes a bottleneck.

Avoiding five-dashboard duct tape

Symptoms of a messy stack:

• Paywall variant in tool A, onboarding order in git, cancel survey in tool C
• Revenue numbers disagree between dashboards
• No one can draw the user path from ad click to subscription on one screen
• Experiments collide because channels are not mutually exclusive

Integration principles:

1. One entitlement source (usually RevenueCat)
2. One journey editor for pre-paywall and lifecycle flows (Rheo)
3. One attribution source (MMP)
4. Pass traits, do not duplicate state (cancel reason, plan, locale into flow resolve)
5. Define metrics hierarchy: install → step completion → trial → paid, each owned by one primary tool

Weekly growth review should open one funnel view, not five tabs.

Migration paths

From hardcoded onboarding: integrate Rheo SDK, rebuild current flow on canvas, parallel run, cut over channel by channel.

From paywall-only tool: keep billing as-is; add Rheo for upstream onboarding and downstream cancel/win-back. Paywall step invokes existing purchase code.

From WebView paywalls: consider native flow rendering for conversion-critical paths; migrate screen by screen.

From Remote Config JSON: migrate schema to canvas; deprecate custom renderer maintenance.

Migrations are phased. You do not rip out RevenueCat. You stop hardcoding screens that change weekly.

Integration data flow (RevenueCat + Rheo)

A concrete pattern teams replicate:

Install → MMP attributes user
       → App calls rheo.present('onboarding')
       → Rheo resolves flow variant from traits + experiment
       → User completes screens; events to Rheo analytics
       → Paywall step calls Purchases.purchasePackage()
       → RevenueCat confirms entitlement; app unlocks features
       → MMP logs subscription event; warehouse joins on user_id

Traits to pass at resolve time: attribution_channel, platform, locale, is_trial_eligible, later cancel_reason for lifecycle channels.

Avoid duplicating offering identifiers in Rheo and RevenueCat without a single config source. Many teams define offerings in RevenueCat and reference offering keys in flow purchase steps only.

Webhooks from RevenueCat update your backend; optional forwarding enriches win-back audiences. Rheo does not need to be in the webhook path for basic flows.

Buying committee: who cares about which layer

Role	Cares about
CTO / eng lead	SDK surface area, crash rate, release cadence
Head of growth	Experiment velocity, funnel metrics
Finance	RevenueCat as billing source of truth
Marketing	MMP ROAS tied to in-app conversion
Legal	Store compliance, promotional offer rules

Positioning Rheo to engineering: small native SDK, clear boundaries, no fork of billing. Positioning to growth: own the journey graph without Swift or Kotlin fluency.

Evaluating vendors without a bake-off circus

Run a two-week proof instead of a six-month RFP:

1. Rebuild current onboarding in candidate tool
2. Ship one real experiment to 10% traffic
3. Compare step analytics clarity, publish latency, and eng hours spent
4. Check native rendering on low-end Android device

Score integration friction separately from editor UX. A pretty canvas that requires eng for every publish fails the growth test.

Future-proofing the stack

New platforms (SwiftUI, Flutter) and new store rules arrive yearly. A journey layer abstracted from hardcoded screens adapts faster than rip-and-replace navigation refactors.

Billing and attribution vendors may swap. Entitlement APIs are stable enough to wrap. Flow definitions moving between tools is harder, so pick a journey vendor with export history and clear data ownership.

Red flags in stack reviews

Watch for these in quarterly tooling audits:

• Three dashboards showing different trial start counts for the same week
• Growth cannot answer which onboarding variant a paid subscriber saw
• Cancel reasons live in Zendesk tags instead of structured traits
• Paywall winner declared without install-to-trial metric
• Engineering is bottleneck for every permission copy test

Each red flag maps to a layer gap Rheo or better integration hygiene closes.

Stack diagram for your wiki

Paste this into Notion and label owners:

1. Attribution (MMP): owns install source and campaign IDs
2. Analytics (Amplitude/Mixpanel): owns cohort reporting
3. Billing (RevenueCat): owns entitlements and revenue events
4. Journeys (Rheo): owns pre-paywall and lifecycle screens
5. App binary: owns core product and SDK versions

When a metric moves, one owner investigates first. Fights about "whose dashboard is wrong" shrink.

Document integration owners in a shared runbook so new hires know which vendor to ping for subscription bugs vs funnel bugs vs attribution gaps.

Neutral comparison takeaway

If your main pain is...	Start with...	Add Rheo when...
Subscription infrastructure	RevenueCat	Journeys need OTA experiments
Paywall design only	Superwall / Adapty	Full funnel path testing
Attribution blind spots	MMP	Funnel tied to channel performance
Slow flow iteration	Rheo	(core use case)

The subscription stack is additive. Winners in 2026 assemble layers deliberately and assign ownership per layer.

Start for free. See where journey experimentation fits alongside the tools you already use.