RevenueCat Blog

How to know if your free tier is generous enough

Thu, 14 May 2026 10:00:00 GMT

Going freemium is supposed to unlock organic growth. You give away the core product, users fall in love, and they tell their friends. But for many apps, it doesn’t play out that way. The free tier feels like a stripped-down trial, users churn before forming a habit, and the word-of-mouth engine never starts.

The standard freemium diagnostics don’t help much here. Conversion rate, paid penetration, and LTV — they all measure what your paying users are doing. None of them tell you whether your non-paying users are an asset or dead weight.

On a recent episode of the Sub Club podcast, Opal CEO Kenneth Schlenker shared the question he uses instead: would a non-paying user recommend the app to a friend?

If the answer is no, you need to give away more.

Why this question matters more than conversion rate

“If you want the freemium dynamic to really pay out, you need to make sure that the free users are recommending the app,” Kenneth says. “Otherwise, that doesn’t work.”

Freemium works only if free users stick around long enough to build a habit and recommend the app. If your free tier is too restrictive — it’s missing core features to achieve users’ job-to-be-done, or it just feels like a countdown to a paywall rather than a useful product — then neither happens. You get a small percentage converting to paid and zero organic pull.

That’s the trap. A free tier designed to demo the product instead of be a product.

How to actually answer the question

The recommendation question is a heuristic, not a metric. But you can triangulate toward an answer by watching two things in parallel:

LTV of installs
Overall retention across both free and paid users

When Opal tested how much to give away in their core ‘blocks’ feature — the scheduled restrictions that block distracting apps during specific times — the team tried everything from one block (very restrictive) to several, measuring these two metrics at every step.

The goal was to find the point where both metrics were moving up. Rather than focusing on just paid conversion, or free-to-paid funnel efficiency, this would show the combined health of the user base.

“Turns out that three [blocks] is enough for free users to get a great experience,” Kenneth explains. “They can actually really use the app, try out a few different things, and then also really power users that are convinced will pay because they want more.”

Three blocks gave non-payers enough utility to build a habit — and recommend the app. It also left enough headroom that committed users still had a reason to upgrade. If LTV and retention don’t both improve as you adjust your free tier, you’re optimizing one segment at the other’s expense.

What ‘yes’ actually unlocks

When Opal moved from a hard paywall to a genuinely generous free tier, their pay penetration — the share of monthly active users on a paid plan — dropped from 20% to 9%. That sounds like a disaster, but it wasn’t.

The free tier unlocked a segment Opal couldn’t reach behind a paywall: high school and college students, who now make up two-thirds of Opal’s DAUs. These users dragged pay penetration down — but they were doing something more valuable: telling their classmates, then telling their schools. Students recommending the app to administrators created Opal for Schools, now a contracted B2B revenue line. That distribution channel didn’t exist when there was only a hard paywall.

Overall, the shift pushed Opal past one million daily active users. “It’s a short-term, scary drop, but what happens in the long-term is that it pays back tenfold,” Kenneth says.

The takeaway

If your non-payers wouldn’t recommend the product, you don’t have freemium — you have a trial in disguise.

The fix isn’t always to give away more. Sometimes it’s to give away differently — more of one feature, less of another, restructured so the free experience is genuinely useful rather than a teaser. But the recommendation question is the compass. Pair it with parallel tracking of LTV and overall retention, and you have a way to find the line for your own product.

Think about:

Does it unlock enough utility to build a habit or progress towards their goal?
Does it unlock enough to make them recommend the app?
Does it keep enough back to give users a reason to upgrade?

Most teams optimize their free tier to maximize conversion. The teams that win optimize it to maximize recommendation, and let conversion follow.

A machine learning test doubled Life360’s top-tier subscriptions — without losing a single mid-tier user

Wed, 13 May 2026 13:34:45 GMT

The freemium bill of rights

Six months into his role as VP of Product at Life360, Giordano Contestabile ran an experiment. The numbers came back showing a massive revenue upside. He ran to the executive team, expecting a celebration. Instead, he got yelled at.

He had violated what former CEO Chris Hulls called the “freemium bill of rights” — a core set of principles dictating that certain features, particularly those related to family safety, must never be taken away from free users to force a conversion.

“The reason number one why people tell us they don’t subscribe is because the free tier is good enough,” Contestabile says. “Our philosophy is that literally we want to do something about it, but that something is not making the free tier worse — is trying to provide more value and really diversify the subscription offering.”

For an app with nearly 100 million monthly active users, that free tier is the ultimate moat. Life360 relies heavily on network effects; the app isn’t useful in “solo mode,” and the primary discovery channel is parents telling other parents. Locking core utility behind a paywall might juice short-term revenue, but it would fundamentally break the viral loop that built the company.

Why an inconclusive experiment is the only true failure

To find new ways to drive revenue without degrading the free experience, Life360 had to scale its experimentation. But Contestabile doesn’t view experimentation as a series of isolated tests; he treats it as a portfolio.

The effectiveness of that portfolio comes down to three levers: velocity (how many experiments ship), win rate (what percentage succeed), and average win size. But surprisingly, Contestabile doesn’t mind a low win rate.

“The only experiments that we are sad about is an experiment that is inconclusive,” he explains. “Then we feel we wasted our time — we didn’t set up the experiment correctly or the hypothesis wasn’t right.”

A loss, on the other hand, is just data. It proves or disproves a hypothesis. Often, a losing experiment reveals that a feature didn’t work broadly, but resonated deeply with a specific cohort — like users in the suburbs who have been on the platform for a month and own a dog.

Those granular learnings feed directly into the next cycle of tests.

How ML doubled Platinum subscriptions

That granular approach to segmentation recently led to one of Life360’s biggest wins.

The app offers three subscription tiers: Silver, Gold, and Platinum. Historically, the vast majority of users chose Gold. In paywall flows, it’s difficult to clearly articulate the value of all three tiers without overwhelming the user, so the team typically defaulted to presenting the Gold option.

To challenge this, the team deployed a machine learning model utilizing about 900 distinct data points to identify users with a high propensity to buy the Platinum tier. When the model detected a high-propensity user, it dynamically presented the Platinum offer instead of Gold.

The results were staggering. “It doubled the percentage of new users subscribing to Platinum,” Contestabile says. “But it did that without losing a single gold subscriber, which was super surprising.”

The model successfully identified users who wouldn’t have converted on the Gold tier anyway, but were perfectly matched for the specific benefits of Platinum.

Parents aren’t viral

Not every data-driven bet pans out. Knowing that 40% of Life360’s users discovered the app through word-of-mouth — usually parents talking at school pickup — the team tried to digitize that behavior.

They built in-app referral mechanics. They offered free Silver subscriptions to users who invited friends. They tested multiple variations of sharing buttons.

“Nothing. Really failure across the board,” Contestabile admits. “And the reason is people my age, families, older people — they are not viral. Parents are not viral.”

The demographic that actually exhibits viral sharing behavior on mobile devices are teenagers. But while teens are on Life360, the parents are the ones making the purchasing and installation decisions. The team learned the hard way that you can’t force a digital referral loop onto an audience whose natural sharing behavior is entirely offline.

In the full episode, Giordano and David also discuss how Life360 incorporates physical hardware like Tile into its subscription ecosystem, why the company is pushing to make growth a mandate for every department including HR and Finance, and the strategic value of the new “pet profile” feature.

Guest links:

Giordano Contestabile on LinkedIn
Life360
Life360 Careers

Testing subscriptions on Compose Multiplatform: one test suite for iOS and Android

Tue, 12 May 2026 00:22:09 GMT

You wrote your subscription logic once in commonMain, your Compose Multiplatform paywall renders the same on iPhone and Pixel, and your CustomerInfo flow works on both platforms without a single expect/actual. Then you sit down to test it and find that the same product still has two sandboxes, two test account systems, two CI jobs, and two completely different ways for the platform to say “the purchase succeeded.” The unified codebase from Compose Multiplatform Subscriptions stops at the test boundary, and most teams either skip purchase testing entirely or maintain two parallel test suites that drift apart.

In this article, you’ll work through a complete subscription testing setup for a Compose Multiplatform app, exploring why Google Play and StoreKit sandboxes resist unification, how RevenueCat’s Test Store collapses both into one sandbox, how to wire the Test Store into a KMP build with a single BuildConfig field, why the right testability boundary is a PaywallsRepository interface in commonMain, how to write coroutine and StateFlow tests in commonTest so a single suite runs against both targets, why fakes beat mocks for KMP subscription code, and how to layer instrumented tests on top so the same code path is exercised end to end.

Every snippet uses the same source layout as cat-paywalls-kmp, the official CMP demo, so you can drop these patterns into a real project without renaming anything.

The fundamental problem: One product, two sandboxes

Subscription testing on a native Android app is already an undertaking. The ultimate guide to Android subscription testing lists license testers, internal tracks, closed tracks, the android.test.purchased static response, and a handful of BillingClient quirks before you can reliably run a single purchase end to end. The equivalent path on iOS adds StoreKit configuration files, sandbox tester accounts, accelerated renewal cycles, and TestFlight rate limits that change throughout the year.

When the same product ships on both stores, you do not get to pick one of these paths. You run both, and you reconcile the differences yourself. A purchase that goes through in the Google Play closed track does not appear in App Store Connect. A StoreKit Transaction that arrives over the iOS testing pipeline does not flow through your Android PurchasesUpdatedListener. Even when the entire app is one Kotlin codebase, you write two @Test annotations, two CI matrices, and two test data setups.

There is also the unit test gap. Google Play does not expose any way to simulate a purchase inside a JVM unit test. StoreKit configuration files run in the iOS simulator, not in kotlinx-coroutines-test. So even before you worry about cross platform reconciliation, you cannot get a working purchase flow inside commonTest at all. The standard advice is to push everything below the SDK boundary into integration tests, which means most teams end up testing only the parts of their code that do not actually touch Purchases.

Look at the CatArticlesDetailViewModel from the cat-paywalls-kmp demo and you can see the shape of the problem:

This class has real business logic. It decides whether to fade an article body, whether to surface a “Join Now” CTA, what to do when the network call fails, and when to recompose. None of that logic depends on whether the underlying receipt came from Google Play or StoreKit. But if PaywallsRepository.fetchCustomerInfo() only emits values when a real billing SDK is connected to a real store, you cannot reach any of this logic from a unit test. The KMP win disappears at exactly the boundary where you most need it back.

The rest of this article is about getting it back.

The Test Store: A sandbox built into RevenueCat itself

The shortest path out of the two sandbox problem is to stop using the two sandboxes for development purchases. RevenueCat’s Test Store is a sandbox built into the platform itself, not into Google Play or the App Store. You configure it once in the dashboard, set a different API key in your app, and the SDK routes every purchase through RevenueCat’s own purchase modal instead of asking the native store to open its dialog.

The modal it shows is small and deliberate. When the user taps “Subscribe” inside the Paywall composable, the SDK overlays a three button sheet: Test valid purchase, Test failed purchase, and Cancel. Tapping the first one is what a successful purchase looks like from your app’s perspective. The SDK marks the receipt valid on the backend, awaitPurchase resumes with a StoreTransaction, the CustomerInfo flow emits a new value with entitlements["premium"].isActive == true, and your gated UI unlocks the same way it would in production. The other two buttons exercise the failure and cancellation paths without you having to fake an exception by hand.

There is no Play Console setup, no App Store Connect tester account, and no license tester opt in URL. The Test Store works in the simulator, the emulator, debug builds on a real device, and CI runners. Auto renewal still happens, just on accelerated cycles: a monthly subscription renews every five minutes, an annual subscription renews every hour, both stop after five renewals so a test session never runs longer than around five hours. Every Test Store purchase shows up in the same RevenueCat dashboard as production data, which means the same CustomerInfo shape, the same webhook payloads, and the same entitlement transitions you ship against.

Two practical rules. First, you need purchases-kmp 2.2.2 or newer for the Test Store path; the cat-paywalls-kmp demo pins 2.10.2+17.55.1. Second, a Test Store key is a debug only artifact. It looks like test_... instead of goog_... or appl_... and is rejected by the server if the SDK is configured against a production project. Treat it the same way you would treat a debug signing key: useful for development, never in a release.

Setting up the Test Store in a KMP project

The whole setup is one extra BuildConfig field on the Android side and one decision in your Application.onCreate about which key to use. iOS does not need a separate change because the same Kotlin code reads the same configuration when the shared module initializes on the Swift side.

Start with the Gradle build. In composeApp/build.gradle.kts, read the Test Store key from local.properties and expose it through buildConfigField. Pulling the key from a local property file (which is already gitignored by Android Studio) keeps it out of source control by default:

Notice the default value of an empty string. If local.properties does not contain revenuecat.test.api.key, the field is still defined and compiles cleanly. That matters for two reasons: release builds pulled from a clean CI checkout do not see the key at all, and any developer who has not opted into the Test Store keeps the regular production path without any source changes.

The local.properties entry on a developer machine is one line:

revenuecat.test.api.key=test_YOUR_KEY_HERE

The key selection happens in CatArticlesApplication, which is the Android entry point for the shared Compose surface. The pattern is “prefer Test Store key when present, fall back to the production key otherwise”:

Two design decisions here are worth pulling out. The first is that the same Purchases.configure call routes either to the Test Store or to production. The KMP SDK does not have a separate “test mode” flag; it picks the backend based on the key prefix and behaves identically otherwise. Your commonMain code never has to ask which backend it is talking to. The second is that this is a debug only ergonomics, not a build flavor. Every developer can flip on Test Store for their personal build by adding one line to their own local.properties, without any branches in the source tree.

The iOS side does not need an analogue. When the Kotlin runtime starts on iOS, it shares the same Purchases.sharedInstance configured by the platform App struct. If you want the iOS app to also use the Test Store during development, configure the same test_... key in the SwiftUI entry point:

Read testStoreApiKey from an .xcconfig, a Info.plist entry, or a build setting. The shape is the same as on Android: take the key from a local source of truth, fall back to a production constant.

The testability boundary: wrapping Purchases behind a repository

Even with the Test Store wired up, you do not want every unit test to depend on a running Purchases.sharedInstance. The SDK assumes a platform context that is not present in commonTest: an Android Context, a BillingClient, an iOS StoreKit transaction listener. The cat-paywalls-kmp demo solves this by funneling every call into the SDK through a single repository interface in core/data:

There are three things to notice about this interface. First, every method returns a Flow<Result<T>> instead of a suspend function. That choice gives StateFlow consumers something to .map and .collect without paying for an extra viewModelScope.launch, and it lets the implementation choose between cold flow semantics and stateIn caching without changing callers. Second, the types in the return positions are all from com.revenuecat.purchases.kmp.models.*. They are pure Kotlin data classes that exist in commonMain, which means a test can construct or hold them without expect/actual gymnastics. Third, there is no platform specific code in the signature, which is what lets the same interface back both androidMain and iosMain consumers.

The production implementation wraps Purchases.sharedInstance with suspendCancellableCoroutine and a small Flow builder. The shape is straightforward:

This is the only place in the entire codebase that imports Purchases.sharedInstance. Every ViewModel, every Compose function, every test is on the other side of the interface. That is the boundary you need to make commonTest viable, because anything above this line can be exercised against a fake.

Unit testing in commonTest: the patterns that work on both platforms

A Kotlin Multiplatform unit test cannot use MockK, Mockito, or any reflection based mocking framework. Those libraries are JVM only. They will compile in commonTest if MockK is on the version catalog, but the iosTest target will fail to link when Kotlin/Native tries to resolve the bytecode generation runtime. The cat-paywalls-kmp demo even declares MockK in gradle/libs.versions.toml and then never uses it, because the moment you adopt the convention plugin that runs commonTest against both targets you cannot import it from shared code.

What does work in commonTest is kotlin-test, kotlinx-coroutines-test, and Turbine. The cat-paywalls-kmp KmpLibraryConventionPlugin wires them into every feature module at the source set level:

The reason this is in a convention plugin and not in each feature module’s build.gradle.kts is that you want this to be free. Every module that hosts a ViewModel or a state holder needs the same test dependencies, and forcing each module to opt in by hand is exactly the kind of friction that ends with someone writing logic they cannot reach from a test. The plugin makes “write a unit test” the default, not a setup task.

A feature module then only declares what is unique to its tests. For feature/subscriptions, the only extra dependency is core/data, because the test uses the real PaywallsRepository interface:

That is the entire test wiring. From here, you can write a class SubscriptionManagementViewModelTest in feature/subscriptions/src/commonTest/kotlin/... and it will be picked up by androidUnitTest and iosTest automatically. One file, both targets.

Why fakes beat mocks for KMP subscription code

With MockK off the table, your options are hand written fakes or expect/actual mock factories. The cat-paywalls-kmp demo picks fakes for every test, and the choice is more deliberate than it looks. Subscription code has two properties that make fakes the better fit even in a JVM only project. First, the surface area of PaywallsRepository is small. Three methods, all returning Flow<Result<T>>. There is nothing to mock that a small data class with a few setters cannot already express. Second, the same fake is reused across many tests with different setup, which makes a stateful builder more readable than a stack of every { ... } returns ... lines.

Here is what the canonical fake from FakePaywallsRepository.kt looks like:

The constructor takes no arguments. The fake starts in a deliberately empty state where every flow emits a “not configured” failure. A test then sets the slots it cares about and leaves the others alone. That asymmetry is the value of fakes over mocks: you do not have to enumerate every method up front, you only describe the scenario you are testing.

The flow methods themselves are one line each, with the empty case routed through a recognisable exception so a misconfigured test fails loudly rather than hanging on an empty flow:

The IllegalStateException here is not for production semantics. It is a test ergonomic. When a future contributor adds a test that calls a method without setting it up, the test fails with a message that names the missing slot, which is much faster to debug than an empty Flow that just never emits.

One limitation to call out. The fake holds and returns Offering and CustomerInfo values, but it does not construct them. Those types come from purchases-kmp and do not currently expose public constructors. That means you can test the failure paths through the fake directly, but a successful “purchase completed and entitlement is now active” assertion has to be exercised against a real Purchases.sharedInstance. That is exactly the seam the Test Store fills, and the next two sections show how.

Writing tests against the fake

A ViewModel test in commonTest looks almost identical to its androidx counterpart. The only differences are the kotlinx.coroutines.test.StandardTestDispatcher instead of TestCoroutineDispatcher, and Turbine instead of LiveData observers. Here is the setup pattern that the cat-paywalls-kmp SubscriptionManagementViewModelTest uses:

Dispatchers.setMain replaces the main dispatcher that viewModelScope uses with the test dispatcher. Without that swap, any StateFlow.stateIn(viewModelScope, ...) would post to the real main thread and the test would hang, because there is no Android main looper in commonTest. Dispatchers.resetMain after each test is the symmetric tear down. Together they give you deterministic scheduling: nothing runs until you ask it to.

The actual test reaches into the fake, instantiates the ViewModel, and asserts on its state through Turbine. The pattern for an error path:

Three details earn their keep here. The first awaitItem() returns the initial Loading value because StateFlow always replays its current state on collection. testDispatcher.scheduler.advanceUntilIdle() then drains every queued coroutine in the test scope, which is what causes the repository’s flow to emit, the ViewModel’s combine chain to run, and the next state to land in the StateFlow. The second awaitItem() picks that state up, and the assertion confirms the error message survives the pipeline.

If you write four or five tests like this, you cover the entire surface of the ViewModel’s state machine. The initial loading state, the offering error path, the customer info error path, the combined error path, and the cancellation path are each one fake setter plus an awaitItem(). None of these tests need a billing client, none of them need a network, and the same suite runs against the JVM target and the iOS target without modification.

What this suite cannot cover is the actual purchase. Because the fake cannot construct an Offering with real packages, you cannot run a test that says “the user taps subscribe, the SDK validates the receipt, and the entitlement flips to active.” For that path you need the Test Store, and the right place for it is an instrumented test on top of the unit suite, not inside it.

Integration testing with the Test Store on Android

The Testing Test Store post on the RevenueCat engineering blog walks through this end to end, and the same approach applies to a CMP project because the Android target compiles down to a normal androidTest source set. Put the integration test in composeApp/src/androidTest/kotlin/.... Configure Purchases once with the Test Store key, launch a small activity that drives a real purchase, and use Espresso to tap one of the three buttons that the Test Store modal presents.

The setup uses InstrumentationRegistry.getInstrumentation().targetContext because the test runs in a real Android process, not in a JVM unit test. The configuration call is the same one your Application makes, but pinned to the Test Store key:

The actual purchase test then resolves the test offering, launches the activity, and waits for the Test Store modal to appear before tapping the “Test valid Purchase” button:

Two things to call out. The delay(2_000) before the Espresso tap exists because the Test Store modal is rendered through the host activity, and Espresso needs the view hierarchy to settle before it can find the button. The 30 second timeout on the assertion accounts for the round trip to the RevenueCat backend that validates the receipt and updates CustomerInfo. Both numbers can be tuned for your CI environment, but they are intentionally generous because the test is doing real network work.

The companion tests are the other two buttons. Tapping “Test failed Purchase” lets you assert that the entitlement stays inactive and the error propagates through your domain layer. Tapping “Cancel” lets you assert that the PurchaseCancelled exception is mapped to a no op rather than surfaced as a user facing error. Three tests, three modal buttons, one Test Store key, no Play Console.

The iOS side: StoreKit configuration files and what the Test Store unifies

On iOS, the equivalent of an instrumented test is a StoreKit configuration file driving an XCUITest. Apple introduced StoreKit configuration files in Xcode 12, and they remain the canonical way to test purchases inside the iOS simulator without setting up a sandbox account. You describe the products in a .storekit file, attach it to a scheme, and run the app under that scheme. Purchases then resolve through the configuration file instead of the App Store backend, and you can use XCUITest to drive the resulting native StoreKit modal.

This works, and for an iOS only app it is often the right answer. In a Compose Multiplatform project, the trade off looks different. The StoreKit configuration file only covers the iOS side. It does not interact with your Android tests, it does not flow data through your PaywallsRepository, and a successful purchase against it does not show up in the RevenueCat dashboard the way a real purchase does. You end up with two parallel integration suites that test the same Kotlin code through two completely different driver layers.

The Test Store collapses this. When the same commonMain code is configured against a Test Store key on both platforms, an iOS purchase goes through the same RevenueCat modal as an Android purchase, the same backend validates the receipt, and the same CustomerInfo flow emits the same shape on both sides. Your iOS integration test can then drive the same three button modal with XCUITest:

The pattern mirrors the Android Espresso test almost line for line. Find the subscribe button, find the “Test valid Purchase” button, wait for the gated content to unlock. The same three Test Store buttons cover the same three scenarios. The same CustomerInfo update unlocks the same composable. You still write two driver layers because the OS testing frameworks are different, but the data plane is shared, the network calls are the same, and the dashboard sees both runs as the same Test Store activity.

For most teams, this is enough. If you also want to exercise the native StoreKit error paths (parental controls blocking a purchase, sandbox account expired, region restrictions), keep a small .storekit based suite for those edge cases. The bulk of your purchase path coverage moves to the Test Store and shrinks the size of the iOS only suite to a handful of platform specific tests.

A three layer testing strategy

Putting it all together, a Compose Multiplatform subscription app has three useful test layers, and each one answers a different question.

The first layer is commonTest unit tests against FakePaywallsRepository. This is where you cover your ViewModel state machine: initial loading, error paths, cancellation handling, derived UI states, and any business logic that lives above the SDK boundary. These tests are fast, deterministic, run on both targets from a single source set, and never touch the network. They are the layer you run on every PR, in pre push hooks, and on every CI build.

The second layer is instrumented tests against the Test Store. On Android this is androidTest with Espresso. On iOS this is XCUITest. Both drive the same RevenueCat purchase modal, both produce real CustomerInfo updates, and both verify the end to end flow from subscribe button to unlocked content. These tests are slower and a little flakier because they include real network calls, but they are the only layer where you can prove that the purchase path works for a real receipt. Run them on merges to main, on release branches, and as part of your release qualification.

The third layer is optional and platform specific. A StoreKit configuration file based suite for iOS edge cases that the Test Store does not model. A Google Play closed track for the rare bugs that only reproduce against the real billing client. Both are valuable, but neither is the workhorse. They exist to plug specific gaps, not to cover the core purchase flow.

The numbers shift the right way too. The unit tests are tens of milliseconds each and run on every commit. The instrumented Test Store tests are seconds each and run on merge. The native edge case suites are minutes each and run on release. Most of your purchase coverage ends up in the layer that runs most often, which is the opposite of what happens when you only have a closedTrack and a StoreKit configuration file.

CI considerations: one matrix, three jobs

The CI shape that falls out of this is straightforward. One job runs commonTest for both targets:

allTests is the umbrella task that Kotlin Multiplatform creates when you have both Android and iOS targets configured. It dispatches to jvmTest, iosX64Test, iosSimulatorArm64Test, and any other target you have enabled. A failure in any one fails the job. Run this on every push, every pull request, and every nightly build.

The second job runs the Test Store instrumented tests on Android. The blog’s CI snippet works as written:

Two practical notes. The Test Store key needs to be available to this job, but not to forks or to release builds. The cleanest way is a repository secret that the job writes to local.properties at the start of the run, so the same buildConfigField pattern picks it up. The job should also run on merges to main and on release branches, not on every PR, because it includes real network calls and consumes Test Store renewals.

The third job runs the iOS XCUITests. A standard xcodebuild test invocation against the same scheme that ships the app, with the Test Store key injected through the same mechanism your local builds use. Both Android and iOS integration jobs read from the same RevenueCat project, which means a single dashboard view shows test activity from both platforms.

The result is a CI surface that mirrors the test layers. Fast feedback from the unit suite on every commit. Slower but realistic feedback from the Test Store suite on merge. The expensive native suites only when you cut a release. None of these jobs require coordinating two sandboxes, and the same PaywallsRepository and ViewModel code is exercised end to end at every layer.

Conclusion

In this article, you’ve worked through a complete subscription testing setup for a Compose Multiplatform app. You configured the RevenueCat Test Store from local.properties and a single buildConfigField, drew the testability boundary at a PaywallsRepository interface so the SDK never leaks into your ViewModels or your tests, wrote commonTest unit tests against a FakePaywallsRepository using kotlin-test, kotlinx-coroutines-test, and Turbine, then layered instrumented tests on top with Espresso on Android and XCUITest on iOS that drive the same three button Test Store modal. The same shared code path is exercised from commonTest all the way through to the receipt validation backend, on both platforms, without two parallel test suites.

The thing worth internalizing is what changed at each layer. Subscription testing usually fragments because the sandboxes do. By moving the development sandbox up into RevenueCat itself, the Test Store turns the two platform problem back into one. By putting a small repository interface between Purchases.sharedInstance and the rest of your app, commonTest becomes a viable home for the bulk of your business logic tests. By using fakes instead of mocks at the unit layer, the same suite runs against both Kotlin targets without expect/actual or a JVM only mocking framework. Each of these choices is small. Together they collapse what used to be two test suites into one.

Whether you are porting an Android subscription app to iOS, starting a new CMP product from scratch, or trying to get purchase testing into CI for the first time, this layered setup gives you the smallest surface area you can ship a cross platform subscription app on with real confidence. The full source for every snippet in this article lives in cat-paywalls-kmp, and a free RevenueCat project with a Test Store key is the only thing you need to run all three layers locally.

Revenge of the brand manager: why ‘pretty’ ads fail at direct response

Mon, 11 May 2026 14:42:25 GMT

There’s a persistent temptation in app growth to make things look beautiful. When a team finally gets budget for creative production, the instinct is to hire a slick agency, shoot in 4K, and write a punchy, conceptual slogan. It feels like real marketing — like you’re finally building a brand.

But when those ads hit the Facebook and Instagram feeds, they often bomb.

I framed this pattern during a recent Sub Club Live as “revenge of the brand manager”. This happens when you optimize for aesthetics rather than addressing the messy, stressful reality your users actually inhabit.

Selling a vibe instead of a solution

Take a recent ad campaign from Granola, a popular AI note-taking app. Granola’s ads were undeniably gorgeous — exactly what a brand manager wants to see on a billboard.

The problem? The ads didn’t speak to the user.

When I look at creative like this, I see an ad made by somebody who hasn’t taken the time or trouble to really understand the world their users inhabit. While it checks a lot of boxes for traditional advertising best practices, in direct response advertising, it doesn’t really speak to what the users are going through.

When a user is scrolling through Instagram or TikTok, a conceptual slogan doesn’t stop them. They don’t care about your brand identity — they care about their own immediate problems. If your ad looks like it was made simply to be beautiful, it registers as an ad. An interruption rather than a solution. As we’ve seen with the shift toward value-first UGC ads, users have developed a profound blindness to anything that feels overly produced or disconnected from their reality.

Designing for the lived experience

If beautiful slogans don’t work, what does? The fix is to root your creative entirely in the user’s lived experience. You have to depict a specific scenario that the user recognizes immediately.

For a note-taking app like Granola, I would suggest focusing on a visceral moment of panic.

Take a specific instance from your user’s life, like a CEO asking what the client said. You freeze. But then you look at this app, and remember your notes. That kind of lived experience ad works much, much better versus a slogan where I don’t even know what the product does for anyone.

This approach works because it leverages the emotion that comes with a solved problem. The user isn’t buying an AI note-taker; they’re buying an escape hatch for when their boss puts them on the spot. By visualizing the panic of the problem and the relief of the solution, the ad earns the click.

Why ‘ugly’ often wins

This reality is often frustrating for founders and designers. As David pointed out during our live session, it is easy to err on the side of polish because we all love the ideal of pristine brand advertising. But in direct response, the ‘ugly’ design — the one that clearly and bluntly states the problem — is frequently what wins the creative testing phase.

When you’re scaling paid user acquisition, you cannot afford to let aesthetic preferences dictate strategy. If you overanalyze your creative through the lens of brand purity, you miss the scrappy, relatable angles that actually drive downloads and trial starts.

So the next time you brief a designer or a creator, ban the conceptual slogans. Ask them to show you the moment your user sweats, and the moment your app makes them breathe a sigh of relief.

About the Author: Shamanth Rao is the founder and CEO of RocketShip HQ, a boutique growth marketing firm with over $100 million in managed spend. He hosts the Mobile User Acquisition Show, where he’s launched Intelligent Artifice, a deep dive on how AI is transforming performance marketing.

Meet the subscription app pre-mortem: how to plan for failure before you ship

Fri, 08 May 2026 10:45:34 GMT

When I started out in the app industry, I worked at a growth agency that partnered with a development agency. As a result, a lot of our projects involved launching entirely new websites or app redesigns.

It was amazing — a fresh slate to use all our customer insights and improve performance! …But also slightly terrifying. Not because of the work itself, but because of the waiting.

That horrible in-between phase after you’ve shipped something, where you’re refreshing dashboards, overanalyzing early feedback, and catastrophizing every dip in the numbers.

What helped me wasn’t positive thinking. It was the opposite: leaning into pessimism.

Deliberately imagining everything that could go wrong before launch. Thinking through every possible scenario. Having the trickiest, most uncomfortable conversations with clients and teams to explore all the what-ifs.

It’s called a pre-mortem. (A bit morbid, but it works.)

Since then, I’ve used it for everything from website redesigns to subscription app launches; especially in products where feedback loops are fast and the stakes compound quickly.

And it’s become one of my favorite planning tools.

What is a pre-mortem?

A regular post-mortem happens after something fails, the classic sprint retrospective. You gather the team, ask not only ‘what went right’ but also ‘what went wrong’ or ‘what could have gone better’, and try to learn from it.

It often comes with a few cringe-inducing “we could have predicted that” moments, where Captain Hindsight suddenly looks like a genius.

The problem is, it’s reactive rather than proactive. You’re analyzing what went wrong after the fact, but it doesn’t change the outcome.

A pre-mortem flips that. The concept is simple: before you launch, imagine it’s three months later, and the launch has completely flopped. Really put yourselves in that moment: the disappointment, the stress, and the why-is-this-happening panic. Bring it to life.

Then ask the full team: why did it fail?

I called it pessimistic, but honestly, it’s not. It only becomes pessimistic if you assume failure is inevitable and stop there. The real goal is to surface risks while you can still do something about them.

If anything, it’s more realistic — and even optimistic — because it assumes you can fix and prevent those risks.

And the interesting part? The things that come up in a pre-mortem are rarely surprising. They’re usually the things everyone already half-knows but hasn’t said out loud.

Who came up with such a morbid concept?

The credit goes to Gary Klein and his often-cited Harvard Business Review article from 2007. But Gary (and yes, given how much I love this concept, we’re absolutely on a first-name basis) had been using the method for a good 30 years before that. He first developed it in the early 90s, so no one needs to do confusing maths back from 2007.

A psychologist by trade, he was fascinated by how people make decisions under pressure and uncertainty. He studied this in one of the most high-stakes environments imaginable: the US Air Force. Later, he developed the idea of pre-mortems further within his own research company, drawing not only on that work but also on medical post-mortems.

What Gary understood — and what more of us need to recognize — is the flawed reality of group decision-making. We’re wired for harmony. We want to get along. No one wants to be the negative Nancy, pointing out risks or poking holes in a plan.

I recently emailed a client outlining all the risks in their current target-setting model and ended with, “sorry, this is a bit negative…”. I felt bad raising those risks, but I also knew, from experience, what happens when you don’t. When you let people believe targets are promises rather than stretch goals. Still, it sucks to be the one to say it. That’s exactly the tension Gary Klein was trying to solve. A pre-mortem removes the pressure to keep up a ‘rah-rah, everything is great!’ mindset.

Instead, it creates a space where calling out risks isn’t awkward; it’s expected.

Since then, the concept has taken off. You’ll find pre-mortems everywhere now: in startups, corporate boardrooms, and even back in the military (a full-circle moment, really).

Daniel Kahneman — who many people know from his book Thinking, Fast and Slow — even called it his single most valuable decision-making technique. Not bad for something that started as an internal fix at a small research company.

Gary later expanded on the idea with what he calls the ‘double-barreled pre-mortem’. After imagining failure, you run a second round where you daydream about wild success — and what could go wrong there, too.

It sounds more optimistic, but the goal is the same: surface risks. Even success can break things. If only Ticketmaster had done that before the Taylor Swift Eras Tour ticket sales…

So that’s how, and why, pre-mortems started. But beyond making it easier to speak up, why else is this tactic so useful?

Why do pre-mortems actually help?

There are five reasons why pre-mortems are so powerful:

1. They make you a better fortune teller

Pre-mortems use a technique known as prospective hindsight (a fancy way of saying imagining the future), which Deborah Mitchell at Wharton found can increase your ability to correctly identify reasons for future outcomes by 30%. All that by pretending it has happened. You basically become a better fortune teller, pretty cool, right?

So it helps you surface real potential risks more effectively than just thinking about them without a specific prompt.

2. It creates psychological safety to talk about risks

We’ve talked a bit about this already. By making the goal ‘identify risks’, you make it safe to say them out loud. People are often all thinking “the founder keeps changing priorities” or “pretty sure this plan was ChatGPT and hasn’t been checked”, but they might be too scared to say it out loud.

As you see others be more open, you’ll also end up being more open.

I think this is especially valuable when you have a room full of young, smart people. I remember at my first job, I assumed whatever senior leadership said was the right call. It felt intimidating to challenge someone with 20 years more experience than me.

Now, as a leader, I know you can tell people to speak up — but the reality is, not everyone will. A pre-mortem helps level that playing field. It gives people permission, and a clear prompt, to question assumptions, raise concerns, and say the thing they might otherwise keep to themselves.

3. It makes the fear concrete

Vague anxiety is paralyzing; we’ve all catastrophized over endless, nameless what-ifs. Specific risks, though, are manageable.

Once you’ve written “what if no one buys it?” on paper and mapped out a plan for it, it stops being a powerful fear. It becomes just another scenario to handle.

Even better, involving the whole team in a pre-mortem helps counteract the planning fallacy — that tendency to be overly optimistic, assume everything will work out, and underestimate time, costs, and risks. By making the risks concrete, you can create a clear action plan.

Think of it as a bit of growth group therapy.

4. It removes panic from decision-making

Have you ever stood in line for coffee, and suddenly it’s your turn way faster than you expected? The barista asks, “What would you like?” and you stammer out, “Um… errr, a vanilla matcha latte, wait, an iced vanilla matcha latte!” Only to take a sip and think, “What was I thinking?”

Okay, that might have just been my own therapy moment the other day, but the point stands: under pressure, we’re terrible at making decisions on the spot.

The same goes for post-launch problems — you’re stressed, stakeholders are asking questions; you’re tempted to make snap, reactive decisions. You blurt out the first thing that comes to mind, and hope for the best.

A pre-mortem changes that. If you’ve already decided, ‘If X happens, we do Y’, then you don’t have to think under pressure. You execute the plan. You’ve already discussed the right course of action as a team, ahead of time. I do this for every experiment I run because it makes ‘failed’ experiments easier to handle: we know what failure looks like, we can learn from it, and we already have a sense of what to test next.

5. It gives you permission to take action imperfectly

I once worked with a Head of Product who was basically a pre-mortem specialist, though he probably didn’t realize it, since we’d never talked about pre-mortems. He had an uncanny ability to spot every possible risk, think it through, and tackle it. Sometimes, it felt frustrating, as it could slow projects down. Until I realized that if I named the risk and laid out a plan, he was more than happy to roll with imperfection.

The extreme opposite of optimism in project planning isn’t pessimism, it’s perfectionism. Try to control everything, and you’ll never go live.

A pre-mortem shows you that even if things go wrong, you have a path forward. That makes it easier to ship. The goal isn’t to prevent every risk, it’s to be conscious of which risks you’re willing to accept and which you aren’t.

By now, hopefully, you’re convinced and starting to wonder how to run your own pre-mortem.

How to run a pre-mortem

While the concept itself is simple, a few small tweaks in setup and approach can make your pre-mortem far more powerful.

Step 1: Gather the relevant individuals

While you can do a pre-mortem alone, I can’t recommend doing it with your team enough. Different people spot different risks based on their expertise, and hearing others’ perspectives can reveal risks you might never have considered.

Even better: bring in someone outside the project; someone who won’t have rose-tinted glasses. Ideally, a classic naysayer who can look critically at what’s being assessed (kind of like that Head of Product I once worked with).

Step 2: Set the scene

Next, set the scene.

Say something like: “It’s [date 2–3 months from now]. This launch has failed. Not a minor disappointment, but a proper flop. What happened?”

Pick a timeframe that feels realistic for the project. Then lean into the drama — think back to high school theater class and really bring it to life. The goal is to make it feel real, to transport yourself to that future moment, and look back with hindsight.

You can even get creative: have AI mock up a founder email, a critical internal memo, or an article in a relevant newspaper or magazine. The more tangible and vivid the scenario, the easier it is to uncover the real risks.

Step 3: List every reason it might have failed

Have everyone list reasons separately. Write down everything, even if they seem unlikely. For example:

We couldn’t reach enough of our target audience
The trial-to-paid conversion rate is too low
We saw very high initial churn
We struggled to get downloads
The price felt wrong (too high, too low, confusing)
A competitor launched something similar at the same time
We got bad press or reviews early on
The team burned out before we could iterate

The more specific, the better. We aren’t aiming for perfection here; quantity over quality is the key at this stage. The goal is to surface as many potential risks as possible.

Step 4: Go through the risks and group them by theme

There will inevitably be some overlap in the concerns people raise. That’s okay, this is a no-judgment moment. At this stage, you’re not prioritizing; you’re organizing.

Give everyone a chance to voice their concerns. Whatever you do, don’t try to diminish them or explain why something won’t happen, especially if you’re the leader or founder.

Instead, focus on grouping the concerns by theme. This helps you see more clearly:

Which concerns are the most common
Which areas seem to carry the most potential risks

Optional additional step: When pre-mortems require a culture change

In some companies, getting into the pre-mortem mindset can be tricky. When things are busy or deadlines are tight, it’s easy to skip it. Or sometimes, people just feel uncomfortable bringing up the uncomfortable.

Here, the framework Shreyas Doshi suggests can be really useful. He recommends categorizing risks into three types:

Tiger: a real threat — something that will hurt the company if left unaddressed.
Paper tiger: a perceived risk/threat that, on closer inspection, is unlikely to cause real problems. These are the things the team might be stressing over, but are actually minor and manageable.
Elephant: unsurprisingly, this is ‘the elephant in the room’ — a risk that is present but isn’t being talked about.

Using this playful, visual language helps build the psychological safety that’s so important for effective pre-mortems. It makes discussions lighter and more approachable, and it gives you a way to raise risks in other settings too. For example: “This might be a paper tiger, but have we considered…?”

Step 5: For each risk theme, ask two questions

Now that you’ve done some idea spring cleaning, it’s time to assess risk levels and impact:

Certainty assessment: how likely is it to happen?
Impact assessment: how bad is it if it happens?

This helps you map everything onto a simple 2×2 grid, so you don’t get stuck debating unlikely scenarios or low-impact risks. Instead, you can focus your energy on the ones that actually matter.

Depending on the size of the group and the scope of the project, this might even be a separate session. The goal here isn’t to solve everything yet; it’s to start identifying which risks deserve your attention first.

Step 6: Determine whether you need to plan or prevent those risks

Next, focus on those biggest risks and decide whether they’re preventable, plannable, or both:

Prevent: can we reduce the likelihood of this happening?
Plan: if it happens anyway, what will we do?

If you try to prevent every single risk, nothing will ever go live, so this is where you need to be critical. Ask yourself: Is this something we can realistically mitigate, or is it a risk we need to consciously accept?

The goal isn’t to eliminate all risk. It’s to understand it and feel prepared for what might happen.

Step 7: Work out potential solutions

Now, depending on the complexity of the risk, this might require an extra session — or a few — to properly think through. Don’t get caught trying to solve everything on the spot. Some risks need deeper brainstorming or input from others.

What does help is summarizing your plans into simple if/then statements. They’re clear, practical, and bring a sense of calm to the unknown.

For example:

If activation is below 10%, we’ll simplify the first-time experience and retest
If we attract the wrong customers, we’ll adjust our targeting and messaging before scaling spend
If nobody hits the paywall, we’ll move it earlier and test different copy
If day 1 churn is above X%, we’ll investigate whether the paywall is creating impulse conversions

Each of these should be tied to a specific metric you’re already tracking — trial conversion rate, activation rate, churn, and MRR. Set your trigger thresholds before launch, so you’re not debating what ‘bad’ looks like after the fact.

If you’re running paywall or pricing experiments, RevenueCat’s Experiments feature lets you set up A/B tests and define success metrics before you launch — so you’re not making decisions under pressure.

Step 8: Review and revisit

One last thing: don’t let your pre-mortem gather dust in a shared doc like so many other strategy decks. Depending on your timelines, set a few clear check-in points, for example, Day 7, Day 30, and Day 90 post-launch.

At each one, revisit your if/then statements and ask: are any of these scenarios actually playing out?

This is where the pre-mortem really earns its keep. The planning is valuable, but the follow-through is what helps you avoid those “we should have seen that coming” moments later on.

For longer projects, it can even be worth running a second pre-mortem closer to launch; a fresh look, with more context, often surfaces new risks you couldn’t see earlier.

Example: subscription app pre-mortem

Before launching a new subscription tier for a client last year, we ran a quick pre-mortem.

One of the risks we identified: ‘Existing customers might feel cheated if new customers get a better deal’.

We couldn’t fully prevent that. The new tier genuinely offered better value, and it needed to. It unlocked a segment of customers we were previously pricing out. But by naming the risk, we could prepare for it:

We spent more time positioning the existing tier, not just promoting the new one
We added a relevant feature to the higher tier to reduce cannibalization
We communicated proactively with existing customers, explaining the new tier and who it was for
We prepared responses for the support team

The result? Far fewer complaints than expected, and only a small increase in support tickets (mostly from customers who missed the updates).

More importantly, the new tier drove growth rather than cannibalizing the existing one, with overall MRR increasing significantly.

When to use pre-mortems

Pre-mortems work in a wide range of scenarios:

Launching a new product or SKU
Changes to subscription models
Pricing adjustments
Entering a new market or channel
Rebrands or major website overhauls
Paid campaign pushes

I even run them with new advisory clients to make sure I can support them effectively and drive real impact.

Basically, try a pre-mortem anytime failure would hurt, and you want to have thought it through in advance.

A pre-mortem won’t make launches less scary

You’ll probably still refresh dashboards too often and overanalyze early data — I certainly do.

But the quality of your anxiety changes. Instead of a vague dread that something might go wrong, you have a clear list of what could go wrong, and a plan for each scenario.

The best launches I’ve been part of weren’t the ones where nothing went wrong. They were the ones where we’d already talked through what we’d do if things did go wrong.

So before your next paywall test, pricing change, or new tier launch, take 30 minutes with your team. Imagine the worst, write it down, make a plan.

Then ship it anyway.

A complete guide to migrating from Google Play Billing v7 to v8 (and preparing for v9)

Fri, 08 May 2026 00:41:42 GMT

Every Android subscription team lives on the same two year clock. The Play Billing Library you shipped with last year is on a deprecation timer, and the Play Console will refuse new uploads the moment the timer runs out. v7 is the next version to hit that wall. After August 31, 2026, you can no longer publish a new app or update built against v7, and v8 has been generally available since June 30, 2025 with significant additions still arriving in v8.1 through v8.3. This guide walks you through the migration end to end, then sets you up for v9.

In this article, you’ll explore the v7 to v8 deprecation timeline and what each date actually means, the full list of removed APIs and their replacements, a step by step migration of the connection, query, and purchase flows, the new behaviors v8 adds that are worth adopting today, what v8.1 through v8.3 layer on top, and how to prepare for v9 before Google publishes a single line of its API surface.

The deprecation timeline that sets your deadline

Google has run a two year deprecation cycle for the Play Billing Library across several major versions. Every major version gets two years of support after release, then the Play Console stops accepting new builds compiled against it. The deprecation FAQ publishes the exact dates:

Library version	Last date for new apps and updates	Extension request deadline
5.x	2024-08-31	2024-11-01
6.x	2025-08-31	2025-11-01
7.x	2026-08-31	2026-11-01
8.x	2027-08-31	2027-11-01

The phrasing in the FAQ is precise and worth reading carefully: “This deprecation prevents only new apps and updates from using older versions of the Play Billing Library. Existing apps that use a deprecated version of the library will continue to function as expected.”

That distinction matters. The deadline is a publishing gate, not a runtime kill switch. Already published v7 binaries keep transacting after August 31, 2026. What stops is your ability to ship a new release. If your app receives any updates at all, including security patches and bug fixes, you need to be on v8 before that gate closes. The extension request deadline of November 1, 2026 is for teams that need to file a formal request through the Play Console to keep shipping v7 builds for a brief additional window. It is not a free extension you receive automatically.

The Play Console signals this through a warning and an inbox message on the Policy status page once your app is on a deprecated version. If your AndroidManifest.xml does not contain the entry named com.google.android.play.billingclient.version, the Play Console cannot detect your library version, and the warning never reaches you. That entry is added automatically by the library, but manifest merging in multi module projects sometimes drops it. Verify it exists in your final merged manifest before you trust the absence of warnings.

What changed in v8: the removals at a glance

v8 removed several APIs that had been deprecated for one or two prior versions. If your code still uses any of these, the v8 upgrade will fail to compile until you replace them.

Removed API	Replacement
`querySkuDetailsAsync()`	`queryProductDetailsAsync(QueryProductDetailsParams, ProductDetailsResponseListener)`
`queryPurchaseHistoryAsync()` (all overloads)	No direct client API. Track history server side.
`enablePendingPurchases()` (no arg)	`enablePendingPurchases(PendingPurchasesParams)`
`queryPurchasesAsync(String skuType, PurchasesResponseListener)`	`queryPurchasesAsync(QueryPurchasesParams, PurchasesResponseListener)`
`BillingClient.Builder.enableAlternativeBilling()`	`enableUserChoiceBilling(UserChoiceBillingListener)`
`AlternativeBillingListener`	`UserChoiceBillingListener`
`AlternativeChoiceDetails`	`UserChoiceDetails`

The signature of ProductDetailsResponseListener.onProductDetailsResponse() also changed. The callback now returns a QueryProductDetailsResult that splits the response into a fetched list and an unfetched list with per product status codes, replacing the older single list signature. Any class that implements this listener has to be updated, even if the rest of its logic is unchanged.

Two terminology changes accompany the API removals. “In app items” are now called “one time products” throughout the documentation and the API surface. The class names themselves did not change, the documentation simply uses the new term, but the rename carries a behavioral implication: one time products in v8 can have multiple purchase options and offers, the same way subscriptions did in v7.

Step 1: Bump the dependency and your minSdk

The first change is the Gradle coordinate. v8.0.0 was the first release in the v8 line, but most teams should target the latest patch in the v8 series instead of pinning to 8.0.0:

The library raised its minSdkVersion to 23 starting at v8.1.0. If your app still supports API 21 or 22, you have two choices: pin to 8.0.0, which keeps the original v7 minSdk of 21, or raise your own minSdk to 23 and adopt the latest v8 patch. The latter is the right call for almost every team, since API 23 was released in 2015 and the device tail below it has been negligible for years. v8.1 is also built against Kotlin 2.2.0, which can affect projects on older Kotlin versions if you consume the billing-ktx artifact, though this is a small jump for any project already on a recent Kotlin Compose stack.

Step 2: Migrate enablePendingPurchases

The no argument enablePendingPurchases() was deprecated in v7 and removed in v8. It used to be a single method that turned on pending purchase support for in app items implicitly. v8 replaces it with a builder that forces you to declare which product categories you want pending support for.

In v7, you had:

In v8, the equivalent call is:

Notice that .enableOneTimeProducts() is not implicit. The deprecated zero argument version was, by Google’s own description, equivalent to a builder with .enableOneTimeProducts() set, so if you do not include this call you will silently lose pending purchase support for one time products. That regression is invisible in unit tests and in most countries with credit card based purchase flows. It surfaces as broken purchases in markets where users pay with cash at convenience stores or with bank transfers, primarily Japan, Germany, Brazil, Mexico, and Indonesia. Add .enableOneTimeProducts() even if you think you do not need it.

If you sell prepaid subscription top ups, also add .enablePrepaidPlans() to the builder. This was added in v7 specifically for prepaid plan pending transactions and carries over into v8 unchanged.

Step 3: Update queryProductDetailsAsync to the new callback shape

queryProductDetailsAsync itself is not removed, but its callback was. The pre v8 listener received a BillingResult and a List<ProductDetails>. The v8 listener receives a BillingResult and a QueryProductDetailsResult that splits products into two lists. Any product that failed to fetch shows up in the unfetched list with its own status code, instead of being silently dropped.

The pre v8 callback looked like this:

The v8 version exposes both the successful fetches and the failures:

The reason this matters is that pre v8, if you queried five products and one of them was misconfigured in the Play Console, the whole call could return successfully with that product silently missing from the list. Your paywall would render four products and you would have no idea the fifth was even attempted. The new shape makes the partial failure explicit. Each unfetched entry carries a status code that tells you whether the product is unavailable in the user’s country, has not yet been published, or hit a transient error.

This is also the moment to rebuild any abstraction layer that wraps queryProductDetailsAsync in a coroutine or flow. The return type of your suspending wrapper has to change from List<ProductDetails> to a sealed class or pair that carries the unfetched information forward. If you have a typealias for the listener type itself, the typealias has to be updated, since the lambda signature is different.

Step 4: Replace the deprecated queryPurchasesAsync overload

v8 removed the overload of queryPurchasesAsync that took a raw SKU type string. The replacement uses a QueryPurchasesParams builder that wraps the same product type with the new typed enum.

Before:

After:

The behavior is identical when invoked correctly. The SkuType constants are gone, replaced by ProductType.SUBS and ProductType.INAPP. If you have a single shared method that accepts a string for the SKU type, refactor it to accept a String that matches the new enum values, or convert it to use BillingClient.ProductType directly.

Step 5: queryPurchaseHistoryAsync has no client side replacement

queryPurchaseHistoryAsync was deprecated in v7 and fully removed in v8. There is no equivalent client API. This is the only v8 removal that does not have a direct one to one replacement, and it tends to surprise teams the most.

Google’s reasoning is straightforward, even if undocumented in the migration page itself: purchase history is not authoritative source of truth on the client. Any history a client builds up can be incomplete, since the device may have been offline during a refund or revocation. The Play Developer API on your server has the authoritative record, and any analytics, audit, or reconciliation flow that depends on knowing past purchases should query it server side instead.

If you previously used queryPurchaseHistoryAsync for one of these reasons, you now have two paths. The first is to call the Play Developer API endpoint purchases.subscriptionsv2.get from your backend whenever you need to inspect a subscription’s full history, including its linkedPurchaseToken chain. The second is to lean on Real Time Developer Notifications and persist the events as they arrive, building your own purchase history table. Most teams already do the latter for analytics and revenue reporting, in which case the v8 removal is a no op.

If you used queryPurchaseHistoryAsync for entitlement restoration on a fresh install or after a reinstall, switch to queryPurchasesAsync with the new params builder. queryPurchasesAsync returns active purchases tied to the current Google account, which is what restoration actually needs. Active purchases is a smaller set than full history, but it is the correct set for entitlement granting. Note that v8 also stops returning consumed one time products and expired subscriptions from queryPurchasesAsync, so configure your one time products as non consumable in the Play Console if you need them to survive a reinstall.

Step 6: Move from alternative billing to user choice billing

v7 already deprecated the enableAlternativeBilling builder method, and v8 removed it entirely. The replacement is enableUserChoiceBilling, which takes a UserChoiceBillingListener instead of an AlternativeBillingListener and exposes a UserChoiceDetails payload instead of AlternativeChoiceDetails.

The functional contract is the same: when the user picks your billing system over Google Play’s at checkout, the listener fires with the purchase details so your backend can complete the transaction outside of Google Play’s payment flow. Only the type names changed. If you carry a per region build flavor where user choice billing is enabled in some regions and disabled in others, the build flavor logic does not need to change, only the type references.

One time products and the multi offer surface

v8 renamed in app items to one time products and gave them the same multi offer capability subscriptions had since v5. A single one time product can now carry multiple purchase options, each with its own price, regional availability, and offers attached. This is the change that motivates the bulk of v8’s surface, and it is also the reason the unfetched product list now exists. With multiple offers per product, the partial failure modes multiplied, and a flat list could no longer represent what happened.

The class names did not change. ProductDetails is still ProductDetails. What changed is the oneTimePurchaseOfferDetails accessor, which can now expose multiple offers and pre-order details starting at v8.1.0. If your paywall renders a single price for an in app item, you are still on the v7 mental model. v8 lets you expose a discounted offer or a regional offer on the same product without creating a duplicate SKU. This is opt in: existing one time products continue to surface a single offer until you configure additional options in the Play Console.

New behaviors worth adopting in v8

Two of v8’s additions are not strictly required but are worth turning on at migration time, since they reduce code you would otherwise carry yourself.

The first is enableAutoServiceReconnection(). The Play Billing service can disconnect for a number of reasons: the user installs an update to Google Play, the device wakes from a long sleep, the system reclaims the bound service. Pre v8, you had to implement onBillingServiceDisconnected() and call startConnection() again with appropriate backoff. v8 ships an opt in builder method that handles this for you:

When auto reconnection is enabled, your onBillingServiceDisconnected() override can be a no op, and the library handles retry with backoff internally. Auto reconnection is opt in rather than the default. If you want to manage connection lifecycle yourself, leave it disabled and continue handling onBillingServiceDisconnected() directly.

The second addition is BillingResult.subResponseCode. Pre v8, the BillingResult returned for purchase failures grouped many cases under BILLING_UNAVAILABLE or ERROR. v8 adds a sub response code on BillingResult that distinguishes specific failure cases:

PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS: the user’s payment method does not have sufficient funds.
USER_INELIGIBLE: the user is not eligible for the offer they tried to redeem, typically because they have already used a one time intro offer.
NO_APPLICABLE_SUB_RESPONSE_CODE: the failure does not map to a more specific sub code.

The ineligibility code is the one you almost certainly want to handle, because it lets you steer the user back to a fallback offer instead of leaving them at a failed purchase screen. The sub code arrives in the BillingResult delivered to your PurchasesUpdatedListener.onPurchasesUpdated callback:

What v8.1, v8.2, and v8.3 add on top

v8 has been moving fast since GA. Three minor releases between November and December 2025 added significant capabilities that are easy to miss if you only read the v8.0 migration guide.

v8.1.0, released November 6, 2025, introduced suspended subscription handling. A subscription enters the suspended state when Google detects abuse or a payment dispute and pauses delivery of entitlements without canceling the subscription. Pre v8.1, suspended subscriptions were invisible to client side queries. v8.1 adds an isSuspended flag on Purchase and a parameter to queryPurchasesAsync to include suspended purchases in the result. The pattern is to filter purchases by isSuspended before granting entitlement, and route suspended ones into a separate UI branch that explains the hold to the user:

v8.1 also reworks subscription replacement. The old SubscriptionUpdateParams.setSubscriptionReplacementMode() is now deprecated in favor of SubscriptionProductReplacementParams set on the per product builder. The new shape supports a KEEP_EXISTING replacement mode that lets you upsell a second subscription on the same account without canceling the existing one, which is useful for bundled offerings.

v8.2.0 and v8.2.1, released in December 2025, generalize what used to be the External Offers Program into a broader Billing Program surface. The old methods (enableExternalOffer, isExternalOfferAvailableAsync, createExternalOfferReportingDetailsAsync, showExternalOfferInformationDialog) are deprecated and replaced by enableBillingProgram(int), isBillingProgramAvailableAsync, createBillingProgramReportingDetailsAsync, and launchExternalLink. v8.3.0, shipped December 23, 2025, adds the developer provided billing flow on top, with BillingProgram.EXTERNAL_PAYMENTS, EnableBillingProgramParams, and DeveloperBillingOptionParams. This consolidation is Google’s response to the regulatory pressure that emerged from the Epic Games ruling and similar requirements in other jurisdictions, where Google is required to support developer provided billing and out of app payment links.

If your app uses the External Offers Program today, the deprecation is a clear signal to start migrating. The methods still work in v8.2 and v8.3, but they will likely be removed in v9. Migrating to the Billing Program surface now is a one time cost that buys you out of a forced migration later.

Preparing for v9 before its API surface exists

At the moment, the release notes top out at v8.3.0. The deprecation FAQ does not list a v9 row. There is no public alpha, beta, or release candidate. So how do you prepare?

By understanding the cadence and the direction of change. Google has shipped a new major version of the Play Billing Library roughly once a year, with v7 released in May 2024 and v8 reaching GA on June 30, 2025. On that pattern, v9 is expected to land in mid 2027, lining up with the v8 sunset deadline of August 31, 2027.

The direction of change is also predictable from the rapid v8.1 through v8.3 releases. Google is consolidating the external billing surface (External Offers Program, user choice billing, developer provided billing) into a unified Billing Programs API. v9 is likely to remove the deprecated External Offers methods, formalize the Billing Programs surface, and possibly extend it further to handle additional regulatory regimes.

Three things you can do today to be ready:

Opt in early: adopt every opt in API v8 ships, including enableAutoServiceReconnection() and the new SubscriptionProductReplacementParams. The opt in surface in one major version is the default surface in the next.
Migrate off External Offers: the Billing Programs surface in v8.2 and v8.3 is the forward path, and it gives you a non breaking migration window before v9 forces it.
Move history server side: v8 removed queryPurchaseHistoryAsync for a reason, and v9 will not reintroduce it. Build your purchase audit trail server side from RTDN events and the Play Developer API.

If you do these three things in your v8 migration, the v9 migration in mid 2027 becomes incremental rather than disruptive.

How RevenueCat absorbs the v7 to v8 transition

The recurring nature of Play Billing Library migrations is the kind of work that taxes a small team disproportionately. Every two years, someone has to read the migration guide, refactor the connection layer, retest pending purchases in cash payment markets, audit the queryPurchaseHistoryAsync removal, and verify that no listener signature change broke a downstream module. The work is rarely interesting, and it always lands on the team that least wants to do it.

RevenueCat absorbs this migration on your behalf. The RevenueCat Android SDK 9.x ships with Play Billing Library 8 already integrated, and the SDK API surface most apps interact with did not change between RC SDK 8.x and 9.x. The only meaningful changes for app code are a Kotlin minimum of 1.8.0 and the removal of data class modifiers from a handful of public types, which means copy() and component destructuring no longer work on those types. equals() and hashCode() are preserved. The migration path is documented in the RevenueCat 8.x to 9.x Android migration guide, and the rationale and feature set are walked through in the Play Billing Library 8 support in Purchases SDK v9.0.0 engineering post.

The practical implication is that the v7 to v8 migration steps in this article reduce to: bump your RevenueCat SDK from 8.x to 9.x, bump your Kotlin to 1.8 or later, replace any copy() or destructuring on the affected RC types with explicit constructors, and verify your one time products are configured as non consumables in the RevenueCat dashboard (since v8 cannot query consumed one time products). That is the entire migration. The v8 specific work, including the new PendingPurchasesParams builder, the queryProductDetailsAsync callback shape, the queryPurchasesAsync overload swap, the user choice billing rename, and the unfetched product handling, is already done inside the SDK.

The same property holds for v9. When v9 ships, RevenueCat will release a new SDK that integrates it, and your app code moves forward with the same pattern: bump the SDK, possibly bump your Kotlin or minSdk, and run your test suite. The recurring Play Billing Library migration stops being something your team has to schedule.

Conclusion

In this article, you’ve explored the full v7 to v8 migration: the deprecation timeline that sets your August 31, 2026 deadline, the removed APIs and their replacements, the six concrete migration steps from Gradle bump through user choice billing, the new behaviors v8 ships with enableAutoServiceReconnection and BillingResult.subResponseCode, the three minor releases that added suspended subscriptions and the unified Billing Programs surface, and a pattern based read on what v9 will likely require.

Understanding the structural reasons behind each removal helps you make better decisions during the migration itself. queryPurchaseHistoryAsync is gone because purchase history was never authoritative on the client. The new enablePendingPurchases builder is explicit because the implicit version silently regressed cash payment flows in some markets. The unfetched product list exists because partial failures had to become visible once one time products gained multiple offers. Each change reflects a problem the prior surface failed to handle, and the v9 changes will follow the same logic.

Whether you’re migrating to v8 this quarter, planning the v9 transition for 2027, or evaluating whether to outsource billing infrastructure to a platform like RevenueCat, this foundation lets you ship Android subscriptions without losing weeks every two years to a forced upgrade. For the official source material, refer to Google’s migrating to Play Billing Library 8 page, the deprecation FAQ, and the release notes.

Meet Rico: Your tireless app growth advisor

Wed, 06 May 2026 16:35:37 GMT

You’ve got the charts. You’ve got the cohorts. You’ve got the experiment results. But somewhere between the data and your next decision, there’s a question you’re not sure how to answer.

Meet Rico, RevenueCat’s app growth advisor built directly into your RevenueCat dashboard and available in Slack. Ask why conversions dropped, which experiment to run, or how your churn rate compares to similar apps. Rico turns your RevenueCat data into your next move.

An advisor, not a search bar

Rico is an embedded domain expert with access to your RevenueCat data, the App Store and Google Play Billing Library documentation, and the industry-wide State of Subscription Apps (SOSA) benchmarks.

Not only can you ask Rico straightforward questions like “show me MRR by country” or “compare this month’s performance vs last month,” you can ask Rico real, business-outcome questions:

“Where am I leaving money on the table in the trial-to-paid flow?”
“Based on the A/B test, should we do a 0 vs 7-day trial next?”
“What is the average conversion to paying for a fitness app?”

What Rico can do for you

Rico’s capabilities span across data analysis, technical debugging, and growth strategy. Here is what your new advisor can do:

Diagnose revenue and retention

“Why did MRR drop in Germany last week?”

Rico can pull your overview metrics, fetch chart data with complex filters, and compare periods to spot anomalies. If revenue drops, Rico can surface exactly which cohort, country, or product is driving the change.

Review product and entitlement setups

“Is my annual product configured correctly in the App Store?”

App Store and Google Play configurations are notoriously easy to get wrong. Rico can review your products, entitlements, offerings, and packages to verify that everything is attached correctly and properly configured in the stores.

Analyze experiments and strategy

“Based on the A/B test, should we do a 0 vs 7-day trial next?”

Rico lists your A/B test results and helps you interpret the winners and losers. It can provide paywall and pricing strategy recommendations, trial optimization advice, and retention analysis.

Benchmark against the industry

“How does my app’s trial conversion compare to similar apps in my category?”

Rico has a dedicated benchmarks tool that compares your project’s actual metrics against industry peers. Ask how your trial conversion, churn rate, or MRR growth stacks up against apps in your category. Rico surfaces where you’re ahead, where you’re behind, and what to test next, using data from the SOSA reports.

Deep-dive into customers

“Look up user abc123: they say they paid but don’t have access.”

When a user writes in with a billing issue, give Rico their app user ID. Rico pulls their full profile: active entitlements, subscription status, purchase history, and any custom attributes your app has set.

Then Rico tells you what it sees. Is the subscription in billing retry? Did they cancel but still have access? Have they been refunded before? Are they enrolled in an experiment that might explain unexpected behavior? For most support tickets, that’s enough to diagnose the issue and respond with confidence.

Research documentation and SDKs

“How do I implement a custom paywall in React Native?”

Rico has full access to the RevenueCat docs and all open-source SDK repositories across iOS, Android, Flutter, React Native, Unity, KMP, and JS. Ask about an implementation detail and Rico finds the exact code snippet or proven approach. Ask about a recent SDK release and Rico pulls the changelog. If something seems broken, Rico can check the live status of RevenueCat’s API.

Learn from the best in the industry

“What do high-retention apps do differently in their first 30 days?”

Rico can search the RevenueCat blog and pull insights from the SubClub podcast. Hundreds of conversations with the founders and operators who have built the most successful subscription apps. Ask Rico what high-retention apps do differently, how apps in your category structure their trial strategy, or what operators have figured out about reducing involuntary churn.

Project and team management

“Who changed the annual product entitlement yesterday?”

Rico can list your apps, API keys, and collaborators, and pull your project’s audit log. Every entry records who made a change, what they changed, and when. That covers everything from product and entitlement config to experiment activity, webhook updates, and collaborator role changes.

Feature adoption audit

“Which RevenueCat features am I not using that I should be?”

Ask Rico to run a feature adoption audit on your project. It checks every RevenueCat feature against your actual usage data and returns three things: what you’re actively using, what’s gone dormant, and what you’ve never tried.

Rico might flag that your Refund Handling integration stopped flowing data three months ago, meaning Apple has been approving refunds without your input. Or it might notice you’re running Customer Center but haven’t enabled the Retention Messaging API, which gives you a second chance to retain users when they try to cancel in the App Store.

App and competitor research

“What’s Duolingo’s monetization strategy?”

Give Rico any app’s bundle ID or package name and it will pull the App Store and Google Play metadata side by side. Ratings, pricing, category, IAP structure, localization breadth, release cadence, the full picture.

Ask Rico to look up a competitor and it will flag what their monetization strategy tells you: whether they’re running a trial-led conversion model, how their content scope affects willingness to pay, what their rating trajectory suggests about product-market fit.

Rico in Slack

Most revenue questions start in Slack. Someone posts a screenshot and asks, “Anyone know why this dropped?” Then everyone waits for the one person who knows how to pull the number.

With the Slack integration, you can now tag @Rico in any channel with a question. The answer lands in the thread: the data, the context, and what to do next. Visible to everyone in the conversation.

To connect Rico to your Slack workspace, go to Account Settings in the RevenueCat dashboard, open the Rico tab, and click Connect to authorize the integration.

Try Rico today

Rico is available in public beta.

Head to your RevenueCat dashboard and ask for a health check. Tell Rico to run a feature adoption audit, or ask: “What’s the biggest bottleneck to my revenue growth right now?”

Open the dashboard or add Rico to Slack. Ask your first question.

Build a paywall by describing what you want

Wed, 06 May 2026 13:49:08 GMT

At the RevenueCat World Paywall Speed Building Championships 2025, the winner built a complete, production-ready paywall in 3 minutes and 16 seconds. It was an incredible feat of human engineering and drag-and-drop mastery.

You can now make that record completely obsolete.

You know you need to test your paywalls. The difference between a mediocre paywall and a great one is often the difference between a struggling app and a thriving subscription business.

But for anyone who isn’t a speed-building champion, the reality is different. Creating a paywall that looks good, handles every edge case, and is ready to publish requires design skills and engineering time you don’t have. Iterating on it takes even longer.

The result is a “good enough” paywall that never gets tested.

RevenueCat’s Paywalls AI Editor changes this. It’s a conversational paywall agent that lets you generate a production-ready paywall from a text prompt in seconds.

From drag-and-drop to done-in-seconds

You can edit any aspect of your paywall using natural language. Type “make the annual plan more prominent” or “use a darker color palette.” Every change streams live in the preview.

RevenueCat Paywalls AI Editor handles the entire paywall creation process from end to end. Whether you’re starting from a blank canvas or adapting an existing template, the AI Editor gives you complete control over every layer of your paywall.

Copywriting and conversion

Great paywalls live and die on their copy. You can ask the builder to rewrite your headlines, subheads, and CTA text to match your brand voice. Personalize the copy using custom variables like {{ custom.first_name }} or rewrite pricing language with variables like {{ product.price }} and {{ product.relative_discount }}. Clean up awkward copy, fix mismatched monthly and yearly labels, and rebalance plan emphasis, for example, changing the default selected plan, updating badge wording, or anchoring users toward the annual option.

Visual design and layout

You control the entire visual mood through natural language. Ask the builder to restyle your colors, adjust spacing, update typography, or fix contrast issues. Add or refine your layout for light and dark modes separately, for example, a white background with dark text in light mode and a deep navy with a glowing CTA in dark mode. Generate and swap imagery for your hero sections and backgrounds to better match your brand on the fly.

Components and structure

Building a paywall means assembling the right pieces. The AI Editor drops in whatever you need on command. You can add headers, feature lists, testimonials, comparison tables, timelines, carousels, and package groups. Remove, duplicate, reorder, or move any existing section, for example, pulling a testimonial block above the pricing cards to build trust before the ask. Ensure compliance by adding sticky footers and updating your Terms and Privacy URLs.

Localization

Scaling your app means translating your paywall. The AI Editor adds localizations directly to your layout and updates translated copy across every component. Fine-tune individual localized strings, for example, shortening a German CTA that overflows its button and test how different languages affect your layout before you push the changes live.

Pre-launch auditing

Before you ship, the builder acts as a second set of eyes. Ask it to audit your paywall for common conversion killers. It flags issues like a low-contrast CTA button, a pricing card that clips on iPhone SE, a missing restore purchases link, or an annual plan that looks identical to the monthly one. Get a list of fixes you can apply instantly with a single follow-up prompt.

Try the AI Editor today

The RevenueCat Paywalls AI Editor is available in public beta.

Log into your dashboard, click “Create paywall,” and select “Generate with AI”. Describe what you want to build. Try to beat 3 minutes and 16 seconds. We think you will.

The Hail Mary pitch that launched a #1 App Store hit

Wed, 06 May 2026 13:16:16 GMT

The Hail Mary pitch

Bria Sullivan had already found success with her game Boba Story, but she wanted to experiment with monetizing a creator’s audience through an app. After a chance dinner meeting with YouTuber Hank Green, she secured a pitch meeting. The goal was to build something for one of his educational channels, Crash Course.

The meeting didn’t go well. The team wasn’t interested, and the answer was a polite “no.” But as the call was wrapping up, Bria threw out one last idea: “What about a Focus Timer, a Crash Course focus timer?”

That single question changed the trajectory of the project. While the Crash Course team still passed, Hank Green himself loved the concept. An hour later, he texted her to say he couldn’t stop thinking about it. They decided to partner up and build it specifically for his core audience—the “Nerdfighters.” It was a reminder that sometimes the best opportunities come from simply putting yourself in the room and refusing to let the meeting end on a rejection.

Live-streaming user research on TikTok

Rather than building in a vacuum, Bria used her existing TikTok audience to validate the app’s design in real time. During long live streams, she would draw different art styles, show color palettes, and ask her viewers directly what they preferred.

She presented six different variations of the app’s central character—a “bean”—and let the audience guide the direction. “When it comes to female audiences too and anything gamified, the look and feel matters so much for organic reach,” she explains. “It’s like what’s going to make someone convert, and the way something looks is a huge reason why people convert.”

This public validation ensured that by the time the app was ready, it already matched the exact aesthetic preferences of its target users. The original, lo-fi “Bee and Puppycat” style she initially favored was scrapped entirely based on this immediate, unfiltered feedback.

The backlash of monetizing a fanbase

Partnering with a massive creator solves the distribution problem, but it introduces a unique set of challenges. When Focus Friend quietly launched via a YouTube community post, the initial reaction wasn’t purely celebratory.

Despite getting 20,000 downloads in the first week, Bria was flooded with angry emails and negative reviews. Users were upset that the app used a subscription model instead of a lifetime unlock, and they were highly sensitive to standard app practices like ad tracking. Because the app was tied to Hank Green—a beloved public figure known for his philanthropy—users felt a personal betrayal that they wouldn’t feel toward a faceless corporation.

“I learned that,” Bria says. “Every app on your phone uses those things, but for some reason he’s not allowed to.” To protect Hank’s reputation and maintain trust, they made the difficult decision to strip out advertising tracking IDs entirely. It was a move that essentially killed their ability to do paid user acquisition, but it preserved the core relationship with the audience.

Why creators make terrible product managers

Bria’s experience with Focus Friend taught her a crucial lesson about creator partnerships: influencers rarely know what makes a good standalone app.

“I don’t think that influencers really know what a good idea is for them to do for their audience,” she observes. “They always, for some reason, they always want a social media or they want a feed of information. And I’m just like, no, I just don’t think that those are good ideas for apps personally.”

Her advice to developers looking to partner with creators is to act as the product manager. Creators understand their audience’s content preferences, but developers understand utility. The most successful collaborations happen when the developer steers the product toward a clear, functional use case—like a focus timer—rather than trying to build another content feed.

In the full episode, Bria also talks about her journey from learning Android development in 2010 to winning an App Store Award, the reality of being a solo developer while raising a newborn, and why she believes product instinct is far more valuable than pure engineering skill.

Guest links:

AI-generated ads: balancing attention and trust in user-generated content

Wed, 06 May 2026 13:02:26 GMT

User-generated videos are no longer exclusively user generated.

With the rise of AI, advertisers can now generate creator-style ads in a matter of hours using synthetic avatars, automated voiceovers, and video tools. What used to require weeks of coordination and creator involvement can now be executed in an afternoon.

This shift is not just technological, it reflects a deeper change in how advertising operates — the pace of modern platforms has outgrown traditional content production.

But this raises a fundamental question. If content no longer needs to be created by real people to perform, what actually drives trust, and where does artificial intelligence start to break it?

Based on what we’ve tested at Mojo, the answer is more nuanced than the current hype suggests. But there’s a few key learnings:

Replication beats interpretation
The cost of failure has collapsed
AI knows what looks real, but humans know what feels real
You are no longer building an ad; you are building a system

The real driver: ad fatigue

The rise of AI-generated ads is not driven by novelty alone. While it is undeniably fueled by the fact that technology has finally crossed a critical threshold of fidelity, the primary catalyst for its adoption is a structural constraint: ad fatigue

On platforms like TikTok and Meta, videos are consumed at a relentless pace. A highly-effective ad can lose its impact within days. For subscription-based products, this rapid decay directly increases the cost of acquiring a new customer.

Today, those stakes couldn’t be higher — with RevenueCat data showing the top 25% of subscription apps grew 80% year-over-year in 2026, while the bottom 25% shrank by 33%. In a winner-take-more market, efficient acquisition isn’t just about optimization, it’s about your app surviving at all.

The natural response is to produce more videos. But this is where the traditional system breaks:standard production is slow and requires a lot of resources. Even highly efficient teams operate on multi-week cycles. Meanwhile, the algorithms shift in real time.

This creates a fundamental mismatch: the algorithm evolves faster than your production process. AI removes that constraint. Instead of asking what the next ad should be, teams can now ask how many variations they can test today. The primary advantage of AI is not that it produces better ads. It’s that it allows you to discover better ads faster.

Case study: Scaling the Mojo ‘Auto Edit’ winner

At Mojo, one of our highest-performing ads was a simple 30-second split-screen video featuring a speaker explaining the product on top and a screen recording of the app on the bottom. This video converted trial users to paid at 23%.

The secret was the person. Our creator was our Product Manager. When he explained the product, he was walking through something he deeply understood. His conviction came from ownership. That kind of authenticity is extremely difficult to synthesize from scratch.

Baseline: Our top-performing human UGC. Notice the genuine conviction of our PM talking about the feature he built.

Phase 1: why replication outperformed native creators

To scale this ad internationally, we initially recruited local creators in several countries to recreate the video. The result was disappointing — despite strong production quality, performance dropped across markets.

The issue came down to execution: each creator interpreted the script slightly differently. Pauses were shortened, pacing changed, and gestures were misaligned. Individually, these differences seemed minor, but collectively, they killed performance.

There was also a constraint regarding legal rights. We often did not have the rights to extend a creator’s content into other languages. This highlighted a critical point: the best-performing creator is the one you actually own.

So we changed strategy. Instead of adapting the ad, we replicated it: we used video translation tools like HeyGen to dub the original video, while strictly preserving the timing, the pauses, the gestures, and the exact energy. In Brazil, the dubbed version achieved a 40% lower acquisition cost compared to native creators.

The lesson here is that execution mechanics matter just as much as the message. AI does not reinterpret; it preserves.

AI Dubbing: 95% perfect lip-sync preserving our PM’s original high energy.

Phase 2: AI avatars (the 80% failure rate)

Encouraged by these results, we moved to fully AI-generated avatars. We expected the speed of production to compensate for a slight dip in quality. Instead, the outcome was binary: most of the profiles we tested failed almost immediately.

The generic avatars we initially generated did not work, and the reasons went beyond mere technical fidelity.

First, we encountered a fundamental perspective and staging issue. As you can see in the variations above, the avatars were placed in hyper-polished environments — studio microphones, cinematic lighting, and stylized backgrounds. Some were even positioned at slight three-quarter angles rather than looking directly into the lens. This immediately broke the native, informal visual code of UGC. The user’s brain categorized the content as a commercial within the first second.

Second, there was a major casting issue. The avatars simply did not match our Product Manager’s original profile or conversational energy. We were trying to scale a specific type of raw, founder-led credibility, but we were using avatars that looked like generic stock models or polished influencers. The disconnect between the message and the messenger was jarring.

These flaws, combined with the expected rigid expressions, caused rapid drop-offs. One avatar had a mere 0.2-second lip-sync delay on a key word, which resulted in a 68% drop in click-through rate compared to the human baseline. Users couldn’t articulate why they did not trust it, but the data was brutal.

But one avatar worked.

Instead of using a generic, polished profile, we used HeyGen to create a custom digital twin based strictly on our original Product Manager. We stripped away the studio mics and cinematic lighting. We matched his raw facecam perspective, his specific look, and his exact baseline energy.

Because the source material already had natural presence and inherent credibility, the output felt believable. That version reached 87% of the original human conversion rate.

The economics changed dramatically:

Traditional creator: $500
Generating the custom AI avatar: $20

RESULT: 31% lower cost per acquisition.

The $20 Winner: Natural head tilts and accurate micro-expressions driving a 31% lower CPA.

Phase 3: the double AI stack

Once we identified a winning creative, we introduced a two-step process: generating the base video using the custom avatar, then instantly translating it into multiple new languages using ElevenLabs for localized, natural-sounding voice cloning.

The results (Brazil localized metrics):

CPA: $8 (31% lower than the human control)
CTR: 4.5%
Conversion Rate: 3.1%
ROAS: 2.1x

The cultural limit: This ‘double layer’ stack (a synthetic avatar that is then dubbed into another language) worked flawlessly in Brazil and Spanish-speaking markets, where users are highly receptive to direct-response UGC formats. However, when we pushed this exact same dubbed avatar to Europe (France, Germany), it failed. The European audience was far more sensitive to the uncanny valley, and the double layer of AI broke their trust.

This highlighted to us that sensitivity to artificial media is not just technical. It is geographic and culturally dependent. You can’t assume universal adoption.

Key takeaways: how AI-generated UGC impacts ad performance and trust

Ads are our business, so we had the luxury of being able to test AI-generated ads and finesse the output. Many apps won’t be able to take this same risk and time, so here’s my top learnings from our creative experiments with AI user-generated content.

Why natural execution beats polished authenticity

There is a common assumption that videos made by users perform well because they’re authentic. In practice, authenticity is only part of the story. These videos work because — even when users are following a script — they feel natural.

The best-performing ads rely on familiar patterns like direct-to-camera delivery, informal conversational tones, and simple visuals. AI is highly effective at replicating these patterns. By mimicking the structure of successful content, AI-generated ads can improve early metrics like views and watch time.

Balancing algorithmic attention vs. user trust

One of the most important insights from our experiments is that these ads operate across two distinct layers:

The algorithm rewards attention
The user decides based on trust

AI helps you win the first, but it doesn’t guarantee the second.

In our tests, fully synthetic avatars struggled in formats that rely on credibility, especially testimonials or personal stories. People are sensitive to anything that feels artificial in emotional contexts. We subconsciously scan for micro-expressions, subtle changes in eye contact, and the natural hesitation that signals genuine human experience. When an algorithm tries to simulate a heartfelt story, it misses these imperceptible cues. The result is a subconscious rejection by the viewer.

Conversely, AI thrives in structured, utility-driven formats. For product demonstrations, tutorials, and feature breakdowns, clarity and pacing matter far more than emotional authenticity. The rule is simple: use AI to explain, and use humans to convince. This principle was at the heart of our strategy when we decided to scale our own top-performing content at Mojo.

The economics of failing fast

The real advantage of AI was not just cost. It was speed.

With traditional methods, creative testing five human creators takes $2,500 and three weeks of production to find one potential winner. Testing five AI variations takes $100 and just two hours.

The downside of testing creatives has collapsed. You’re no longer optimizing for perfect execution upfront, you’re optimizing for iteration speed. You are no longer buying videos, you’re buying iterations — and iteration compounds.

From production to decision-making

Before, production was the bottleneck. Now, production is instant. But a new bottleneck emerges: decision-making.

When you only have five videos a month, you can rely on intuition. When you can generate 50 variations a day, intuition fails. Teams no longer need to figure out how to produce content. They need to figure out what to test and what to cut.

AI did not remove the need for creativity. It made taste and data analysis the new competitive advantages. Bad decisions now scale just as fast as good ones.

The hidden risks

Like any new approach to ad creatives, there are payoffs you have to consider:

We’re already seeing a specific aesthetic emerge among AI-generated ads: perfect lighting, lack of breathing pauses, and synthetic enthusiasm. If every brand starts using similar avatars, these videos will become the new fatigued format. Ad fatigue won’t disappear; it just shifts from the individual video to the format itself.

Navigating the legal maze

There’s also a significant legal challenge. Building your acquisition engine on a digital copy of a real person is a liability maze. Who owns the likeness if that employee leaves the company?

With external creators, the problem is worse. If you don’t secure rights to use their digital likeness, you’re essentially renting your growth. Owned content scales, rented content does not. Brands need to rethink their talent contracts entirely. You need specific likeness agreements that outline exactly how, where, and for how long a synthetic avatar can be used, including clauses that allow the company to run the digital copy for six to twelve months after an employee departs.

Audience backlash and reputational risk

The risk of audience backlash is a reality that cannot be ignored. Audiences are becoming increasingly sophisticated at identifying synthetic media, and for subscription-based apps, the stakes are uniquely high. Because the business model relies on an ongoing relationship, being perceived as using deceptive or low-quality AI creative at volume can be devastating.

It creates what is essentially a ‘trust tax’, if a user feels tricked by an advertisement, they might install the app, but will inevitably churn. It doesn’t just hurt immediate acquisition; it erodes the fundamental trust that drives long-term retention. Every app audience is different, so it’s vital to consider your specific consumer group’s sentiment. The challenge for brands moving forward is finding the balance between being transparent, efficient, and maintaining a sincere human connection.

Best practices for scaling AI-generated ads

Before you generate new AI content, you need to answer a few fundamental questions:

Do you own the source material and likeness rights?
Is the format utility-driven rather than an emotional story?
Can you kill the campaign in 24 hours if the data shows it is failing?
Have you tested your specific market’s tolerance for synthetic media?

Most importantly, you have to break the perfection. Perfect delivery feels like a commercial. Here’s what we’ve found works:

Lower the resolution slightly so it does not look like a studio shoot
Let the audio retain a bit of background room tone.

Artificial intelligence naturally gravitates toward a flawless output, so you have to actively force it to be messy.

Checklist: when to use AI or real users for ads

If you’re deciding between a human creator and a synthetic avatar, use this quick reference guide based on our testing:

Opt for AI-generated ads when:

The goal is utility: product walkthroughs, feature demos, or screen-recording tutorials
You need scale: testing 10+ hook variations or localizing an ad into five different languages
Speed is critical: you need to respond to a creative trend within 24 hours
Cost is the bottleneck: you have a winning script but a limited budget for multiple creators

Opt for real humans when:

The goal is trust: personal testimonials, ‘storytime’ formats, or founder-led brand intros
Emotional nuance is key: content that requires subtle micro-expressions or genuine empathy
High-value markets: targeting regions (like Europe) with high sensitivity to ‘uncanny valley’ media
Originality: creating the source material that will eventually be replicated by AI

The new UGC

We’re entering an era of infinite content where the true bottleneck is no longer creation, but judgment. While the technological barrier to generating an ad has effectively dropped to zero, the psychological barrier to earning consumer trust has never been higher.

Algorithms are exceptionally good at replicating familiar patterns to buy attention, compress feedback loops, and scale distribution. What they cannot do, however, is synthesize genuine conviction. The top growth teams of the future won’t merely be those who test the fastest. Instead, they will be the ones who understand exactly when to automate a system for efficiency, and when to rely on a real human heartbeat for persuasion.Ultimately, AI didn’t make advertising smarter — it simply revealed the clear boundary between what machines can execute and what they cannot. Speed and automation will always buy you attention, but it takes a human to earn trust.

The post-purchase screen: how to stop Day 0 cancellations

Tue, 05 May 2026 10:21:34 GMT

There are a lot of things that keep me up at night: my ADHD medication, whether I locked the back door, my dog trying to get on the bed… and these trial cancellation numbers. Yep, stats like these are enough to steal my Zs (and now they’re about to do the same to you, sorry in advance).

A staggering 55.4% of 3-day trials are cancelled on Day 0. Ouch.

That’s over half gone before they’ve even had a chance to use what they signed up for. Talk about not giving an app a fair shot. So what’s happening, and how can apps combat it?

Whilst the number does drop a bit with longer trials, even with a 30-day trial nearly a third of users cancel on the very first day. Combine Day 0 and Day 1, and you’re looking at 84% of 3-day trial cancellations happening in that first 24 hours. For 7-day trials, it’s still 64%.

% of trial cancellations, by day and trial duration — State of Subscription Apps 2026

Do you see why those numbers keep me up at night?

And it’s not just trials, even annual subscriptions see almost 35% of cancellations within the first month.

Cancellation timeline for annual subscriptions — State of Subscription Apps 2026

Why 55% of free trials cancel on day zero

This data from the State of Subscription Apps Report 2026 really surprised me. Users are churning fast, losing faith in the app from the outset, feeling disappointed. It’s like your date slipping out after the first drink. You’re left wondering… how did it go so wrong so fast?

The first place we tend to look is onboarding. While I’ve seen plenty of wins from improving onboarding and paywalls, it’s not enough. These early cancellations show a clear pattern: people want to try your product. They hand over their payment details, click subscribe… and then something goes wrong immediately after.

Most advice on reducing early cancellations focuses on the in-app experience, pre-trial onboarding or improving your lifecycle marketing. All this is important, but there’s one step almost nobody talks about: the post-subscription screen. The very thing your users see the moment after they convert.

Introducing app aftercare: aka, the post-purchase screen

I first realized this when I interviewed Rosie Hoggmascall, Head of Product & UX at Fyxer.ai, on her approach to paywalls. She emphasized thinking about what happens after purchase, and it stuck with me. I call it aftercare, because that’s exactly what most apps are missing: care.

Think about it like this: you walk into a shop, buy something, and the minute your transaction goes through, the salesperson turns away. No “Great choice!”, no bag, no receipt, no guidance on how it works. Just… nothing. You’d feel weirdly used. Embarrassed. Probably just awkwardly standing there wondering, “Now what?”.

That’s exactly what most apps do.

I walked through a ton of post-purchase screens to see how different apps handle this moment. (Confession: I didn’t spend hundreds of pounds on subscriptions. I have to be very strict on my app subscriptions, given how many I test. So I used Mobbin for examples, though I did peek at some in the wild too.) What I found was a spectrum: some apps completely miss the moment, and some absolutely nail it.

6 Levels of post-purchase screen optimization

Here’s how to level up your post-purchase screen, step by step. I see six levels of post-purchase screens:

The basic version: straight into the app
A clear confirmation screen
Celebrate the moment
Remind them what they are getting
Highlight what you’ll help them achieve
Give them one clear next step

Each is slightly better than the last, and more in tune with what the user needs.

Now, I will say that as much as I love a neat little framework, some apps I reviewed broke the mould, choosing to use the post-purchase moment to push users to sign up for an account or pursue an upsell. That also works in certain scenarios, so I’ll cover when to go with those approaches as well.

I’ve also made a Mobbin board with 13 examples of different app onboarding-to-post-purchase screen journeys. Check it out here.

Level 1: the default straight-into-app version

The most common approach is to rely on Apple’s default “You’re all set” confirmation, then dump users straight into the app. That’s it. No intermediate screen, no acknowledgement of what just happened, no guidance on what to do next.

Take Zero, a weightloss and metabolic health app. You subscribe, get the standard Apple pop-up, and then you’re deposited straight into the app. What next?

MasterClass, the online learning platform, does the same. You could argue it makes sense — MasterClass has a massive library, and users potentially already know what they want to watch or were attracted by a specific expert to subscribe. But even here, a little extra care would go a long way. If someone clicks through that confirmation screen too quickly (and they will), they might not even register what they just signed up for — or how much they’re paying.

It’s the same as the store example I shared earlier: no acknowledgement, no guidance, just an abrupt ending.

Level 2: a clear confirmation screen

Level two is a simple but meaningful upgrade — after the standard Apple confirmation, add your own screen that acknowledges what just happened.

Pillow Talk, an AI journaling app, does this really well. It welcomes you to Pillow Talk Plus, confirms that everything in the plan is now yours — the insights, the support, the space to process — and then guides you straight into the app.

It doesn’t list every feature exhaustively, but it gives a reassuring tick that you made the right choice. It also helps clarify that your subscription went through, in case you clicked past the Apple pop-up too quickly (as I tend to do).

Lifesum, a calorie-counter and meal-planning app, takes a similar approach: “Your journey has begun”. Simple, warm, and focused on the outcome rather than the features. That small moment matters more than you might think, especially for someone on a trial who could still talk themselves out of it.

That little moment of “You made the right choice, here’s what’s ahead” can do a lot of heavy lifting. It’s the same as a salesperson in a store saying, “All set — enjoy!”

You can take it even further by reminding users of their original reason for signing up (their Job to be Done) to reassure them and reinforce why they’re here. It’s such a simple screen, and not a huge effort to implement, which is why I think this should be the minimum standard for any app.

Level 3: celebrate the moment

Now we can do even better. Be the store employee who doesn’t just say, “You’re all set,” but adds a little enthusiasm: “I have that shirt too” or “Those shorts have been so popular, I love them”. The tiny extra phrase that makes you feel good about your purchase (and less guilty about spending money when you swore off clothes shopping for the month… ahem, not talking about me here).

In-app, you can take the same approach: make the post-purchase screen feel like a genuine celebration. Not cringe or over-the-top, but a moment that acknowledges they made a good decision, and this is something worth celebrating.

This is what Duolingo does. When I first explored this topic with Rosie, she mentioned their celebratory animation, which quickly makes you feel good about the decision you just made.

I mean, we rarely see that owl so happy — it’s nice to see.

Animations are a great way to spark that energy. Take Kitchen Stories, a recipe app: their fun confetti screen welcomes you with, “You can now start using Kitchen Stories Plus!” It could be a bit clearer about exactly what’s included in Plus, but the moment of celebration is there, and it works. (And there is confetti, who doesn’t love a bit of confetti.)

Level 4: remind them what they’re actually getting

Here’s something app teams do too quickly: assuming users remember what’s included in the plan they just upgraded to. Spoiler: they don’t. Especially on a trial, where part of the decision might have been, “Well, I can always cancel”.

It’s like making a big order at a restaurant; it’s nice when the waiter repeats it back to you, reassuring you they’ve captured your order. The same applies here. Especially if the upgrade came through a feature-specific paywall, users might not even know all the premium features they now have access to.

Use the post-purchase screen to remind the user of their purchase. It provides clarity, removes nerves, and also reminds them of all the great features now available.

AllTrails, the hike, bike, and run app, does this really well for their Peak subscription. First, there’s a simple animation welcoming you. Then, after suggesting push notifications, they clearly list everything included in the plan.

For users who were previously on Plus, they even reassure you that you’re still getting all the Plus features too.

That prompt to enable push notifications, with a clear explanation like “We’ll remind you before your trial ends”, is also a clever way to tackle Day 0 cancellations. It’s a double win: you get permission to send notifications, and the user feels less anxious about forgetting to cancel if they want to — preventing the pre-emptive trial cancellation.

This point about notifications is worth dwelling on. You can promise users reminders upfront, but if they haven’t enabled notifications yet, that promise doesn’t land. The post-purchase screen is the perfect moment to set this up, in context, when the reason is obvious, and the value is immediate.

Level 5: highlight what you’ll help them achieve

Beside, an AI receptionist app does this particularly well. It congratulates you on starting your trial, then immediately reminds you of the outcome you’re here for: your clients will get instant answers, and you’ll get time back.

It also backs that up with three concrete stats:

100% of business calls answered
80% of inquiries handled automatically
30% more bookings

You haven’t even opened the app properly yet, and you’re already thinking about results, instead of fighting buyer’s remorse and wondering whether to cancel.

Headway, the bitesized book summaries and personal growth app, is one of my favorites here. It combines the celebratory approach from earlier with a satisfying star animation: “Congrats! Now you are a member of Headway Premium, together with 1.7 million learners.”

That community framing is smart. It immediately signals that this isn’t some scrappy app you should second-guess. 1.7 million people made the same choice you just did.

We often assume that because someone signed up for a trial or subscribed, they already trust us. But really, they’ve only trusted us enough to make that first purchase (that’s free!). The post-purchase screen is your chance to keep building that trust, step by step.

Then it reframes the moment around the Job to Be Done: “It’s Day 1 of your self-growth journey”. That’s more than a confirmation, it’s a feeling of excited expectation. This is a new me. I’ll finally stop doomscrolling Instagram and start learning!

Headway reinforces this by focusing on outcomes — grow your productivity, get daily motivation, improve your soft skills — rather than just listing features. It’s about making the user feel the value they just unlocked.

Level 6: give them a clear next step

For some apps, the biggest barrier after subscribing isn’t doubt, it’s paralysis. Where do I start? What should I do first? If your app has a lot of content or options, that first decision can feel overwhelming enough to make someone close it entirely.

Now you don’t want to hit users with ten questions right after purchase — I don’t know about you, but when that happens, I just blank or pick the first thing that comes to mind.

The solution isn’t more information, it’s fewer choices. Greg, a plant care app, handles this brilliantly. The post-purchase screen gives you one job: start adding your plants. Take a photo or upload one. No menus to navigate, no features to explore, no extra decisions. Just one clear first step that gets you using the product immediately.

I had a similar experience with Picnic, a photo-organizing app. The moment I subscribed, it took me straight to a folder of my 2017 photos and had me swipe left or right to decide what to keep — Tinder-style.

As someone who hasn’t used a dating app in ten years, I got to enjoy the fun of swiping again. Once I finished that folder, the app celebrated how much space I’d freed up and let me delete the photos. Then I could move to the next folder at my own pace, making the process clear, fun, and completely manageable.

What that did (and I don’t think it was accidental) was make me feel immediate progress. I wasn’t thinking about whether the weekly subscription was worth it; I was busy clearing out my 2017 camera roll. By the time I came up for air, I was already invested, and honestly, it was kind of fun sifting through years of photos.

Another approach is to provide a brief instruction on what to do next. After the celebratory owl, this is exactly what Duolingo does: a simple, clear set of steps showing how the app works and what to do first:

While many apps include this guidance in their onboarding — and yes, most users will see it on Day 0 — for anyone signing up later, it’s a helpful reminder of what they’ll get and how it works.

Alternative post-purchase onboarding strategies

Now we’ve covered the six levels of app aftercare, let’s push it just a little further. Depending on your app, you can also use this moment to encourage users to create an account or present a subtle upsell, making the post-purchase screen do double duty.

1. Push for the account setup

If account creation is important to your app — for saving progress, personalizing the experience, or staying in touch — and you haven’t already collected it, the post-purchase screen is a good moment to ask for account creation. Not perfect, sure — ideally, you’d have it earlier, but better late than never.

The key is giving users a real reason to hand over their details right now. Not “create an account to continue” (that feels like a gate), but motivation to pass over that info. Back to our shop example: if setting up an account comes with a perk, like 10% off, we’re much more likely to go for it.

Alan Mind, a previous CBT-guided journaling app, does this well: “Save your progress and secure your journal”. That’s a reason that actually matters to the user, showing that their data and privacy are safe.

What would make this even better is offering frictionless sign-up options, like Apple or Google. It removes effort at exactly the moment users are least motivated to fill out forms.

As it stands, it’s not entirely clear what the password requirements are either, which can make this step feel unnecessarily clunky, and that’s the last thing you want right after someone has just subscribed.

Calm, the meditation app approaches this a bit better:

Post-purchase, you get a how did you hear about us survey, and are then encouraged to sign up for an account to track progress.

2. Go for the upsell

One final option — and one to use carefully — is leveraging the post-purchase high to push for a longer commitment or additional purchase. This tends to show up more in larger, well-known apps that are focused on increasing realized LTV per paying customer.

Flo, a cycle-tracking and women’s health app, does this with confidence. After congratulating you on starting Flo Premium, it presents a ‘gift’, which turns out to be a 44% lifetime discount on an annual subscription.

The framing is smart: it’s positioned as a gift, not a sales pitch. And by locking in annual subscribers at the moment of highest trust, they’re tackling both trial drop-off and long-term churn in one move.

Headway takes a slightly different approach. After the celebratory screen, they offer a one-time deal on a Self-Reflection Ebook at a discounted price.

This is a more classic upsell moment, the kind you’d usually see in e-commerce. You’re already in a ‘yes’ mindset, trust is high, and a complementary product can feel genuinely helpful rather than pushy.

That said, sequencing matters. Focus on getting the basics right first, making sure users feel good about what they’ve just committed to, and only then, ask for more.

How to build your first post-purchase screen

Getting started is easy. If you’re currently at Level 1, don’t try to jump straight to Level 5, as tempting as it is. Start with Level 2. It’s a single screen you can ship in a sprint: acknowledge what just happened, remind users why they signed up, and make them feel good about it. That alone puts you ahead of most apps.

Once that’s live, start layering in improvements. Add a celebratory moment or a clear first step, depending on what your app needs. If your product has a lot of content and users tend to feel overwhelmed, prioritize a clear next step or simple instructions (like Duolingo). If your product is simple but the commitment feels big (like Headway), lean into celebration and reassurance.

The main metrics to watch are your Day 0 and Day 1 cancellation rates. Track before and after launching the new screen to measure impact. If you offer a free trial, also monitor your trial-to-paid conversion rate, especially if you’ve added things like push notification opt-ins or feature reminders (like AllTrails has).

If you go down the upsell route, focus on realized LTV and retention, not just the conversion rate on that single offer. A pushy upsell that damages trust will cost you far more in churn than it generates in upgrades.

Because ultimately, the goal isn’t to optimize the post-purchase screen in isolation, it’s to get the moment after someone subscribes right, because that sets the tone for the entire relationship.

Don’t skip this onboarding moment

There are many ways to approach the post-purchase screen, and not every approach will fit every app. But the one thing I’d strongly push back on is doing nothing, dropping users straight into the app, and hoping they figure it out.

At a minimum, give users clarity on what they’ve just subscribed to. Add a moment of celebration, a clear next step, or a reminder of the outcome they’re working towards. These aren’t big product investments, but they can make a real difference to those Day 0 cancellation numbers.

You’ve already done the hard work of earning someone’s trust to the point that they’re willing to subscribe. Don’t stop guiding them the moment they do.

Compose Multiplatform subscriptions: single codebase for iOS and Android

Thu, 30 Apr 2026 01:40:16 GMT

You ship a subscription app on Android and your team starts the iOS port. Suddenly you are maintaining two paywall implementations for Android and iOS, two billing integrations, and two sets of receipt verification code with different APIs and different bugs. RevenueCat’s purchases-kmp SDK collapses that duplication. You write your subscription logic once in commonMain, the SDK wraps Google Play Billing on Android and StoreKit on iOS, and a Compose Multiplatform paywall component renders the same UI on both platforms.

In this article, you’ll set up a Kotlin Multiplatform project with the RevenueCat KMP SDK, configure dashboard products and entitlements, initialize Purchases on Android and iOS, gate premium content from common code, run an in app purchase from commonMain, and drop in a server driven paywall built with the dashboard’s Paywall Editor. You’ll work directly with the same source layout used by cat-paywalls-kmp, the official KMP demo app.

What you’ll build

You’ll end up with a Compose Multiplatform app that lists premium articles, fades the body until the user is entitled, opens a server driven paywall, runs the purchase through the platform native dialog, and refreshes the entitlement state. The same screen runs on both iPhone and a Pixel without a single line of duplicated UI code.

The repository structure is a normal multi module KMP project: a composeApp module with commonMain, androidMain, and iosMain source sets, a few feature modules (home, article, paywalls, subscriptions), and core modules for data, network, and design system. Every line of subscription logic in this tutorial lives in commonMain.

Why single codebase changes the math

Building cross-platform subscriptions without a shared SDK means writing every subscription concept twice. You query Google Play with BillingClient and a purchase token, and you query StoreKit with Product.products(for:) and a signed JWS. You verify receipts with two completely separate server APIs, store them in two different shapes, and reconcile them with a backend mapping layer. None of this work is the part of your product that users care about.

The RevenueCat KMP SDK gives you four shared concepts that hide all of that:

Offerings are the set of products you currently sell, configured in the dashboard rather than in your app.
Packages are the buyable units inside an offering (monthly, annual, lifetime).
Entitlements are the access levels your app cares about (premium, pro, family), independent of which store the user paid through.
CustomerInfo is a single object that aggregates every active entitlement for the current user, regardless of platform.

Once you have these four objects, your app stops asking “did this user buy through Google Play or App Store?” and starts asking “is customerInfo.entitlements["premium"] active?” That single property check works the same on iOS and Android.

Prerequisites and dashboard setup

Before any code, you’ll set up four things in the RevenueCat dashboard:

A project with one Android app and one iOS app, each linked to its store credentials.
Products imported from Google Play Console and App Store Connect.
An entitlement named premium (or whatever identifier you prefer).
An offering with one or more packages attached, marked as the current offering.

Two codelabs walk through the dashboard side end to end. If you have not configured products yet, go through them first:

The two important screens to land on are the entitlement and the offering. The entitlement is the unit your app code checks:

The offering is what your app fetches at runtime. It bundles the packages you want this version of the app to display, and you can change its contents without shipping a new build:

After both apps are set up, copy the public SDK API keys from Project Settings > API Keys. There is one key per platform, and you will use both of them in Step 2.

Step 1: Add the RevenueCat KMP SDK

The KMP SDK ships as two artifacts: purchases-kmp-core for the subscription logic and purchases-kmp-ui for the Compose Multiplatform paywall component. Both are published to Maven Central with a single version coordinate of the form <sdk>+<hybrid-common>. The number after the plus sign matters when you link the iOS pod, so do not strip it.

Start by adding the version and library entries to gradle/libs.versions.toml:

Then declare the dependencies inside the commonMain source set of your app module’s build.gradle.kts. In the cat-paywalls-kmp demo this lives in composeApp/build.gradle.kts:

Notice that both Android and iOS pull the same commonMain dependency. There is no androidMain.dependencies { implementation("com.revenuecat...") } block. The KMP artifact carries platform specific bindings inside it.

Linking the iOS native framework

The KMP SDK depends on PurchasesHybridCommon, a native iOS framework that wraps StoreKit. The cleanest way to bring it in is through the Kotlin CocoaPods plugin. Apply the plugin to your composeApp module:

Then declare both pods inside the kotlin { cocoapods { ... } } block. Pin the pod version to the same major as your purchases-kmp artifact so the Kotlin and Swift sides agree on protocol shapes:

Run ./gradlew podInstall once. Gradle generates a .podspec for your shared module and writes a Podfile.lock next to your iOS app. From now on, opening the iOS workspace in Xcode pulls everything down through CocoaPods.

The KMP SDK uses Kotlin/Native interop bindings that are still flagged as experimental, so opt in inside any iOS source set that touches them:

That is the entire setup. No platform-specific source files yet. Everything else lives in commonMain.

Step 2: Initialize Purchases on each platform

Purchases is a singleton. You configure it once early in the app lifecycle, then every other call goes through Purchases.sharedInstance. Initialization is the only place where Android and iOS code differ, and only because each platform has its own application entry point.

On Android, initialize from your Application.onCreate. The cat-paywalls-kmp demo does this in CatArticlesApplication:

The PurchasesConfiguration(apiKey) { ... } builder is a small DSL. Inside the trailing lambda you can set appUserId, purchasesAreCompletedBy, verificationMode, and other options. Passing appUserId = null tells the SDK to generate an anonymous identifier in the form $RCAnonymousID:<uuid>. When the user later signs in to your backend, you call Purchases.sharedInstance.logIn(userId) and RevenueCat transfers any purchases to that account.

Do not forget to register the Application class and the INTERNET permission in AndroidManifest.xml:

On iOS, initialize from your SwiftUI App struct. You import the native RevenueCat pod here, not the KMP wrapper, because configuration runs in Swift before the Kotlin runtime starts:

ContentView then hosts the shared Compose surface inside a UIViewControllerRepresentable:

The Kotlin side of that bridge is a one liner in iosMain:

App is the same @Composable you call from MainActivity on Android. From this point on, every screen you build runs on both platforms.

The reason initialization is split is that Purchases.configure reaches into the platform billing client immediately. On Android it asks BillingClient to open a connection. On iOS it registers a StoreKit transaction listener. Both need to happen before any Compose composition starts, which is why you do not configure inside commonMain.

Step 3: Check entitlements from common code

Once Purchases is configured, you can ask “is the current user entitled to premium?” from anywhere in commonMain. The KMP SDK exposes coroutine friendly suspend variants of every callback API. The one you want here is awaitCustomerInfo():

CustomerInfo.entitlements is a map keyed by the entitlement identifier you set up in the dashboard. The value is an EntitlementInfo with an isActive flag, an expirationDate, a willRenew boolean, and a store enum that tells you which platform the underlying purchase came from. For access decisions, only isActive matters. The entitlement is active whether the user subscribed through the App Store, Google Play, Stripe, or a promotional grant from your support team.

Most apps wrap this in a repository so the rest of the app can collect a Flow and forget about callbacks. The cat-paywalls-kmp demo defines PaywallsRepository in core/data:

The fetchCustomerInfo implementation is a thin Flow wrapper around the SDK call, with Dispatchers.IO to keep network work off the main thread:

A ViewModel collects this flow and exposes a StateFlow<CustomerInfo?>:

The Compose Multiplatform UI then reads it like any other state and decides whether to render the article body or fade it behind a paywall prompt:

DetailsContent applies a fadingEdge modifier when isEntitled is false. Subscribed users see the article through to the end. Free users see the first few paragraphs fade into a “Join Now” CTA. The same composable runs on both iOS and Android.

Step 4: Run a purchase from `commonMain`

Triggering a purchase is two suspend calls: fetch the current offering, then call awaitPurchase with one of its packages. The SDK takes care of opening Google Play’s billing dialog or StoreKit’s purchase sheet, validating the receipt with the store, and posting it to RevenueCat for tracking.

The awaitPurchase helper from purchases-kmp-core accepts a Package:

Offering exposes convenience accessors for common cadences (monthly, annual, lifetime) and a generic availablePackages: List<Package> if you want to build a custom plan picker. The cat-paywalls-kmp demo wraps this in PaywallsRepository.awaitPurchase(packageId):

Two things to know about the return value. First, the StoreTransaction is informational only. The receipt has already been validated server side by the time awaitPurchase resumes, and the user’s CustomerInfo has been updated on RevenueCat’s backend. Second, the next call to awaitCustomerInfo() will reflect the new entitlement, which means any UI bound to your customerInfo flow recomposes automatically. You do not need to manually invalidate state.

If the user cancels the dialog, the SDK throws a PurchasesException whose code is PurchaseCancelled. Catch it and treat it as a no op rather than an error.

Step 5: Drop in a server driven paywall

You could build the package picker yourself, but RevenueCat’s Paywall Editor lets you design the entire screen in the dashboard and update it without shipping a new build. The purchases-kmp-ui artifact includes a Paywall composable that renders the configured paywall on both Android and iOS.

You design the paywall in the dashboard’s visual editor:

In your KMP code, the entire paywall screen is one Paywall call. The cat-paywalls-kmp demo lives in feature/paywalls/CatCustomPaywalls.kt:

PaywallOptions is where you pass callbacks for dismissal, purchase completion, and restore. With no offering passed, the component renders the current offering assigned to the user in the dashboard. If you are running an A/B test, RevenueCat picks the variant for this user automatically and attributes any conversion to the right experiment arm.

This is the part that pays for itself. The entire visual design of the paywall, including which packages to show, how to highlight the recommended plan, what copy to use for the trial CTA, and which offering to display, is configurable from the dashboard. You can tweak headline copy or swap a one screen layout for a feature comparison layout in the morning, watch conversion metrics in the afternoon, and revert by clicking a button if the new variant underperforms. None of this requires a Play Store or App Store review cycle.

Putting it all together: the architecture

Here is how all the pieces line up in a finished KMP project. In code, the cat-paywalls-kmp demo organizes responsibilities by module:

composeApp is the only module with platform specific code. Its androidMain configures Purchases from the Application, its iosMain exposes a MainViewController() to SwiftUI, and its commonMain holds App.kt plus a Navigation Compose NavHost.
feature/* modules are screens (home, article, paywalls, account, subscriptions). They depend on core/* and contain Compose Multiplatform UI plus ViewModels.
core/data owns PaywallsRepository, the only place that calls into Purchases.sharedInstance. Everything else reads Flow<Offering> and Flow<CustomerInfo> from this repository.
core/model, core/network, core/designsystem, core/navigation hold the data classes, Ktor client, theme, and navigation graph respectively.

The final UX you ship looks like this. Subscribed users see the full article and a subscription management screen sourced from the same CustomerInfo object:

The same SubscriptionManagementScreen reads customerInfo.activeSubscriptions, customerInfo.entitlements["premium"]?.isActive, and customerInfo.originalAppUserId to render its content, and runs without modification on both platforms. There is no if (Build.VERSION...) and no #if os(iOS). The code lives once, in commonMain, and the SDK does the platform translation underneath.

If you want to inspect the full source as a reference, every file shown in this article is in cat-paywalls-kmp. The minimum surface to get a working integration is the four steps above plus the dashboard setup. Everything else is product specific UI.

Conclusion

In this article, you’ve configured the RevenueCat KMP SDK in a Compose Multiplatform project, initialized Purchases on Android and iOS, gated a premium screen with CustomerInfo.entitlements, run a real purchase through awaitPurchase, and rendered a server driven paywall with the Paywall composable from purchases-kmp-ui. Every piece of subscription logic except platform initialization lives in commonMain, which means your iOS and Android apps stay in lockstep without any code duplication.

The thing worth internalizing is what the SDK takes off your plate. You no longer think in terms of purchase tokens versus signed transactions, two notification pipelines, or two receipt verification servers. You think in terms of offerings, packages, entitlements, and CustomerInfo, and the SDK collapses both stores into those four concepts. That same abstraction is what makes the visual Paywall Editor possible, since it is far easier to ship one server driven UI when there is only one shared state model underneath.

Whether you are porting an existing Android subscription app to iOS, starting a new product on KMP from scratch, or experimenting with paywall variants without burning a release cycle, this setup gives you the smallest surface area you can ship a cross platform subscription app on. The remaining engineering time goes back into the parts of your app that actually differentiate your product.

As always, happy coding!

— Jaewoong (skydoves)

How a switch from hard paywall to freemium led to a 75% LTV lift and a 50% conversion drop

Wed, 29 Apr 2026 16:06:13 GMT

For the vast majority of subscription apps, the most reliable path to profitability is simple: lock your core value behind a hard paywall.

The data backs this up. According to our State of Subscription Apps report, hard paywalls convert downloads to paid at a median of 10.7% — five times better than the 2.1% median for freemium apps. The floor for hard paywalls (4.2%) is actually double the median for freemium.

“If you’re a bootstrapped startup or you’re operating with limited outside capital, it’s a much more reliable and low-risk way of growing your business,” explains growth advisor Phil Carter in a recent episode of the Sub Club podcast.

But what if you want to build a billion-dollar company?

“There are a lot of examples of apps like Spotify, Duolingo, Strava that have done that through freemium,” Phil says. “You’re just going to attract a much larger user base at the top of the funnel if you have a free version of your product.”

The transition from a hard paywall to freemium is the highest-ceiling growth lever a mature app can pull. It’s also the most dangerous. To illustrate the stakes, Phil shared the story of his biggest win — and his biggest failure — from the past year. Both involved the exact same strategy.

The win: a 75% increase in LTV

Phil’s biggest win came from helping an established subscription app move away from a traditional hard paywall. But rather than simply opening up the app and hoping users would eventually subscribe, his team implemented a “multistep paywall.”

The strategy reframed the value proposition. Instead of saying, You have to pay for this product now, the new onboarding flow communicated a different message: This product is free and will always be free, but we want you to try the best version of it for seven days. After that, we’d love to have you continue paying to get maximum value.

The results were staggering.

“We saw a 75% increase in LTV per user through the implementation of this multistep paywall along with some other pricing and packaging optimizations,” Phil says.

By removing the hard gate, the app widened its top-of-funnel significantly. More users experienced the core product, organic acquisition accelerated, and the multistep paywall successfully captured the revenue upside.

“It pretty fundamentally altered the full potential size of this business,” Phil notes.

The fail: a 50% drop in conversion

The success of the multistep paywall might suggest that every scaling app should immediately drop its hard paywall. But Phil’s biggest failure of the year serves as a stark warning against treating freemium as a silver bullet.

With a different client, Phil’s team attempted a similar shift to freemium. The results were disastrous.

“The initial results didn’t work at all,” he admits. “We saw more than a 50% reduction in subscriber conversion. We very quickly pulled off of it after a couple of weeks.”

Why did the exact same strategic move produce such radically different outcomes?

It comes down to product-market fit and the inherent complexity of managing a freemium model. When an app relies on a hard paywall, it forces a binary decision before the user has fully experienced the product. The conversion is driven by the promise of value, the quality of the marketing, and the friction of the paywall itself.

When you remove that friction, you’re entirely reliant on the product’s ability to demonstrate ongoing, undeniable value. If the free experience is too generous, users have no incentive to upgrade. If it’s too restrictive, they churn before forming a habit.

According to State of Subscription Apps 2026, 55% of all 3-day trial cancellations happen on Day 0 — meaning the battle for the subscriber is won or lost in the first session.

As Phil puts it, moving from a hard paywall to freemium is “like moving from playing checkers to playing chess because it requires a lot more sophistication.”

When should you make the switch?

If you’re considering dropping your hard paywall, the data and Phil’s experience suggest a clear framework for the decision:

1. Stay with a hard paywall if:

You’re bootstrapped or highly capital-constrained
You need immediate cash flow to fund paid acquisition
Your product solves an acute, immediate problem rather than building a long-term habit
You don’t have the product analytics infrastructure to rigorously test feature gating

2. Consider testing freemium if:

You’ve achieved strong product-market fit and high retention among your core users
You’ve got the runway to absorb a temporary dip in conversion rates while you optimize the model
Your product benefits from network effects or user-generated content (like Duolingo’s massive free experience)
You’ve hit a growth ceiling with paid acquisition and need to unlock organic, word-of-mouth growth at scale

Freemium isn’t a pricing strategy; it’s a product strategy. If you treat it simply as a different way to display your paywall, you risk halving your conversion rate. But if you treat it as a fundamental shift in how you deliver value, it might just be the move that turns your app into a billion-dollar business.

The counterintuitive freemium strategy that scaled Opal to 1M daily active users

Wed, 29 Apr 2026 12:58:49 GMT

Why dropping conversion to 9% was the right move

When Opal, the popular screen time and focus app, hit $5 million in annual recurring revenue (ARR), they were scaling efficiently with a hard paywall. The business model was working, but user growth was plateauing.

To build a product capable of reaching a billion users, CEO Kenneth Schlenker made a terrifying decision: transition to a true freemium model. The immediate result was a massive drop in their download-to-paid conversion rate, plummeting from 20% down to 9%.

But that drop was exactly what the company needed. By giving away the core product for free, Opal unlocked entirely new segments—specifically high school and college students, who now make up two-thirds of their daily active users (DAUs). These free users became the app’s marketing engine. The initial hit to conversion was eclipsed by an explosion in organic growth, pushing Opal past 1 million DAUs and $10 million in ARR.

“We’ve seen a decrease in our conversion to paid, but we’ve also seen as a consequence of that an explosion of our DAUs and revenue with it,” Schlenker explains. “It’s a short-term, scary drop, but what happens in the long-term is that it pays back tenfold.”

The success of a freemium model hinges on a single question: would a non-paying user recommend the app to a friend? If the answer is no, the paywall is too restrictive.

Schlenker argues that many apps fail at freemium because their free tier feels like a crippled trial rather than a complete experience. If users hit aggressive limits before they can extract real value, they won’t stick around, and they certainly won’t tell their friends.

To find the right balance, Opal experimented heavily with their “blocks” feature. They tested giving free users just one block, then two, then more. They eventually landed on three free blocks per day. This proved to be the sweet spot—enough functionality for free users to get a great experience and build a habit, while still leaving power users hungry enough to upgrade.

You can’t “vibe code” a brand

With the rise of AI coding tools, the narrative of the “billion-dollar one-person company” has gained traction. The idea is that a single developer can spin up a functional app in a weekend and scale it to massive revenue. Schlenker calls this a lie.

While AI is incredibly efficient at generating functional tools, it cannot generate emotional resonance. A screen time app is technically simple to build—Schlenker notes that people frequently launch Opal clones—but building a category-defining company requires more than just code.

“Teams create product soul. You can’t vibe code a brand,” Schlenker says. “I think that a recipe for failure in my mind is just to create something that has a function, which AI does really, really well… but you need more than that to be able to be successful.”

That “soul” is evident in Opal’s design choices, like the highly engineered, tactile interaction of cracking open a digital gemstone when a user hits a focus milestone. It’s an expensive, difficult feature to build that doesn’t directly move a metric on a spreadsheet, but it’s the exact kind of magical moment that builds brand affinity and long-term retention.

Expanding beyond the App Store into schools

Opal’s organic growth among students led to an unexpected B2B opportunity. A high school in Los Angeles reached out to the company because their students—who were already using Opal independently—suggested the app as a solution to the state’s impending phone ban.

This organically birthed “Opal for Schools,” a specialized deployment that blocks distracting apps while students are on campus, but allows access to educational tools and emergency contacts. Crucially, it’s not just a “bell-to-bell” restriction. Students keep the app after school, using it to manage their own study time and sleep schedules.

By partnering with schools, Opal is essentially building the next generation of professional users while solving an immediate crisis for educators.

In the full episode, Kenneth also discusses why retention is the only real moat for consumer apps, how they turned a viral user video into their most successful ad, and why every AI feature should be evaluated by whether it makes the user win.

Guest links:

Apple’s new monthly subscriptions with a 12-month commitment: useful, but probably not magic

Tue, 28 Apr 2026 15:45:38 GMT

Apple has introduced monthly subscriptions with a 12-month commitment: an annual subscription that customers pay for month by month. Developers can configure and test them now, and Apple says they’ll be available to customers in May everywhere except the United States and Singapore.

This is a meaningful new pricing tool, especially for markets where paying a full year upfront is a real barrier. But it is probably not a new default subscription model for most apps. In fact, Google Play has worked similarly for a while, but is not wildly popular. The best use case is localized experimentation: making annual-style commitment more accessible without giving up the long-term retention benefits of a yearly plan.

What Apple announced

Apple’s new option lets developers offer an auto-renewable subscription that behaves like an annual commitment, but bills the customer monthly.

Instead of asking someone to pay, say, $59.99 today for a year of access, you can ask them to commit to 12 monthly payments. The customer can cancel at any time, but they will still be charged monthly for the remainder of their 12 month period. At the end of their commitment they will lose access to paid features and will no longer be charged.

Apple is also handling some of the customer-facing transparency. Customers can see completed and remaining payments in their Apple Account, and Apple says it will send email and push notifications before renewal.

The important availability note: Apple says this will be available worldwide except in the United States and Singapore.

This is not just “a monthly plan”

The implementation detail that matters is that Apple is modeling this as an annual subscription product with multiple billing plans.

In App Store Connect, developers create an annual auto-renewable subscription and choose between billing plan types, including “1 Year Upfront” and “Monthly With 12-Month Commitment.” Those billing plans can exist under the same product ID.

That means a single subscription product can now have multiple ways to pay:

One annual price paid upfront
One monthly price paid over a 12-month commitment
Different intro, promo, win-back, or offer-code behavior per billing plan

The customer does not simply pick from an Apple-generated menu at random. Your app or paywall still needs to present the right option and initiate the purchase with the intended billing plan. Developers also need to clearly show both the monthly payment and the total commitment amount before purchase.

This is all very similar to Google Play’s installment base plan for subscriptions: one subscription concept, multiple purchasable configurations.

Why this probably won’t change everything

The obvious first reaction is: this is huge. Annual subscriptions, but paid monthly, should reduce friction and increase conversion.

Maybe. In some cases.

But Google Play has supported installment-style subscriptions for a while, and they have not become the default way most apps monetize. There is a reason for that: for many apps, the standard annual plan is still better.

A paid-upfront annual subscription gives the developer cash today. It improves short-term payback, reduces monthly billing failure risk, and creates cleaner revenue recognition for the business. If your audience can comfortably pay upfront, the traditional annual plan is still a very strong product.

Monthly annual commitments are different. They may lower the purchase barrier, but they do not give you all of the cash upfront. They also add complexity to pricing, paywall copy, analytics, support, and cancellation expectations.

So the goal should not be “replace annual subscriptions.” The goal should be “test whether this unlocks customers who wanted the annual value proposition but could not or would not pay the whole amount upfront.”

Where it gets interesting

The strongest opportunity is localization.

In many markets, the problem with annual subscriptions is not that users dislike commitment. It is that the upfront price is too high relative to local purchasing power. A $50 or $60 annual subscription can be a meaningful expense. Breaking that into monthly payments while preserving a yearly commitment changes the decision.

That makes this especially worth testing in markets where:

Annual conversion is low, but monthly retention is healthy
Users respond to annual discounts but hesitate at checkout
Local purchasing power makes upfront annual pricing feel too steep
You already localize pricing and paywall strategy by country

This is not currently useful for the US, especially because Apple is excluding the US (and Singapore) from launch. But that actually reinforces the point: this is less about a universal monetization shift and more about giving developers another regional pricing lever.

As of writing, Google Play only supports their installments based plans for subscriptions in Brazil, France, Italy, and Spain. This may be a good signal that these regions are more likely to be interested in these types of offers.

What not to use it for

This should not be used to cover up weak retention.

If users do not keep finding value in your app, putting them into a 12-month payment commitment is unlikely to create a better business. It may create more support tickets, more refund requests, more negative reviews, and more payment failures.

The right apps to test this are apps with proven long-term value. If users already stick around, but upfront annual pricing is the barrier, monthly commitments could help. If users churn because they stop using the product after two weeks, this won’t help.

What developers should watch

The obvious metric is conversion: does a monthly annual commitment convert better than a paid-upfront annual plan?

But that alone is not enough. Developers should also watch:

Annual-plan cannibalization
Payment failure and recovery rates
Refund and support volume
Renewal into the next 12-month commitment
Subscriber sentiment in reviews and support conversations
Net revenue by country compared with standard monthly and annual options

This is a pricing experiment, not just a checkout experiment. The upside is incremental revenue from users who would not have bought annual upfront. The downside is replacing high-quality upfront annual purchases with slower, riskier monthly payments.

How RevenueCat is thinking about support

Over here at RevenueCat we are, of course, all over this.

Early testing suggests these transactions can move through our systems, but full support requires some product changes our engineering team is already hard at work on.

Developers will need a clean way to understand which billing plans are available, present the right pricing terms, choose the intended billing plan at purchase time, and measure performance after launch. Paywalls will also need to account for regional availability, since the monthly commitment option is not available everywhere.

We’re actively looking at the right way to model and expose this so developers can take advantage of it without taking on all of the complexity themselves. More details will come as Apple’s rollout gets closer and we finalize support across the RevenueCat platform.

For now, the practical takeaway is simple: this is a useful new tool, especially for localized annual pricing. It is not a magic monetization switch. The apps that benefit most will be the ones that test it deliberately, explain it clearly, and already have the retention to make a 12-month commitment feel fair.

Stop building features: why early-stage apps need a learning roadmap first

Tue, 28 Apr 2026 10:11:45 GMT

Most early-stage founders have a roadmap full of features they want to build. It feels productive; you’re shipping, you’re making progress.

And while I love fast shipping over perfection, when that speed is focused purely on features, it can be dangerous — especially when you start planning months ahead. You’re assuming you know what users need before validating it, and you’re also committing to features and improvements in a space that is still highly volatile.

Then the roadmap becomes a to-do list of guesses; outputs rather than outcomes. You ship features with great excitement, but you don’t necessarily learn whether they actually matter. Or, at the very least, learning happens much more slowly than it should.

I’ve seen new subscription apps spend months building features that nobody actually uses, because they never paused to ask: what do we need to learn right now?

For early-stage subscription apps, roadmaps shouldn’t be about what to build, as you really can’t reliably predict more than a quarter ahead anyway.

Instead, they should be about what to learn.

That’s exactly what we’ll focus on: building a learning roadmap.

A learning roadmap is a structured plan built around questions and hypotheses rather than features — designed to validate assumptions before committing to a build.

Focus on validating over shipping features

There’s a difference between a shipping mindset and a validating mindset.

Shipping feature mindset: What features can we release this quarter?
Validating mindset: What’s the most important question we need to answer right now?

Pre-Product-Market Fit, you’re not trying to build a complete app that does everything. Instead, you’re trying to figure out whether you’re building the right thing.

The goal is to learn what actually matters to your early users, and what drives them to pay.

The beauty of switching to a validating mindset is that it often doesn’t require building a full feature to generate insight. You focus on the smallest possible test that lets you learn.

How Robinhood validated pre-launch

Before building their trading app, Robinhood launched a waitlist landing page. The value prop was simple: ‘Commission-free trading.’ The main goal was a basic email sign-up, plus a referral loop that encouraged people to move up the list by sharing.

Source: kickofflabs.com

The result was over 1 million sign-ups before the app even existed.

But sign-ups alone weren’t the signal they focused on. They tracked several behaviors to understand the quality of that early audience:

Referral behavior: Were people sharing unprompted? (Yes, the viral coefficient was strong)
Email engagement: Did waitlist users open updates and ask about launch timing?
Willingness to act: When early access was offered to top referrers, did people actually work to earn it?

When you do eventually build a feature, it should usually be because something has been validated, and even then, you’re building it to answer a question, not just to add another piece to the product.

What does a learning roadmap look like?

A learning roadmap is structured around questions rather than features.

For each question, you should be clear on what you think the answer might be, how you’ll test it, and what would indicate whether you’re right or wrong.

The structure looks like this: Strategic Goal → Question → Hypothesis → Test → Success Criteria → Next Step.

It’s important that every question you try to answer is directly tied back to a broader strategic goal.

This forces you to be specific about what you’re trying to learn rather than just shipping and hoping.

For example, imagine you aren’t sure whether users understand the app’s value before they reach the paywall.

Strategic Goal: Improve the download-to-trial-started conversion rate.
Question: Do users understand the value before they hit the paywall?
Hypothesis: Users will better understand the app’s value if we show more visualizations of what the app looks like, directly linked to the benefits we’re measuring.
Test: Add a screenshot of the app to the benefits section instead of illustrations.
Success Criteria: A significant increase in the conversion rate at the first paywall.
Next step: If confirmed, explore other ways to communicate value more strongly. If disproven, test alternatives; for example, adding a short video before onboarding that shows the outcomes users can achieve.

Each question you’re trying to answer is essentially an opportunity to create value for your users.

The key insight, drawn from the work of Teresa Torres on continuous discovery, is to think about opportunities the way your customers would describe them, rather than in internal product language.

For example, you can reframe the question from the user’s perspective: “I don’t understand what this app does before I have to pay.”

Customer-centric framing like this helps you consider multiple possible solutions, and that’s why it’s important not to jump to the first test idea.

If a test, such as “adding a screenshot instead of illustrations,” fails, it doesn’t necessarily mean the underlying question is answered. You may need to explore several different ways to test the same hypothesis before reaching clarity.

The way I approach this is by noting down a few things first:

The quantitative data behind the question or hypothesis, for example, we see a very low trial-start rate while onboarding completion is already high.
The qualitative data that helps us understand the behavior further, for example, during user testing, we observed that people who clicked away from the paywall were still trying to figure out what the app actually does.
According to SOSA 2026, 55% of all 3-day trial cancellations happen on Day 0 — making the question of whether users understand your value before the paywall one of the most critical assumptions to test early.

From there, I work out multiple possible test ideas. For instance, in this example, you could also try:

Adding a short video to the onboarding that shows the app in action
Testing a feature carousel at the start
Showing a simplified “what you can do in the app” overview during onboarding

You can then return to the original question and evaluate which approach is most likely to help you gain clarity, given the insights you’ve gathered.

The three buckets: Now, Next, Later

If you’re wondering what you should be building 2–3 months from now, don’t worry, you really don’t need to know.

I’ve always said that a quarter in a startup can feel like a year in a corporation. Honestly, a month in an early-stage startup can feel like a quarter in a later-stage one. Things move fast, and thank goodness for expensive skincare and blonde hair to help hide the grey hairs I’m convinced startups are responsible for.

While your vision and strategy should be long-term, your roadmap can stay short-term. Trying to plan much beyond that usually just leads to endless rework.

I like structuring a learning roadmap into three time horizons: Now, Next, and Later; a framework popularised by Janna Bastow, which gives you permission not to do everything at once.

Your buckets can look like this:

Now (1–2 weeks): The most critical question you need to answer right now. Just one question. Maximum focus.
Next (2–4 weeks): The questions that are likely to come next, depending on what you learn from what you’re testing now. These are tentative rather than fully committed — for example: “If this happens, then we will do X”, based on the signals you’re seeing.
Later (backlog): Ideas and questions you want to explore eventually, but aren’t scheduling yet. These can and will change as you learn.

This approach keeps you focused while still allowing you to capture ideas without getting distracted.

If you’re anything like me, you probably generate a million ideas during the early phase. While long-term planning is hard, ideation usually isn’t, so having a backlog helps you park ideas and return to them later.

And honestly, a lot of ideas won’t survive that process (I have so many post-it notes with article ideas that, days later, make me wonder what I was thinking). So make a habit of tidying the backlog regularly.

How to prioritize what to learn

You can’t test everything at once; all those ideas and questions you want to explore will need to be prioritized ruthlessly.

This is where assumptions come in. Start by testing the assumptions that would undermine your strategy if they turned out to be wrong.

I usually think about three types of assumptions:

Problem assumptions. Do users actually have this problem and care enough to change behavior?
Value assumptions. Does our solution genuinely help in a way that users recognize?
Willingness to pay assumptions. Will enough users pay enough at this price point for the product to be sustainable?

It’s very simplified, but as a new subscription app, you are essentially trying to answer these questions pre–product-market fit:

Do users have this problem strongly enough to change behavior?
Do they understand the value before reaching the paywall?
Are they willing to pay at this price point?
What makes them come back after day one?
What’s the core action that predicts retention?

My suggestion is to test in that order. If the problem isn’t real, there’s no point in testing around value assumptions. If the solution doesn’t work, there’s no point in testing pricing.

From there, group related questions together; you’ll often find that many of them are connected. For example, returning to the paywall scenario, the question of “understanding value before the paywall” might break down into sub-questions such as:

Do they see what the app looks like?
Do they understand the outcomes they can achieve?
Do they know how long it will take to see results?

Grouping questions this way helps you identify the parent question to prioritize, and also reveals which sub-questions are likely to be answered together.

For example, if you’re building a sleep app and you’re unsure whether your audience struggles more with falling asleep or with staying asleep, that’s a problem assumption you can validate through user research.

Smaller tests, faster learning

Hopefully, you’re convinced by now that you don’t need to build a full feature to learn — and that, as a result, a traditional feature roadmap is somewhat limiting. The goal, instead, is to test assumptions with the least possible effort.

You’ve already seen how the waitlist approach worked for Robinhood, but there are many other options, too:

Prototypes. It’s never been easier to mock up prototypes using AI tools like Lovable.
Painted door tests. Here, you basically fake it till you make it, literally. You could show a fake feature button that isn’t yet functional.
Manual versions of features. If you eventually want to automate something, start by testing the human version first. For instance, you might want to build automated skin analysis and recommendations, but initially test having someone manually provide the advice.
Start with the first part only. For example, if you’re building a community feedback loop, you might begin by testing whether a simple “like” interaction is used, even if the downstream functionality isn’t built yet. In one case, the like action didn’t even trigger any visible response at the start, but it helped validate that users were willing to engage with that behavior.

If you want to go even lighter, you can start with research, such as browsing forums to validate the problem space or conducting user interviews before creating any mockups. For early-stage startups, user research is almost always a good investment of time.

What happens when you learn

Every test will lead to one of three outcomes:

Confidence goes up
Confidence goes down
The result is inconclusive

I’ll be honest, that last one kind of sucks, but I promise it can still teach you something. This gives you clarity on what to do next:

If confidence goes up, decide whether you need further validation, whether there’s more to learn, or whether you can move on to the next question.
If confidence declines, decide whether you need further validation, whether there’s more to learn, or whether you can move on to the next question.
If the result is inconclusive, it could mean several things: perhaps the change didn’t have the expected impact, there wasn’t enough data, or the test itself wasn’t the right way to answer the question. You can then decide the best next step based on the cause.

The goal isn’t to be right. In early-stage work, you will be wrong quite often, and that’s completely normal.

The real objective is to learn quickly enough that being wrong doesn’t become costly.

How to know you’re making progress

A learning roadmap can sometimes feel slower because you’re not shipping visible features. This is where trust can start to waver, for founders and teams alike.

Progress simply looks different, and part of adopting a validating mindset is redefining what progress means.

Progress can be seen in several ways:

You can articulate what you now know that you didn’t know before
You’ve eliminated solutions that don’t work (negative results are progress)
Your questions are getting more specific and focused
You’re converging on a smaller set of high-confidence opportunities
Your success criteria are becoming more measurable over time

Discussing regularly in sprint meetings what you’ve learned and understood, as well as small wins, helps you better see the progress that might not show up yet in your dashboards.

Common traps with planning your roadmap

Across the startups I’ve worked with, the same roadmap mistakes keep repeating. They’re rarely about effort or intent; they’re about how decisions are made.

1. Building before validating

This often shows up in disguise.

Teams will sometimes say they aren’t following a feature roadmap, yet a specific feature or update suddenly starts feeling inevitable. Everyone becomes convinced it’s important. When you ask what that belief is based on, the answer is usually something like, “we just know” or “we have to do this.”

That’s still building before validating.

Confidence is not the same as evidence. Even strong intuition needs to be grounded in research, data, or real user signals. The more excited you are about an idea, the more disciplined you need to be about pressure-testing it.

2. Too many priorities

If everything is a priority, nothing is.

A strategy is not ten parallel projects; it’s a clear commitment to one or two things that matter right now. Your roadmap should reflect that focus.

Be ruthless with your “now” bucket. If you’re trying to answer several big questions at once, you’ll likely make shallow progress on all of them and meaningful progress on none.

3. Vague success criteria

“We’ll see if users like it” is not a success criterion.

“It’s slightly better” isn’t either.

Early on, statistical significance isn’t always possible, and that’s fine. What matters is being explicit about what success looks like before you start.

Ask yourself:

What signal would make you confident enough to continue?
What outcome would clearly tell you to stop?

Also, think through secondary metrics in advance. For example:

If the main metric doesn’t improve but another one does, what would you do?
If the main metric improves but something else worsens, is that acceptable?

Planning these scenarios early prevents a lot of post-hoc rationalization.

4. Ignoring negative results

It’s tempting to explain away data that doesn’t confirm what you want to believe. As one speaker once said, “If you torture the data enough, it will always confess.” That idea has stuck with me because it’s painfully true.

There will almost always be a way to frame results as “not that bad” or to cherry-pick supporting slices of data. Clear success criteria help protect against this, but mindset matters too.

Negative results aren’t something to be ashamed of. Most things won’t work; that’s completely normal. Treat failed experiments as learning rather than something to justify away. That’s what actually moves teams forward.

5. Never moving on

The final trap is getting stuck in testing mode.

Testing can feel safe because there’s always one more variant to try or one more week of data to collect. But at some point, you need enough signal to make a decision and move forward.

Roadmaps are not about infinite validation — they’re about building confidence and then committing.

Be honest with yourself about whether more testing will actually change your decision, or whether it’s just a way to avoid making one.

Some signs you’re ready to move on:

You’ve tested across 2–3 cohorts, and the pattern is consistent
The signal is strong enough to justify allocating resources (not just “slightly positive”)
Further testing is unlikely to change your decision
You’re delaying commitment rather than genuinely learning

Use this list of common mistakes to keep yourself in check; you can even use it as part of a sprint retrospective. Going through the following questions as a team:

Were there any cases where we built before validating?
What are our top priorities? Do we need to narrow them down?
Are the success criteria of all the experiments clear enough?
What were the ‘negative’ results this sprint? What did we learn from them?
Is it time to move on from any focus areas?

Stay the course, refine or pivot?

In Eric Ries’s Lean Startup framework, there’s a recommendation to hold regular (often monthly) meetings to decide whether to pivot or persevere, essentially, whether to change direction or stay the course.

I agree with the methodology, but the binary framing can feel a bit too black-and-white. The decision is usually not as simple as either killing an idea or continuing unchanged. Sometimes something is working partially, and the pressure to choose between pivoting and persevering can push teams toward perseverance because pivoting feels scarier. That’s where sunk cost fallacy starts creeping in; you’ve invested so much that it’s hard to step away.

Instead, I prefer thinking about it in three options:

Stay the course (persevere). When the core hypothesis is confirmed, focus on execution and iteration.
Refine. The direction is generally right, but some details are wrong. This isn’t about small optimization; it’s about making a meaningful adjustment, such as changing the target audience, refining positioning, or altering features.
Pivot (or kill). The core hypothesis is disproven, meaning you need to fundamentally rethink the problem, the user, or the solution.

Most launches don’t need a pivot; they need refinement. A true pivot should only happen when evidence clearly contradicts your core assumption about the problem or user, such as when target users don’t perceive value or when there are no meaningful signals of monetisation.

A well-known example of a major pivot is that of Instagram. Originally launched as Burbn, the product started as a check-in app with many features.

After launch, the data showed that:

Most features were being ignored
Photo sharing had unusually strong engagement

The founders stripped away everything except photos because they realised their core hypothesis was wrong: users weren’t primarily looking for a check-in app or the broader feature set. Instead, they doubled down on the signal with the strongest user engagement and pivoted around that.

When can you move on from a learning roadmap?

A learning-style roadmap isn’t meant to last forever.

At some point, it can start to lose its usefulness. Instead of providing clarity and direction, it may begin to feel like a long list of unresolved questions. As teams scale and the number of initiatives grows, a pure learning roadmap can sometimes create more noise than focus.

This is usually a sign that you’re getting closer to product–market fit.

As confidence increases, the balance naturally shifts. Post–product–market fit, you tend to have a clearer understanding of who your users are, what they want, and which problems truly matter. At that stage, a more traditional, feature-oriented roadmap (still focused though on outcomes) often becomes more practical.

That doesn’t mean learning stops.

Markets evolve. User behavior changes. Competitors improve. The difference is that the focus moves from mostly learning with some building to mostly building with some learning.

You’re no longer questioning everything, but you still leave room to validate key assumptions and challenge strategic direction when necessary.

In that sense, a learning roadmap is what helps you reach the point where a feature roadmap actually starts working.

Building roadmaps around questions, not outputs

So remember, in early-stage subscription apps, strong roadmaps are built around questions — not features, not incremental improvement points, and definitely not growth for growth’s sake.

A simple structure works well:

What are we doing now?
What are we doing next?
What comes later?

Your backlog belongs firmly in the later bucket.

The real work is being ruthless about identifying the assumptions that could undermine your idea if they turn out to be wrong, and prioritizing those first.

Start by testing small and moving quickly. Only then should you expand and build with greater confidence.

This approach can sometimes feel slower because you’re shipping less. In practice, it’s usually faster. Teams that default to constant building often spend months delivering features that nobody actually wants. Starting with learning helps avoid the waste of building things just for the sake of building.

If you want to go deeper into defining your strategy and identifying the right questions to answer, you can explore my full course on building an app that people will pay for.

Recapping App Monetization Seoul

Fri, 24 Apr 2026 10:46:55 GMT

On April 10, monetization leaders from Korea’s top apps came together at Boutique Monaco in Seoul for a night of honest conversation about how apps actually make money. The event, App Monetization Seoul, was co-hosted by DARO, RevenueCat, and EHVM Apps Capital.

There was a great turnout with C-levels, growth leads, and product folks from companies like Google, AppsFlyer, Toss (Viva Republica), Healing Paper, Moloco, Criteo, SNOW, and CJ. The mix of ad-side and subscription-side practitioners in the same room was what made the evening work.

Two levers that drive ad revenue

Eungil Cho, BD Manager at DARO, opened the evening. His framing was simple and hard to argue with. Ad revenue comes down to two levers: eCPM and impressions. Getting one of them right is not enough. The teams that win are the ones that balance both and build a culture of continuous experimentation around them.

The point landed because the insights came out of DARO’s own experience running ad monetization for Alarmy, the number one alarm app globally built by Delightroom. Real numbers, real trade-offs, no slideware.

What actually moves subscription revenue

Rik Haandrikman, VP of Growth at RevenueCat, spoke next: his session pulled from the State of Subscription Apps 2026 data across 115,000 apps on the RevenueCat platform. The talk cut through a lot of the rumours floating around about paywalls, pricing, and trials, and replaced it with what the numbers actually say.

If you have been guessing at what drives subscription revenue, the answer is that most of the industry is guessing too. The signal, when you zoom out across that many apps, is sharper than you would think.

The global opportunities founders keep missing

The night closed with a panel on global monetization. Evelin Herrera, CEO of EHVM and the person behind more than 150 mobile app and game M&A deals, joined Rik and Seunghwan Stephan Seo, Chief of Staff and Product Owner at Delightroom.

The conversation kept coming back to the same point. Korean app founders have world-class products, but many of them leave real revenue on the table because they underinvest in markets outside their core. Evelin’s view from the deal side, paired with Stephan’s operator view from Alarmy’s global playbook, made the case concrete.

Finger food and frank Q&As

The last 90 minutes were networking over finger food. This is the part of these events that is hard to engineer and easy to get wrong, but conversation flowed and the food was great. Conversations that started in the Q&A kept going through the networking, which is usually the sign of a room full of the right people.

Thanks to everyone who came out.

Yes, you can build a subscription app with AI (but it might hurt a bit)

Thu, 23 Apr 2026 12:03:43 GMT

We’re in the middle of an AI-fueled hype cycle where it feels like everyone is building apps in a weekend and making $100K a month. It is as exciting as it is misleading.

“Your app, OnTimer – Never Be Late, is ready for distribution.”

When I finally saw that message from Apple’s review team, I knew two things were true:

Yes, you can build your own mobile app with AI
You’re probably not going to do it in a weekend (it took me four months)

I like to joke that any idiot can build an app now — just ask me how I know. But we really are living in an amazing moment. Great ideas have never been limited to a specific set of people; anyone of any background, education, or technical ability can have a million-dollar idea. The limit has always been whether those same people have the technological know-how to turn that idea into reality. Now, as we’ve all seen, AI has erased that limitation.

The reality behind vibe coding your first app

I don’t know how to code.

When I started building the app in November 2025, I was just trying to see what was possible with vibe coding. But each time I got something to work, or fought through a bug, I got more determined to see it through.

Seeing the app in the App Store and getting my first customers has been incredibly rewarding. It was also harder than I expected.

So yes, you can vibe code a real subscription app. Is it as easy as everyone says? That’s a more nuanced answer. But I’m going to share what I learned so you can do it too, and maybe even avoid some of my mistakes.

Lesson 1: don’t wait for the perfect idea, build something

If you’ve ever gotten a frustrated text from a colleague saying, “We’re all on the Zoom, are you joining?” then you’ll understand OnTimer’s origin story.

Every morning, I used to check my calendar and set alarms two minutes before my meetings. I hate being late, and regular calendar notifications are too easy to ignore. I needed something more persistent, otherwise I’d just keep writing that email or staring at a chart.

So when I wanted to see what was possible with vibe coding, I didn’t go looking for the perfect idea, I just automated my own behavior.

I didn’t know if it could make money, I didn’t know how many other people shared the problem. I just knew I didn’t want to wait.

In a world where you can build anything, paralyzing yourself in search of that perfect, differentiated idea, is a great way to get stuck doing nothing.

So when I saw a LinkedIn post for Supervibes, ‘The vibe coder for native apps’, I got to work.

Lesson 2: pictures are not products, and AI often doesn’t know the difference

I was blown away when my initial prompts transformed my vision for OnTimer onto the screen in minutes. It’s almost intoxicating to see your app come to life like that.

But I quickly learned that there is a big difference between what you’re seeing and what is actually working. This has been a recurring theme throughout the process.

I knew oAuth would need real setup, that was expected. What I didn’t expect was that the AI would fake things that actually mattered to the user experience.

When Supervibes initially coded the app with fake calendar data, that seemed acceptable as a starting point. But it also ‘faked’ things that would come back to bite me. On the homescreen it had created a sync icon with text that said, “Auto-syncs every 15 minutes”. As it turned out, this wasn’t a feature or setting — it was pure window-dressing, but I didn’t know to question it.

It took me about a week to get oAuth and the initial calendar connections working. When my Xcode-connected test phone fired its first OnTimer alarm for a meeting, it was the first time I started to believe this could work.

But remember earlier how I told you I was an idiot? This is where that comes back into focus.

With the core functionality ‘working’, I spent my nights and weekends slogging through the App Store’s somewhat-convoluted process and finally sent a first build to TestFlight.

That was eye-opening, and not in a good way. The full screen alarms that worked so well on my test phone, when the app was in the foreground, didn’t work at all when the app was in the background. And since the automatic sync was fake, OnTimer’s never be late promise was pretty empty.

I eventually switched from Supervibes to Claude Code, but this is a ‘gotcha’ across AI tools. The ‘pictures’ they paint feel real, but pictures aren’t products. The inconsistency between what was hard-coded in, and what wasn’t, made it near-impossible to differentiate between whether something was built and functional, or just a convincing visual.

If I could go back, I would have spent a few hours with a whiteboard before writing my first prompt and asked:

What does success look like at each stage?
What qualifies as working?
What are my expectations as a user?

Lesson 3: your simple app might actually be more complex than you think

Sharing that first version on TestFlight early turned out to be a great decision. The feedback was swift and painful.

Connecting oAuth turned out to be the easy part. Building a persistent notification system that works in the background is not. Making the never be late guarantee work when a phone is silenced is not. Syncing multiple calendars reliably is not. Every time I solved one challenge, a new one seemed to appear.

This is somewhat the nature of AI: what you see from the outside appears functional and sleek. Even when a problem arises, it seems to be resolved fairly simply. But behind each challenge and subsequent resolution, the respective jerry-rigged solutions become knots that come back around to haunt you. Because we only see the front of the AI tool, it often appears problems are solved, when actually they’ve just been plastered over.

I learned quickly that there is a lot of complexity in building a ‘simple’ app. As a vibe coder, this is where you are kind of on your own.

On a team, you have people and experience to think this stuff through. Often you avoid pitfalls because your engineers have already run into them before. With vibe coding it’s just you and an LLM. If you don’t ask the right questions, it’s hard to know what’s coming next.

Here’s what I should have done differently:

Asked an LLM to compare my plan to app store rules and iOS limitations
Created a ‘Perfect.md’ file that described the ideal end-to-end user experience and forced Claude to align every change to it
Talked through my idea with others (humans!) to uncover challenges early

Lesson 4: the vibe coding landmines are scary, but they aren’t deadly

Three or four times as I was building OnTimer, I hit walls that seemed insurmountable. I ran into issues that brought everything to a halt, and pushed me to the edge of my sanity.

A few weeks in I got caught in a cycle. Identify bug → prompt Claude to fix → Claude says “Perfect, I fixed it” → nothing changes → repeat

My prompts eventually devolved into me telling Claude to “Go F%ck itself” which didn’t help.

In a moment of desperation, I asked Claude to show me how to manually make a change to one word on my homescreen. I was losing my mind, and Claude couldn’t even make the simplest of changes, let alone fix the bug.

Then I saw my manual change instantly revert itself. I didn’t know why, but I finally saw what was happening. It turned out an update I made was causing new code to save to a backup drive, while the live file stayed static.

It was a week of hell, for what turned out to be a five-minute fix.

The problem with vibe coding is that you don’t have the same instincts or approach engineers have. We can’t look at the code the way they can. When things break, it’s easy to get lost.

But here is what I learned: don’t keep doing the same things over and over that aren’t working, and don’t let Claude (or *insert AI tool*) do it either. Even when you try to prompt root cause analysis, it can have a tendency to just keep trying to fix the same area of your code. You have to get it out of its own way.

A good tactic I have found is to use another LLM to challenge Claude. If a fix doesn’t work I bring in ChatGPT:

I share the Claude Code thread and relevant files, and ask ChatGPT for a fresh analysis and prompt
I send the prompt to Claude in Plan mode, and go back and forth between the two LLMs
When it’s fixed, I update my Claude.MD file with a detailed explanation to prevent similar issues in the future

Bugs are probably the worst part of vibe coding. They’re not just time-killers; they rob you of your confidence. It’s not fun, but the more you battle through these, the faster and better you get at it.

Lesson 5: monetize early, you won’t regret it

From the beginning I knew I was going to launch OnTimer as a subscription app. Monetizing your app forces you to focus on value delivery and product-market fit. Those are great forcing functions, even when you are still learning.

You will have to make real decisions: freemium vs. paid, free trial lengths, what lives behind the paywall and what doesn’t. I chose freemium with an annual subscription. The free tier lets users experience the core alarm functionality. The paid tier unlocks multiple calendars and Time-to-Leave departure alerts.

Figuring out what to place behind the paywall forced me to ask myself what was valuable enough to pay for, and what needed to be free to get someone hooked. That thinking made OnTimer a better app.

Monetization adds layers:

App Store complexity: subscription apps get more scrutiny from reviewers, and rejections are more painful when you’re trying to ship
Entitlement logic: your app needs to know what a user has paid for, and show it appropriately
Paywall considerations: a bad paywall doesn’t just hurt conversion, it can get your app rejected entirely

Fortunately, RevenueCat makes this a lot faster and easier. They provide an integration prompt for vibe coders, which was like magic.

I fed it into Claude and within minutes I was walking through RevenueCat’s setup guide. In less than a day I had a working paywall.

It wasn’t perfect. I did get rejected from the App Store twice because of a paywall issue — a nuance in the RevenueCat UI builder looked correct visually but wasn’t behaving right in practice, reverting to a default state rather than the one I’d selected. I hit customer support, quickly got it sorted, and finally got OnTimer approved.

What was cool though, is that I went back into the paywall builder a few days ago, and the issue I ran into had been fixed. It’s great when your feedback helps the next developer avoid the same pitfall.

RevenueCat did the heavy lifting so that I could focus on developing the app’s core value. They handle the logistics of your subscription infrastructure so you can stay focused on building something people want to pay for.

So, I really encourage you to monetize early because:

It forces honest conversations about value: if someone won’t pay for it, that’s information — find out early
Subscribers give better feedback than free users: they have skin in the game and they want it to work
Revenue changes your psychology: even a few dollars a month makes you more serious about shipping and improving

Go build your first app, it’s worth it

You should absolutely go build your first app. It’s not as easy as the hype makes it sound. Things break, and you hit walls. You have moments of real frustration and doubt.

But you also have moments of amazing accomplishment. Yesterday I had a doctor’s appointment, and OnTimer’s Time-to-Leave feature fired off an alarm based on traffic and distance.

I built that!

…Okay, Claude helped.

The point is that vibe coding is real. You may not make $100K/month right off the bat like many on LinkedIn and X would have you believe — it will probably take longer than you expect. It took me about four months to launch. But if you push through the hard parts, you can build something you are proud of.

Now I’m shipping, learning, and even starting to see the first signs of revenue. The next challenge is growing it, and that’s going to be hard too.

But I’m in it now, and you can bet this won’t be the only app I build.

AI got me started. Persistence is what got me here.

Check out OnTimer – Never be late on the App Store!

How to add trial notifications to your subscriptions

Wed, 22 Apr 2026 14:50:05 GMT

Free trials are one of the best ways to convert users into paying subscribers — but they can backfire. When a user forgets they started a trial, the unexpected charge feels like a betrayal. They refund, leave a bad review, and never come back. Even worse, that one bad experience can make them reluctant to try any subscription app again.

A simple reminder notification a day or two before the trial converts changes the dynamic entirely. The user feels respected, not tricked. They either cancel (which they would have anyway) or they convert knowing exactly what they’re paying for. Either way, you build trust — and trust is what drives long-term retention.

I’ve written about building trial reminders before using RevenueCat and Zapier to power email-based notifications. In this tutorial, we’ll build a similar system using local and remote push notifications in React Native — though the same concepts apply to Kotlin and Swift.

How to plan trial reminders

Trial reminders don’t have to be complicated, but sending out more than one reminder builds trust, and removes uncertainty. I would recommend a lightweight three-notification pattern:

1. Activation nudge (same day)

Send a notification on the first day, highlighting a feature they have not yet tried, in order to signal that the notifications work, and to get them to experience their first “aha moment” during the trial.

2. Mid-trial reminder (two days before end)

Two days before the trial is about to expire, remind them that the trial is ongoing and that it will expire in the next few days. You will most likely see users cancelling their trial at this point — that is to be expected. That gives you a chance to capture them with a win-back offer, for example.

3. Trial-ending alert (morning of last day)

On the morning of the last day, send a transparent, helpful reminder:

“Your trial ends today. Keep access by staying on your plan — or cancel anytime.”

How to implement trial notifications in React Native

There are two approaches: local notifications (no server needed) and remote notifications (requires a small backend). We’ll walk through both, starting with local.

Local notifications approach

With local notifications, all the reminder logic lives on the device — no server needed. When a user starts a trial, you grab the trial expiration date from RevenueCat’s customerInfo.entitlements (specifically the expirationDate on the active entitlement), then schedule notifications relative to that date.

Local notifications are the simplest approach — very little code and no backend to maintain. The trade-off is that the notification schedule can only update when the user opens your app. If someone cancels their trial through the App Store settings page, for example, the app won’t know to unschedule the reminders until it’s opened again. The same applies if they switch to a plan without a trial.

Additionally, local notifications will fail if the user’s device is powered off, and orchestrating other notification channels such as email is harder with local notifications. Some Android phones also have limitations on delivering local notifications at the exact scheduled time.

Remote notifications

The alternative to local notifications is a server-driven approach. You run a lightweight backend that listens for RevenueCat webhook events and schedules or cancels trial reminders accordingly.

This approach takes more work to set up, but it’s significantly more reliable. You can update notification content without shipping an app update, use multiple channels (push notifications and email, for instance), and cancel reminders immediately when a user unsubscribes — no app open required. The backend itself doesn’t need to be complex: a single endpoint that digests webhooks and schedules notifications is all you need.

On the client side you only need to take care to store users’ push notification token, which is something RevenueCat can actually help you manage. You can save push tokens in Attributes, from which they are available using either REST API or Webhooks.

Choosing a notification package to use

React Native does not come with notifications included, so you need to install and configure an external dependency to run them. Here are a few options that support both remote and local notifications:

Expo Notifications
Expo notifications is excellent for notifications, especially if you have an Expo project. This tutorial will use Expo Notifications for the examples.
react-native-notifications
Wix has been maintaining their own notification package for React Native for over 10 years already. It’s stable and has all the features you need for notifications.
@notifee/react-native
Notifee is a feature rich notification library for both iOS and Android. It’s especially powerful when you want rich notifications, with images, custom sounds and interactability.

Subscription reminders with local notifications

The next parts assume that you’ve installed and configured your notification package for your project.

Step 1: create a trial schedule object

We will want to remind users three different times, so let’s build a trial object that will be used for scheduling when and containing the messages we want to send. The following trialSchedule follows the 3-part trial reminder structure we discussed earlier.

Step 2: schedule notifications during subscription process

Scheduling the trial reminders will happen when users subscribe. We can use getCustomerInfo to check if user is running a trial:

Step 3: unschedule notifications on unsubscribe

Subscription reminders with remote notifications

Step 1: store users’ push tokens

The first step to adding remote trial notifications is to track the users’ push tokens. This is made easy with RevenueCat Attributes, where you can store additional structured information about customers. These attributes can later be read using the REST API.

If you take a look at the documentation for Attributes, you see that both $apnsTokens and $fcmTokens are reserved attributes. This means that we can store push tokens in RevenueCat as well. Doing that through code is just a few lines:

That is all that is needed from the client side, as long as you have configured your notifications correctly. The rest of the tutorial will focus on what needs to happen on the server side.

Step 2: build a notification backend

All of the logic for trial reminders will happen on the backend side. For this we need to build an endpoint that accepts webhooks from RevenueCat and then schedules notifications based on those. To understand which types of Webhook events we need to support, we can take a look at the webhook sample events.

In this example we are going to use a Cloudflare worker, but it’s not a requirement. You could also build this using Zapier and OneSignal.

Here’s some example code:

Let’s go through the main functions of the code.

Unwrapping the webhook payload is the first step.

The POST request from RevenueCat webhook is sent to our worker which then unwraps the contents. In this case the interesting parts are:

period_type, tells us if the subscription is TRIAL type
purchased_at_ms, tells us when user made the purchase
expiration_at_ms, tells us when the trial will convert
subscriber_attributes, from here we can get the push notification token to use

Scheduling notifications

In our code we check first if the purchase is trial type, then we schedule a notification 6 hours from that if the purchase was made before 12pm, otherwise we schedule it for the next day. Then we schedule a mid-trial reminder 2 days before the trial ends. Last scheduled reminder is set for the morning of the expiring subscription. If the subscription expires in the morning, we schedule it for the evening of the previous day.

Unscheduling notifications

The last logic we have for the apps is that we unschedule the notification if the user cancels the trial. In this case we monitor for the cancel_reason being UNSUBSCRIBE and then remove the scheduled notifications.

Running logic to send notifications periodically

The last part of the code is that we run a different worker every hour to send notifications to users based on their scheduled times. This is done through a cron job.

Step 3: enable webhooks in the RevenueCat dashboard

Navigate to the RevenueCat dashboard, and select the Integrations tab from the sidebar. Under Core Tools, select Webhooks. Click Add Webhook and set the Delivery URL to your worker endpoint (e.g. https://your-worker.your-subdomain.workers.dev). Set the Authorization header to match the RC_WEBHOOK_SECRET you configured in your worker. Make sure to enable at minimum the INITIAL_PURCHASE, CANCELLATION, EXPIRATION, and TRIAL_CONVERTED event types.

Wrap-up

Trial notifications are one of the fastest, lowest-effort ways to improve trial quality and conversion. With clear data (purchasedDate, expiresDate) and a small amount of React Native code, you can build a trust-first notification flow that feels more like Blinkist — transparent, helpful, and user-centred.

Start with the three-message sequence, keep the messaging honest, and iterate based on user behavior. You’ll see the lift.

How an email list became a 15-year safety net for a solo app developer

Wed, 22 Apr 2026 12:58:17 GMT

The personal workaround that became a business

Teleprompter Pro didn’t start with market research; it started with a frustrating freelance video gig. In 2010, Joe was a 19-year-old freelance videographer working on a low-budget pilot. They needed a teleprompter, but he was “too cool to write on a piece of paper and hold it.”

He tried using Apple Pages on a first-generation iPad to scroll text, but the experience was clunky. He couldn’t even easily get a black background. Having recently downloaded Xcode, he decided to build a simple scrolling text app himself.

“It just sort of moved some text up,” he recalls. But when he put it on the App Store alongside a few other random projects, it was the only one that gained traction. It solved a genuine problem for people doing video production. For the next seven years, that simple utility app generated steady, organic revenue while Joe worked a full-time job in web and graphic design. It wasn’t until 2018 that the app’s revenue allowed him to quit his job and go full-time indie.

The App Store river and the illusion of control

Many developers attribute every spike in downloads to a brilliant new feature they just shipped. Joe takes a more humbling view of his app’s growth trajectory.

“I think we assume that literally everything is happening to us and that we’re responsible for any of the success,” he notes. The reality is that the App Store is a massive river. Sometimes your app is just sitting right in the current, benefiting from a small algorithmic tweak or a new search trend.

Joe embraced this reality early on. “We’ve never, ever had a day of zero revenue ever,” he says, even during the years when he was barely updating the app. Accepting that he didn’t control every single variable freed him from constantly chasing the algorithm. Instead, he could focus on building a reliable product and let organic momentum do the heavy lifting.

The unexpected ROI of personal customer support

When Joe finally transitioned to full-time indie development, he found himself spending an enormous amount of time answering customer support emails. Many were simple questions—like explaining that a user’s orientation lock was on—but he felt a deep responsibility to ensure every user got a helpful answer.

While it consumed his working days, that direct line to users became his most valuable product research tool. “A lot of questions we get are just super simple… but I sort of feared that that would turn into one-star reviews or someone abandoning the product,” he explains.

Those conversations led to crucial feature additions, like adding a video recording option, and eventually highlighted the need for better onboarding. More importantly, taking the time to personally respond built immense goodwill. Users who were initially frustrated often became loyal advocates, simply because they received a genuine reply from the app’s creator rather than an automated corporate response.

Why an email list is the ultimate safety net

If there is one piece of advice Joe insists on, it’s the importance of owning your audience. From the very early days, he asked users for an email address. He didn’t have a grand marketing plan; he just liked the idea of being able to announce cool things to people.

That simple decision became the foundation of his business stability. “I’m quite convinced that that is the single most important thing I ever did for my career,” he says.

When he transitioned Teleprompter Pro from a paid upfront model to a subscription model in 2020, he didn’t have to rely on App Store release notes to communicate the change. He could email his users directly, explain that existing customers were grandfathered in, and offer a discount to those on the fence. When he launched his new app, Captions (Recap), earlier this week, he emailed a segmented list of users who actively record video, offering them the Pro upgrade for free if they pre-ordered.

The App Store algorithm can change overnight, but an email list ensures you never have to start from zero.

In the full episode, Joe also discusses the stress of navigating an unexpected “spam” rejection from App Store Review for his new app, the benefits of attending industry events, and why slow, steady growth is often the healthiest path for indie developers.

Guest links:

Build web funnels with Stripe Billing and Managed Payments in RevenueCat Web

Wed, 22 Apr 2026 12:03:04 GMT

If you build on Stripe and want a merchant-of-record path for web, you can now do more in RevenueCat Web: by using Stripe Billing and Stripe Managed Payments across Web Purchase Links, Web Paywalls, Funnels, and the Web SDK.

This gives you a powerful toolkit to build web purchase flows, with Stripe at the center of billing and checkout. For eligible flows, you can also use Stripe Managed Payments, which adds a Stripe-native merchant-of-record option to the same web monetization path.

Stripe in RevenueCat Web

As web monetization becomes a bigger part of your app business, your stack needs to hold together. You want purchase flows on the web, billing that still makes sense, and tools that don’t force you to rebuild everything around a new system.

With RevenueCat Web, you can now combine Stripe Billing and Stripe Managed Payments with the touchpoints you already use to launch and scale purchase flows like your paywall and checkout. Billing, checkout, and web monetization can now work together in one Stripe-based path inside RevenueCat Web.

Across paywalls, links, funnels, and the Web SDK

This support shows up in the places where you build and sell. You can use Stripe-backed billing and checkout across the main RevenueCat Web features that shape your web monetization journey.

Features	What you can do
Funnels	Build end-to-end acquisition and conversion flows on top of Stripe
Web SDK	Build Stripe-powered purchase flows directly into your web experience
Web Purchase Links	Launch shareable purchase flows backed by Stripe Billing and Managed Payments
Web Paywalls	Present web paywalls tied to Stripe-backed products and checkout

That range matters. You are not adding one checkout button to one page, you’re bringing Stripe into RevenueCat Web across the touchpoints that support acquisition, conversion, and lifecycle flows.

Stripe Managed Payments in RevenueCat Web

If merchant-of-record matters to you, this release matters even more. It affects how you handle tax, operational overhead, and the structure of your checkout flow.

Alongside Stripe-backed billing in RevenueCat Web, you now have a path to use Stripe Managed Payments for eligible flows through Stripe Checkout — which is especially relevant if you want a merchant-of-record model without moving away from Stripe.

The benefits are straightforward:

More choice in how you build on web
More continuity with your existing Stripe setup
A clear Stripe-based path to merchant-of-record in RevenueCat Web features you use to drive conversion

How the stack works

Each part of the Stripe stack plays a different role:

Stripe Billing handles your subscription and billing setup
Stripe Managed Payments gives you a merchant-of-record model for eligible flows
RevenueCat Web brings those pieces into the paywalls, links, funnels, and SDK flows you use to sell on the web

Layer	What it means for you
Stripe Billing	Your subscriptions and billing system live in Stripe
Stripe Managed Payments	You get Stripe’s merchant-of-record model for eligible flows
RevenueCat Web	You use these capabilities across paywalls, links, funnels, and SDK-driven experiences

You can keep Stripe at the center while using RevenueCat Web to launch and optimize the purchase experience around it.

More app teams now treat web as a serious monetization opportunity. This changes what you need from your stack. You need purchase flows that fit your product, billing that fits your business, and infrastructure that supports how you test, package, and iterate on the web.

By combing Stripe Billing and Stripe Managed Payments with RevenueCat, you now have a stronger option to do just that.

Start building

If you already use Stripe and want to bring merchant-of-record into your web monetization setup, now is a good time to take a closer look. You can build Stripe-powered purchase flows in RevenueCat Web with support for both Stripe Billing and Stripe Managed Payments.

Start with the docs, review the setup and eligibility details, and map the first flow you want to launch. You can also join us at our Stripe Sessions pre-event on April 28th to see how app teams are approaching web funnels, web-to-app, and app-to-web growth: Reserve your spot.

If you are building on web with Stripe, you now have a stronger path to do it in RevenueCat.

Announcing Paywall rules: show or hide paywall components

Wed, 22 Apr 2026 10:02:06 GMT

RevenueCat Paywalls is the easiest way to build custom paywalls for your app. Combined with RevenueCat Targeting, it allows you to serve a different paywall to different customers without having to make new releases. And now, with the release of the new Paywall Rules feature you can take personalized paywalls even further, without having to make new paywalls.

Paywall Rules allow you to customize the visibility of paywall components based on both preset and Custom Variable based rules, enabling you to customize a single paywall to support multiple scenarios.

Hides components when a package is selected, and more

What do Paywall Rules look like in practice?

One example is using Paywall Rules to show a trial timeline only when a trial is available, or to display a different package based on a custom variable.

Paywall Rules supports the following rules at the moment:

Rule	When the rules will take effect	What Rules are available
offer.intro	If the user selects a package that includes an introductory offer	Visibility and text overrides
offer.promo	If the user selects a package that includes a promotional offer	Visibility and text overrides
package.identifier	If the user selects a package that matches the defined identifier	Visibility only
Custom variable	If the paywall is rendered with or without the defined custom variable.	Visibility only
offer.multiphase	If the user selects a package that includes a promotional offer	Text overrides only

How to create your first Paywall Rule

To create a Rule for your paywall, navigate to paywall editor and select the Paywall logic tab from the left sidebar. You will see the following button to create a new rule:

Creating a rule has two parts:

Selecting the Rule that will control component visibility
Selecting either existing or new components that the rule will be applied to

A purple highlight around the preview indicates that you’re viewing how paywall look like with Rule applied.

When viewing your rule, any component that you add will be set to only be visible for that Rule. You can edit this later if you require the component to be visible in more cases.

Rules are evaluated at runtime, after publishing your paywall, which allows multiple rules to exist on a component. Rules are applied to a component in the order defined in the table above. Custom variable rules are evaluated in alphabetical order.

Current limitations of Paywall Rules

Paywall Rules are supported on most components that you can add to your paywall, with the following limitations:

Express checkout buttons
Individual pages of a carousel
Individual tabs
Footer
Sheet
Purchase Button

Wrapping up

Paywall Rules make it easier than ever to build smart, context-aware paywalls without the overhead of maintaining multiple paywall variants. Whether you want to highlight a trial offer, swap out packages based on a custom variable, or tailor messaging for promotional offers, a single paywall can now handle it all.

As we continue to expand the supported components and rule types, we’re excited to see the creative ways developers and growth teams use this feature to drive conversions.

Give Paywall Rules a try and let us know what you think 👉 Paywall Rules documentation

Exit Offers in RevenueCat Paywalls: A Practical Guide for Android

Wed, 22 Apr 2026 00:39:29 GMT

When a user dismisses your paywall without purchasing, the conversion opportunity is lost. Exit offers change this by presenting a second offer at the moment of dismissal, typically a lower price, a longer trial, or a different plan. This is the same strategy e-commerce sites use for cart abandonment: catch the user on the way out with an alternative they might accept. RevenueCat’s paywall system supports exit offers as a dashboard configured feature that requires no code changes, but only if you present your paywall the correct way.

In this article, you’ll explore how exit offers work on Android, why the presentation method matters, how to configure them in the RevenueCat dashboard, the correct code for both PaywallDialog and PaywallActivityLauncher, and the common mistake that silently prevents exit offers from appearing.

What exit offers are and when they trigger

An exit offer is a secondary paywall that appears automatically when a user dismisses your primary paywall without making a purchase. The flow looks like this:

User sees the main paywall (e.g., an annual plan at $49.99/year)
User taps the close button or swipes to dismiss
Instead of closing, a second paywall appears with the exit offer (e.g., a monthly plan at $4.99/month)
User either subscribes to the exit offer or dismisses again, which closes everything

The exit offer is a separate offering configured in the RevenueCat dashboard. It has its own paywall design, its own packages, and its own pricing. The SDK handles the transition between the main paywall and the exit offer automatically.

Exit offers do not trigger when the user has already completed a purchase. If the user subscribes on the main paywall, the paywall closes normally without showing the exit offer.

The presentation mode requirement

This is the most important point in this article: exit offers only work with PaywallDialog and PaywallActivity on Android. They do not work with the Paywall composable embedded directly in your layout.

Presentation method	Exit offers supported
`PaywallDialog` (Composable)	Yes
`PaywallActivityLauncher` (Activity)	Yes
`Paywall` composable (embedded)	No

The reason is structural. PaywallDialog and PaywallActivity control their own dismiss flow. When the user taps close, the SDK intercepts the dismiss action, checks if an exit offer is configured, and presents the exit offering before actually closing. The Paywall composable, on the other hand, is embedded directly into your Compose layout. It has no concept of “dismiss” because it is just a composable in your navigation graph. There is nothing to intercept.

If you are currently using the Paywall composable and want exit offers, you need to switch to PaywallDialog or PaywallActivityLauncher. The migration is straightforward and covered in the sections below.

Setting up exit offers in the dashboard

Exit offers are configured entirely in the RevenueCat dashboard. No code changes are required once your paywall is presented with a supported method.

Create the exit offer offering. In your RevenueCat project, create a new offering (e.g., “exit_offer_monthly”) with the packages you want to show as the exit offer. This could be a discounted monthly plan, a longer free trial, or a different product entirely.
Create a paywall for the exit offer offering. Attach a paywall to the exit offer offering using the Paywalls editor. Design it as you would any other paywall. This is the screen the user will see after dismissing the main paywall.
Link the exit offer to your main paywall. In the Paywalls editor for your main paywall, open the exit offer settings and select the exit offer offering you created. This tells the SDK which offering to present when the user dismisses.

Once linked, the exit offer is live. The SDK handles preloading the exit offering data, intercepting the dismiss action, and presenting the exit offer paywall.

Presenting with `PaywallDialog`

PaywallDialog is the recommended way to present paywalls in Compose. It displays the paywall as a full screen dialog on compact devices and a standard dialog on tablets. Exit offers work automatically.

The simplest setup uses setRequiredEntitlementIdentifier to show the paywall only if the user does not have a specific entitlement:

If you need custom display logic, use setShouldDisplayBlock:

No additional code is needed for exit offers. The PaywallDialog handles the flow internally: it preloads the exit offering on display, intercepts the dismiss action, and transitions to the exit offer paywall if configured. The setDismissRequest callback fires only when the user has fully dismissed both the main paywall and the exit offer (or if no exit offer is configured).

When using setShouldDisplayBlock together with an exit offer, the SDK also evaluates the block before showing the exit offer. If the condition returns false (for example, the user purchased on the main paywall and now has an active entitlement), the exit offer is skipped and the dialog closes directly.

Presenting with `PaywallActivityLauncher`

For apps that do not use Compose or prefer an Activity based approach, PaywallActivityLauncher launches the paywall as a separate Activity. Exit offers work automatically here as well, the SDK launches the exit offer as a second Activity on top of the first.

When the user dismisses the main paywall Activity, the SDK automatically launches the exit offer Activity on top. If the user purchases from the exit offer, the result is PaywallResult.Purchased. If they dismiss the exit offer too, the result is PaywallResult.Cancelled. The onActivityResult callback handles both scenarios uniformly.

To launch without an entitlement check, use launch() instead of launchIfNeeded():

The embedded `Paywall` composable: Why exit offers do not work

If you are embedding the Paywall composable directly in a navigation graph, exit offers will not trigger:

The Paywall composable renders the paywall content directly in your layout. When the user taps the dismiss button, onDismiss navigates back via navController.popBackStack(). The paywall has no opportunity to intercept this dismissal and show an exit offer because the navigation action happens immediately.

If you want exit offers while keeping a navigation based flow, replace the embedded Paywall with a PaywallDialog placed inside the screen composable:

The behavior is identical from the user’s perspective, a full screen paywall appears and can be dismissed, but the PaywallDialog manages the dismiss flow internally, enabling exit offers.

How exit offers work under the hood

When a paywall loads, the SDK calls preloadExitOffering() in the background. This method checks whether the current paywall’s configuration includes an exit offer reference (an offering ID stored in PaywallComponentsData.exitOffers.dismiss.offeringId). If it does, the SDK fetches that offering from RevenueCat’s backend and holds it in memory.

When the user taps close, the SDK checks two conditions:

Has the user completed a purchase? If yes, close normally. No exit offer.
Is there a preloaded exit offering? If yes, present it instead of closing.

For PaywallDialog, the transition works through a state swap. The current dialog offering is set to null (closing the current paywall), and the exit offering is set as a pending offering. A LaunchedEffect detects this transition and opens the exit offer as a new dialog.

For PaywallActivity, the transition launches a new Activity. The exit offer Activity uses the same PaywallActivity class but with the exit offering’s ID passed as an argument. The result from the exit offer Activity is forwarded back to the original caller.

The SDK also tracks exit offer events for analytics. When an exit offer is shown, a paywall_exit_offer event is recorded with the exit offer type (dismiss) and the exit offering identifier. This data appears in RevenueCat Charts, letting you measure how exit offers affect your conversion funnel.

Platform differences

iOS

Exit offers on iOS work with presentPaywall() and presentPaywallIfNeeded(). They do not work with PaywallView embedded in SwiftUI. This is the same structural limitation as Android: the presentation method must control the dismiss flow.

One important consideration: Apple’s App Store Review Guideline 5.6 (Developer Code of Conduct) has been cited in some rejections for apps that show additional offers when the user tries to dismiss a paywall. Apple’s definition of “manipulative practices” is subjective, and enforcement is inconsistent across reviewers. Some apps use exit offers on iOS without issues, while others have been rejected. If you want to start with a safer approach, use RevenueCat’s Targeting feature to enable exit offers only for Android users.

React Native

Exit offers work with the presentPaywall and presentPaywallIfNeeded functions. They do not work with the <RevenueCatUI.Paywall> component embedded in your layout. The pattern is consistent across all platforms: only presentation methods that control the dismiss flow support exit offers.

Kotlin Multiplatform

Exit offers are not yet supported in the RevenueCat KMP SDK.

Conclusion

In this article, you’ve explored how exit offers work in RevenueCat’s paywall system on Android, from dashboard configuration to the correct presentation methods. The key takeaway is that exit offers require PaywallDialog or PaywallActivityLauncher. The Paywall composable does not support them because it has no dismiss flow to intercept.

Understanding this distinction helps you choose the right presentation method from the start. If you plan to use exit offers, build your paywall integration around PaywallDialog (for Compose) or PaywallActivityLauncher (for Activity based flows). If you are already using the embedded Paywall composable, switching to PaywallDialog is a small change that unlocks exit offers without altering the user experience.

Whether you are implementing exit offers for the first time, migrating from an embedded paywall to a dialog based one, or evaluating how exit offers could affect your conversion funnel, the patterns in this article give you a clear path to get them working correctly on Android.

As always, happy coding!

— Jaewoong (skydoves)

Write the Tweet before you build the product

Tue, 21 Apr 2026 14:06:04 GMT

In the early 2000s, Amazon popularised a product development framework that has since become Silicon Valley folklore: the Working Backwards method. Before writing a single line of code, Amazon product managers were required to write the press release announcing the product’s launch. The logic was simple but ruthless: if the press release wasn’t compelling, the product wasn’t worth building.

Today, consumer attention spans have shrunk from the length of a newspaper article to the length of a TikTok video. As growth advisor Phil Carter noted in a recent episode of the Sub Club podcast, the Amazon memo has evolved for the AI era:

“Now instead of a news article, it’s a Tweet or a TikTok video,” Carter explains. “It is really helpful to start with the end in mind because the reality is no matter how good your product is, if people aren’t willing to give it a shot, it’s not going to matter.“

For modern subscription apps, especially those leveraging AI, the new forcing function for product development is this: write the Tweet before you build the feature.

The ElevenLabs approach to feature launches

This isn’t just a theoretical exercise. It’s how some of the fastest-growing consumer AI companies actually operate.

Take ElevenLabs. In a separate Sub Club episode featuring their mobile growth leads, the team revealed that their product specs often begin as a literal Twitter thread. Before building launch assets, landing pages, or writing code, they ask one question: can the value of this feature be explained clearly in a Tweet?

If the answer is no, it’s a red flag. Writing the narrative first forces clarity. It prevents engineering teams from falling in love with a technically-impressive feature that users won’t actually care about. By starting with the Tweet, ElevenLabs ensures every feature they ship has a built-in hook for organic distribution.

The TikTok filter: demonstrability is distribution

This concept extends beyond X (formerly Twitter) to video-first platforms like TikTok and Instagram Reels. In fact, visual demonstrability is arguably the most important attribute a new feature can have.

“It’s almost a good filter when building products,” says Sub Club host David Barnard. “Would this make a good TikTok video?”

Consider the rise of Cal AI. In a crowded health and fitness category dominated by established giants like MyFitnessPal, Cal AI broke through by building a product experience that was inherently viral. Their hook was entirely visual: take a photo of your meal, and the app instantly calculates the macros.

Is machine vision calorie tracking perfectly accurate every time? No. But as a product experience, it’s magical. More importantly, it’s demonstrable in three seconds. That demonstrability fueled a massive wave of user-generated content (UGC) and paid ad performance, propelling the app’s rapid growth.

As Joseph Choi highlighted in another Sub Club conversation about TikTok virality, platforms with algorithmic feeds reward products that can instantly communicate their value proposition visually. If your core feature requires a three-minute tutorial to understand, it will struggle to find organic traction.

Building for the ‘automagical’ moment

The ‘write the Tweet’ philosophy is ultimately about engineering an ‘automagical’ first-time user experience. In an app ecosystem where the average consumer is bombarded with thousands of ad impressions daily, and where hard paywalls often convert 5x better than freemium models, you have a very narrow window to prove your worth.

When you write the Tweet first, you are forced to distill your product’s value into its most potent form. You are designing for the aha! moment; for the exact moment a user realizes your app solves their problem in a way they’ve never seen before.

A perfect example of this is the screen time app one sec. Founder Frederik Riedel built the initial prototype in a weekend to solve his own social media habit. A single, well-crafted Tweet demonstrating how the app forced a deep breath before opening Instagram drove months of sustained organic growth. The product was the marketing.

How to apply the tweet first framework

If you want to implement this in your own product development cycle, start by adding a mandatory section to your product spec templates. Before detailing the technical requirements or user flows, require the product manager to draft:

The hook: a 280-character Tweet announcing the feature. What is the single most exciting thing about it?
The visual: a description of the three-second video clip that would accompany the Tweet or serve as a TikTok ad. What exactly is happening on screen?
The user testimonial: what is the specific, enthusiastic quote you want a user to leave in an App Store review after trying it?

If your team struggles to write these three elements, you likely have a positioning problem — or worse, a product problem.

As Phil Carter puts it, “You need to start with the end in mind, which is how are you going to get your first hundred or first thousand users? And part of that is writing the Tweet upfront or figuring out what the TikTok video needs to look like upfront.”

In the AI era, shipping fast is table stakes. Shipping features that actually resonate requires clarity. So next time you’re debating a feature on your roadmap, don’t ask if you can build it. Ask if you can tweet it.

6 steps to design a freemium tier that drives upgrades

Tue, 21 Apr 2026 11:49:45 GMT

It’s tempting to jump straight to tactics when it comes to freemium. There’s so much more you can do than just a hard paywall: engagement moments, upgrade triggers based on usage, contextual nudges… I’m getting excited just writing about it!

But what deserves more attention is working out what to offer free vs. paid. There’s a lot of generic advice out there:

“Give them a taste of premium”
“Provide value”
“Balance value and pushing upgrade”

None of which answers the tricky question: what do you offer in your free versus premium tiers? How did freemium giants like Duolingo, Slack, and Strava figure out what belongs in each?

That’s what I want to cover here. I promise to stay strategic rather than tactical, but practical enough that you and your team can actually use this to decide what belongs in each tier. Follow this step-by-step process, and you’ll end up with a clear, defensible freemium strategy.

What does the data say about free vs. paid?

Before we begin, a quick note: the numbers can make freemium look like the underdog: hard paywall products have median conversion rates of about 10.7%, compared to 2.1% for freemium models, and can generate roughly 8× more revenue per install after 14 days. While it’s true that hard paywalls can be huge performers, it’s not the rule. And that’s only the median story.

The strongest freemium products — think of companies like Duolingo, Slack, and Strava — show how wide the performance spread can be. Top freemium apps can achieve retention rates between 42.4% and 58.1%, far outperforming average outcomes.

Retained subscribers after 1 year, by access methods — State of Subscription Apps 2026

In other words, freemium rewards exceptional execution: the difference between a mediocre strategy and a great one is enormous, and getting the tier design right is what determines whether you land in that top bracket.

So, let’s jump into six steps to creating a freemium strategy that actually drives upgrades.

Step 0: is freemium even right for you?

I’d be doing you a disservice if I skipped this step, but if you’ve already thought this through, no offence taken at all — jump straight to Step 1.

Still with me? Let’s cover the considerations when deciding if freemium is right for your app.

Understanding audience size in free vs. paid

The first consideration is audience size. If you’re building a product you want to scale broadly, freemium is usually the default choice. The word-of-mouth potential and advantage of a large top-of-funnel reach often outweigh the downside of a lower conversion rate. On the other hand, if your product serves a very niche audience, you may want to save yourself some time and go straight to a hard paywall model (possibly paired with a trial).

If you compare day 35 downloads to paid for freemium vs. hard paywall, the averages differ greatly:

Day 35 download-to-paid, freemium vs. hard paywall — State of Subscription Apps 2026

That means that, in a freemium model, you typically want at least ~1,000+ free users to build a meaningful paid cohort. Based on these ranges, if you have around 5,000 users, freemium might yield roughly 110–225 paying customers, whereas a hard paywall could convert closer to 325–1,085.

If you’re unsure whether your audience is large enough to support a freemium strategy, it’s worth estimating your Serviceable Addressable Market (SAM) to see whether you can realistically reach the scale needed for freemium to work.

Unless you have a very good reason why people would convert at a higher-than-average rate — Slack converts at over 30% because of its business case and strong freemium strategy — the math needs to work for lower conversion rates.

Revenue delay within freemium apps

Freemium apps tend to lean toward more habit-forming, viral products. That virality comes at a cost: there is a delay in revenue. Hard paywall users mostly convert on Day 0, while a larger share of freemium users convert weeks after download, meaning you need the runway to wait:

Average revenue per install (RPI) after 14 days, split by access method and pricepoint — State of Subscription Apps 2026

Willingness to pay and pricing confidence

It’s harder for newer apps to understand willingness to pay with a freemium model because you need a bigger audience to learn from. Is it not converting because people won’t pay — or is it converting less because of freemium? For new apps, it could be worth temporarily starting with a hard paywall to learn, then switching to freemium once you understand your price sensitivity better. Alternatively, if you expect word-of-mouth to be your primary growth driver or you’re in a crowded market, you can take the Headspace approach: start with a very generous free tier and then, over time, move more behind the paywall.

Don’t let freemium make you timid on pricing

There’s no published data directly showing that freemium apps charge less than hard paywall apps, but in my experience, the tendency is there — and it’s a trap. RevenueCat’s data shows that higher price points actually drive better Day 35 conversion rates (2.8% median vs. 1.4% for low-priced apps) and higher revenue per install.

Day 35 download-to-paid, by pricepoint — State of Subscription Apps 2026

The logic is counterintuitive but sound: if someone has experienced genuine value in your free tier and still chooses to upgrade, they’re a high-intent buyer. Price accordingly. Your generous free tier should give you confidence to charge more, not less.

Step 1: what is your goal with freemium?

You’ve decided freemium is right for you. Now the question is what you want that free tier to do for your business.

Your goal shapes everything that follows: how generous your free tier is, where you draw the paywall line, and how aggressively you push for upgrades. People often think freemium’s main benefit is purely for word-of-mouth or volume, but freemium can serve many goals.

1. Stand out in a competitive market

Healthi, a weight-loss app, intentionally went freemium because its major competitors — Weight Watchers and Noom — didn’t offer a free version. This helped them gain traction and stand out in a crowded market.

When standing out from the competition is your goal, you’ll typically want a generous free version to begin with. You’re using free as a wedge against incumbents. Over time, as you establish your position, you can tighten the free tier and charge more — similar to what Headspace did and what we see with several larger AI apps.

2. Drive organic growth through word-of-mouth

People are much more likely to recommend a free app than a paid one, and many freemium apps benefit from running fewer ads as a result. Duolingo’s former VP of Product, Cem Kansu, put it bluntly on the Sub Club podcast: at Duolingo, free users were never treated as freeloaders. They were the primary distribution channel. Around 80% of new users arrive organically, powered by viral loops, shareable progress, and the app’s built-in motivation systems.

When this is your goal, you need to think carefully about how to ensure free users get enough value to recommend you, and whether you can build viral loops into your freemium model. If free users don’t love the product, there’s nothing to spread.

3. Help build a habit

Some apps naturally take longer to build value or to understand. In these cases, freemium can give you time to convert users who a trial (rarely longer than 30 days) simply can’t.

When this is your goal, think about the actions needed to get the user far enough along to pay. For example, Fitbod, a fitness app, offers three workouts completely free before you need to pay. After three workouts, you’re starting to get into the habit of using the app and seeing the value. The free tier isn’t about generosity, it’s about giving users enough runway to form the habit.

4. You need volume for your app to work

Some apps need scale for their core product to function, whether that’s data, community, or network effects.

For example, I worked with an IBS app that was just starting out. Their main feature of value was a powerful scanning tool that helps you understand what you can and can’t eat based on what triggers your gut health issues. They were intentionally very generous with the scanning tool — more generous than they needed to be — because every new market they entered, they needed a lot of data on what foods to include, and this was cheaper and easier to source through user data than external data sources. For one new market they were testing, they went so far as to omit a paywall entirely because their data outweighed short-term revenue.

If their goal had been just word-of-mouth, they could have offered less, which is exactly what they did in their main market, where they already had enough data. They still grew substantially organically, resulting in YoY revenue up 70%–80% and paid conversions rising from 6.6% to 13.7% (well above average for freemium).

Strava is another example: free users recording activities generate the route data, segment data, and social activity that make premium features like heatmaps, leaderboards, and route suggestions valuable. The more people tracking for free, the better the paid product becomes making it worthwhile having a generous free tier.

5. Have a positive impact on the world

The final reason is a tricky one. I’ve worked with an app that genuinely grew out of a desire to help people (one of the best parts about specialising in wellness apps). They had a very generous free tier: you could use the main features without ever paying. But people weren’t activating as much as premium users — we’re talking 1%-2% active for freemium vs. 60% for premium.

With free user activation being extremely low, they weren’t actually achieving their impact goal. You need to find ways to stay true to this mission while actually delivering value. For example, when Headspace removed its freemium content, it still offered free meditations on YouTube to stay true to its goal of having a positive impact, just through a different channel.

So start by defining your main goals to ensure you design your model the right way. Depending on your goal, you may intentionally choose to be more or less generous.

Step 2: define what user success looks like

Your users have a job they’re trying to achieve with your app, and when they achieve it, they retain. If you have the data, look at what it shows for paying users; if you don’t, define the actions that will predict success.

I like how Alice Muir Kocourková explains it:

“Free users should be able to achieve meaningful progress toward their goal — but not reach the full solution.”

So you need to know not only your goal, but theirs too. That then allows you to work backwards to what actions get them to that point.

Step 3: choose your freemium architecture

Based on the above, you can now think through how to shape your freemium setup. Not all freemium models are built the same way. Some apps offer very different features for free vs. premium users, while others offer a taster of premium features. Before you map individual features to free and paid, you need to decide how the free tier relates to the paid tier. There are three broad approaches, each suited to a different type of product.

1. The taster model: same product, with limits

Here, users get the full product experience up to a certain limit. The free version doesn’t feel stripped down, it feels complete enough to use and get real value. The upgrade trigger comes from usage growth, not from missing features.

Loom, the video-sharing platform, is a great example. I used it for free for a good year, maxing out at 5-minute recordings and saving up to 25 videos. I didn’t use it often, so I’d occasionally delete older videos to make room. Over time, I started seeing the value, and I reached a point where five minutes felt frustrating, and sending four separate videos to a client did not exactly scream professional. I switched to paid and have been a loyal customer for years.

Other examples include Zoom (free users get the same tools but hit a 40-minute limit) and Notion (same editor and workspace, but with block limits and limited guest invitations).

When this works well:

Usage impacts value: saving more videos, longer recordings, more storage are genuinely more valuable as you use the product more.
Your core value is what drives word-of-mouth, so you want or need free users to experience the real thing.
There’s a natural inflection point where casual usage becomes serious usage. Think of it as the ‘defining the relationship’ moment — you don’t want an app situationship.

For this to work, you need to identify, or create, that natural inflection point where casual clearly becomes serious. Set limits too high and users never hit them; set them too low and the free tier feels like a trial with extra steps.

2. The split model: different features for different jobs

Here, free and paid users get distinctly different capabilities. Premium isn’t ‘more of the same’ — it’s a different set of tools serving a different (usually more advanced or professional) use case.

For example, CapCut, the video editing app, offers basic video editing features for free, but as I edited my video and wanted fancier subtitles and better editing tools, it was indicated that these were premium features. I could edit without them, but for a business use case where I wanted a more polished result, paid made sense.

Surfline, a surfing app, works the same way. Casual once-a-year surfers only need a basic forecast, and the free app handles that well. Serious surf fanatics want extended forecasts, wave timeline features, and detailed swell data.

As a casual surfer myself, I just want to know whether I can surf (and hope I can stand up). I have no clue what the wavelengths and frequencies mean. But as those casual users start to fall in love with surfing (or move closer to a beach), they may become paid users at a later stage.

When this works well:

You serve distinct user segments with different needs (casual vs. power user, personal vs. professional, individual vs. team)
Paid features have meaningfully higher value, or higher cost to serve, that justifies a separate tier
Free features are strong enough to stand alone — they’re not just a teaser for what’s behind the paywall

The risk: If the split feels artificial, e.g. if users constantly bump into locked features during their normal workflow, it creates frustration. So the locked features should feel like a different destination, rather than a roadblock on the same path.

3. The hybrid model: taster limits + split features

Many of the best freemium apps combine both approaches: some features are available to everyone with usage limits, while others are exclusively premium. This gives you two distinct upgrade triggers: “I need more of what I already use” and “I want access to something new”.

Slack offers you a taster, or well, practically a full free meal. You get the full workspace experience, but message history is limited to 90 days, and you’re capped on integrations. Yet features like Slack Connect (cross-organisation channels) are fully premium, because they’re classic business features that signal a team should be able to pay. Casual teams never need them; business teams can’t live without them.

ChatGPT works similarly too: free users get access to capable models with usage limits (taster), while advanced models, deeper reasoning tools, and higher-volume image generation are premium-only (split).

And Duolingo also does the same: free users get all lessons (the core product) with ads and limited ‘hearts’ (taster), while unlimited practice, progress quizzes, and offline access are premium-only (split).

When this works well:

You have both a broad casual audience and a smaller power-user segment.
Some features scale with usage (good for limits) while others are binary; you either need them or you don’t.
You want multiple upgrade triggers at different points in the user journey.

Which approach is right for you?

If you aren’t sure, these questions can help:

Does your product’s value increase with usage volume? (More messages, more storage, more recordings.) Lean toward the taster model. Set limits where casual use flips into serious use.
Does your product serve clearly different user types? (Hobby vs. professional, individual vs. team, consumer vs. business.) Lean toward the split model. Gate features by segment, rather than usage.
Is your user base very broad, with a wide spectrum of needs? Lean toward the hybrid model. Use taster limits for the core experience and split features for power tools.

Don’t feel like you need to set and forget; this may be something you test and evolve as you learn. Your architecture can change over time, it’s much easier to tighten a generous free tier than to loosen a restrictive one.

Step 4: map your free vs. paid offering

Now, this is likely to be something you will optimize and experiment with vs. set-and-forget, but you need to start somewhere. Based on the above, if you’ve worked that out already, this step should feel quite natural.

Now, this is likely to be something you’ll optimize and experiment with rather than set and forget, but you need to start somewhere. If you’ve worked through Steps 1–3, this step should feel quite natural.

For each feature, map out whether it’s free, paid, or limited — and critically, write down the strategic rationale for why. This forces you to articulate the reasoning, which makes it much easier to revisit later and to align your team. For example, here’s how some of Strava’s features map out:

Feature	Free	Paid (Summit)	Strategic rationale
GPS activity recording	✓ Full access	✓	The product is about tracking. Gating it kills the network. Every recorded activity = content for the social feed.
Activity upload from devices	✓ Garmin, Apple, Wahoo etc.	✓	Device integrations expand the top-of-funnel. Every synced watch is a distribution channel.
Segment leaderboards	Limited (personal only)	✓ Full leaderboards	This is the upgrade hook. Competitive athletes need to see where they rank so this is a natural “aha moment” trigger.
Power analysis (cycling)	✗	✓	Niche but extremely high willingness-to-pay. Cyclists already spend thousands on gear.
Clubs & group challenges	✓	✓	Clubs are viral loops: each club invite is organic acquisition. Free access maximises reach.

A few additional considerations as you map this out:

1. Keep AI costs in mind

If your app uses AI features, some things you’d like to offer for free may simply be too expensive to give away. This is reshaping freemium for AI-first apps: rather than gating features, many are adopting usage-based models where free users get a set number of credits or queries.

ChatGPT, for example, doesn’t lock features so much as it limits how much of the best model you can use before you need to upgrade. When mapping your features, note the cost to serve alongside the strategic rationale — it may override your preference.

2. Consider platform-specific differences

Your strategy may need to differ for iOS and Android, based on the differences in how those user groups monetise. Lose It! has a platform-specific paywall strategy: the same feature (barcode scanner) is free-with-ads on Android, but paid on iOS. Some apps also lean more heavily on ads for Android because there’s a lower likelihood of paying. This breaks the “sacred rule” of platform parity, but Lose It! led with data and adjusted based on what actually worked per platform.

3. Having your Bill of Rights in place

This might be the most important part of this step. As you map features to free and paid, you also need to define what you’re not willing to move.

Here’s the problem: it’s very easy to slowly shift more and more of your offering to premium, one experiment at a time, until the free tier offers little value. Each individual experiment might show a lift in conversion rate. But over time, the cumulative effect of reducing free value — on word-of-mouth, on user experience, on brand love — is almost impossible to measure until it’s too late.

Chris Hulls, Founder and CEO of Life360 (the family safety platform used by over 80 million active users), talked about exactly this on the Sub Club podcast. Life360 recently wrote a ‘Bill of Rights’ for their free users, an internal document that acts as a constitution for what cannot be touched. Whilst their Bill of Rights isn’t publicly available, to give you an idea of what it includes, Chris did share:

“This is probably the most important: the core map, location history, and place alerts, they must be free. Doesn’t mean we can’t move the paywall a bit, but real value there, no deceptive tactics… The real anchor is all around the lifeblood to who we are.”

Jacob Eiting, RevenueCat’s CEO, nailed why this matters in that Sub Club podcast: nobody runs a holdout group long enough to see the cumulative effect of chipping away at the free tier. You can A/B test removing any single feature, and retention looks fine. Do it 20 times, and you’ve quietly eroded the thing that made people love you.

I love the concept of the Bill of Rights and recommend taking notes on your own. This is likely a longer-term project, and if you are larger already, an internal discussion, but worth thinking through the following questions:

What must always be free, no matter what? These are the features that are the product. If you gated them, you’d kill the thing that keeps people coming back. (Life360: core map + location sharing + place alerts. Duolingo: daily lessons. Strava: GPS tracking and the social feed.)
What is the core value that free users receive, and is it real value, not a teaser? Chris’s test is simple: real value forever for free, period, rather than some crippled demo or a countdown to a paywall. A genuinely useful product someone could use indefinitely without paying.
What can we experiment with, and what’s off-limits for testing? Some things you A/B test aggressively (paywall copy, timing, pricing) and some things you never touch because they are core to the free experience.
What would make a free user feel cheated if we moved it behind the paywall? This surfaces the emotional contract, not just the functional one. Users might not churn immediately, but they’ll stop recommending you.
What dark patterns or ‘growth hacks’ are we explicitly ruling out? Life360 included this in their Bill of Rights: no deceptive tactics, no ads that interrupt the Job to be Done, no springing changes on users without notice. Writing down what you won’t do is as important as what you will.

Step 5: work out if a trial is needed

Sometimes newer freemium apps default to offering a free trial, thinking they need to. It’s well-intentioned, but definitely not a requirement. Rather, trials should be strategic: offering them when users need to experience premium features to understand their value, or only to highly engaged users or win-back users.

A few considerations:

1. Do users need to experience premium to understand it?

If your premium features are the kind of thing people need to try (like advanced analytics or personalized coaching), a trial makes sense. If the free-to-paid gap is self-evident from the free tier, e.g. “I can see the leaderboard exists but I can’t use it”, a trial may be unnecessary.

2. Consider reverse trials

Rather than a traditional free trial that ends and asks users to pay or leave, a reverse trial gives new users premium access for a limited time, then drops them to the free tier. This is increasingly popular in freemium apps because users experience the gap between paid and free from the perspective of losing something (loss aversion), which is a stronger motivator than never having had it.

It’s distinct from a traditional trial because the user lands on freemium rather than churning entirely.

3. Don’t go too long

In general, avoid overly long trials to prevent further delay of monetization. Daily-use apps can get away with a 3-day trial, while weekly-use apps may need 7 days. Match trial length to your app’s usage cadence so users have enough time to experience value but not so much that the urgency to decide disappears.

Step 6: start working on how you communicate and push for upgrade

Only once you’ve designed a strong setup can you jump to the part I got all excited about at the beginning: the tactics. It’s not to underestimate them; they just work 10x better once you’ve designed the foundations well. Alice Muir Kocourková shares some great pointers on how to do this in her article How to turn freemium users into loyal subscribers. I’d recommend prioritizing the following areas first:

1. Communicating freemium value

Not getting caught up on listing everything, but zooming in on the few drivers that matter to that user to upgrade. First, work on your overall upgrade message, then get fancier by improving based on user intent and usage (Alice has some great tips for this).

2. Onboarding for expectations

If your goal is word-of-mouth, you need to be much more intentional in onboarding so that the free experience is strong; if you are focusing on long-term conversion, you may push a bit harder for paid upfront.

How much you communicate about premium during onboarding is a strategic choice. But no matter your goal, don’t be too discreet. Nothing is worse than thinking an app is fully free, only to get a nasty shock after you’ve invested effort in setting it up and using it. That erodes trust fast.

3. Working hard on paywall timing and visibility

A common mistake in freemium is low paywall visibility. I was watching a show on the Channel 4 app (Okay, it was Married at First Sight: Australia, don’t judge me too much) and I got about 11 episodes in, being driven absolutely mad by the ads. I ended up Googling and discovered that I could upgrade to ad-free for £3.99. Maybe they earned more from me through the ads, but I was at the point of abandoning the show in frustration at the 10–15 minutes of ads per episode. Not knowing about premium nearly caused me to churn entirely.

Consider what the right moments in the journey are to surface your upgrade offer. Spotify is the gold standard here: their ad interruptions aren’t random annoyances, but carefully calibrated strategic friction — a reminder of what premium feels like, placed at the exact moment you’re most annoyed by the free experience. It’s no coincidence they achieve a 46% freemium-to-paid conversion rate.

The best freemium apps don’t just build a great free tier and hope people upgrade. They design specific moments throughout the user journey where the value of premium becomes undeniable, and then make it effortless to act on that feeling.

Freemium isn’t glamorous

Freemium is one of the hardest monetization models to get right, but when it works, it compounds: free users drive word-of-mouth, which drives more free users, which strengthens your product (through data, network effects, or community), which makes premium more valuable, which funds more investment in the free tier. It’s a flywheel, but only if the foundations are strong.

The work in this guide:

Deciding your goal
Defining user success
Choosing your architecture
Mapping features with rationale
Determining if you need a free trial
Writing your Bill of Rights

All of this isn’t glamorous. But it’s the difference between the median freemium app (2.2% conversion) and the top 10% (where freemium apps outperform even hard paywalls), so do the strategic work first, and then I give you full permission to go wild on the tactics.

We made our whole company vibe code apps — here’s what we learned

Mon, 20 Apr 2026 11:59:03 GMT

At RevenueCat we’ve seen a strong trend in first-time developers shipping apps and making their first dollars using vibe coding tools. The trend is clearly visible in number of developers making their first API call:

i still don't think i've fully comprehended the implications of this pic.twitter.com/U0KPe6F0TR
— Jacob Eiting (@jeiting) November 19, 2025

To understand this new wave of developers, we decided to become them.

Making everyone a customer

At the end of last year we kicked off an internal hackathon, titled Vibeathon, here at RevenueCat. The idea was simple: get everyone in the company to build apps using the same tools our customers are using. This included tools such as Vibecode, Rork, Claude, Cursor, and other agentic development tools — tools that allow non-engineers to build software.

Shipping quickly and often is one of the core values at RevenueCat, so we gave everyone until the end of January to build an app, add the RevenueCat SDK, and ship it to app stores. Out of the full RevenueCat company, 44 signed up for the hackathon, close to 30 apps got built, and 12 made it to app stores in time. The best part was that most people were from non-engineering functions.

Learning through building

Unsurprisingly, people ended up solving their own problems: building apps to track golf progress, recognize good firewood, scan receipts for taxes, and get book suggestions. Our hackathon showed the democratizing effect of vibe coding in microscale: cheaper build process makes it easier to target underserved niches.

One of the apps that was built during Vibeathon is Bygone. Bygone helps you understand today’s weather by showing how it’s changed since yesterday

Before publishing this article I took a look at how much money the built apps have made, and at the moment these apps sit at a bit over $700 in revenue since the beginning of the year. Not enough for anyone to retire, but enough to signal that we built things people found valuable. Comparatively, the two batches of Shipathon (2024 and 2025) have collectively made over $5.5 million, so our apps have some catching up to do still.

Fast to build, hard to understand

The focus of this hackathon was learning, and we ended up learning about our product, customers, and the vibe coding movement more than we could have expected.

During the Vibeathon people were building fast and iterating quicker, but a lot of people emphasized how little they actually gained understanding in what was being built. Apps ended up being blackboxes that rely on AI to make improvements. When Apple would reject the app because of a bug, the participants could not diagnose the problem themselves, but had to go back to the AI and hope that it could fix it. Vibecoders are not authors of the product, but operators.

Some participants wanted a more structured approach and created SPEC.md and AGENTS.md to describe how agents should approach the tasks and what patterns to avoid. After that Codex was capable of one-shotting the app during dinner time, signalling that skill in vibecoding is not prompting, but specification writing. Good spec of course requires good understanding of the development concepts that the agent needs to follow. Essentially you’re aiming at getting a good output from a junior developer.

Most apps were built with React Native (with few Swift exceptions), and all but one targeted iOS. This was also the only platform most of the vibe coding tools support, despite React Native being a cross-platform framework.

The App Store was the hard part

Vibeathon brought in a lot of people who had not previously built apps, or had maybe built an app a decade ago and not touched App Store Connect or Play Store Console after that. For most people it turned out that building the app is the actual easy part, and getting it approved through Apple’s and Google’s reviews is the hard part.

This could be called the last mile problem of vibe coding, when code and implementation become cheaper and more approachable by masses, the real moat is in turning those things into apps and services that users can actually download.

People also struggled with setting up accounts, in some cases it taking Apple a few weeks to ensure that all required documentation was in order to deploy an app. The contrast is huge, when building an app can take just 5 minutes, but becoming able to distribute can take weeks. This is one of the topics we plan to focus on in the new StartApp School program, by providing detailed guidance on how to set up your Apple and Google Developer accounts.

Monetizing remains a big hurdle as well. Adding RevenueCat SDK is easy, but Apple and Google have both made it very difficult to be compliant with all their in-app purchases rulings on the first try. Almost no app got through the review process the first submission, and most people reported the constant back and forth between fixing reported issues, to end up just getting new ones.

Make your people code

Even before we kicked off Vibeathon, RevenueCat was working on better support for different vibecoding tools. Last year we released our MCP, which allows you to setup and manage products in RevenueCat and App Store Connect through agents. We’ve since improved the MCP with more features, and improved the support for it in different vibe coding tools. RevenueCat dashboard also now supports more agent friendly setup flow, giving you the prompts to setup the SDK without having to do it yourself.

Vibeathon was the first time we forced people to work solo on these projects. The promise of vibecoding being that anyone from sales to marketing, and operations to engineering could build and monetize apps, without spending considerable time on learning how to code, or having previous technical experience. Understanding this is important as it is being embodied in our new customers as well, who are building apps with a similar setup: no technical background.

Your app got cloned. Now what? A developer’s guide to protecting your work from copycats

Thu, 16 Apr 2026 16:33:24 GMT

Building a successful app is hard enough — even in the age of vibe coding. So watching someone else copy your hard work, slap a new logo on it, and siphon away your revenue is infuriating.

The app ecosystem has always had a copycat problem, but recent advancements in AI and vibe coding have poured fuel on the fire — making vibe coded app clones one of the fastest-growing threats to original developers. Today, a functional clone of a validated app idea can be generated in days, complete with scraped marketing copy and a nearly identical user interface. When OpenAI launched its official Sora mobile app in late 2025, the App Store was immediately flooded with over a dozen “Sora” and “Sora 2” branded fakes, accumulating hundreds of thousands of downloads and generating significant revenue before Apple intervened.

For developers, the question is no longer if your successful app will be copied, but when. And more importantly: how do you protect your app from copycats — legally and practically?

In theory, intellectual property (IP) law provides a robust shield. In reality, the gap between legal theory and the practical experience of navigating App Store disputes is wide. Here is a breakdown of the IP instruments available to app creators, from copyright, patents, and trademarks, to how the platforms handle infringement claims, and the real-world strategies to actually protect your app.

The intellectual property toolkit

When developers discover a clone, their first instinct is often to claim, “They stole my idea!” Unfortunately, IP law does not protect ideas or concepts. It only protects the specific expression or implementation of those ideas. Understanding the different types of mobile app intellectual property protection is the first step in building your defensive moat.

First, here’s your toolkit at a glance:

IP instrument	What it protects	Cost and timeline	Practical utility for indie devs
Copyright	Source code, UI graphics, text	Low cost, automatic	Moderate (easy to circumvent by rewriting code)
Trademark	App name, logo, icon	~$350/class, 6-12 months	High (best tool for stopping deceptive clones)
Utility Patent	Algorithms, functional methods	$10k-$38k+, 2-4 years	Low (too slow and expensive for most)
Trade Secret	Proprietary backend logic	Cost of security measures	Moderate (only works if kept confidential)

Note: the table above is specific to the US. While many of the terms and tools work the same way across the world, we’ve gone into more depth on global IP tools further down.

Copyright: protecting the expression

Copyright law automatically protects the original expression of your ideas as soon as they are fixed in a tangible medium. For a mobile app, this includes the source code, user interface graphics, original text, and promotional materials.

However, copyright is limited by the tension between an idea and the expression of that idea. You cannot copyright the concept of a habit tracker or a meditation timer. If a competitor sees your app, understands how it works, and writes entirely new code to achieve the same functionality with different visual assets, they have not committed copyright infringement.

While copyright is automatic in most places — the Berne Convention ensures that a work is automatically protected as soon as it’s created — registering your work with the relevant authorities (such as the US Copyright Office) is highly recommended. Registration provides a public record of your ownership, makes enforcement significantly easier, and is often a prerequisite for filing a lawsuit or claiming statutory damages. In the US in particular, registration is a prerequisite for filing a federal infringement lawsuit and for claiming statutory damages, making it a practical necessity rather than a mere formality.

Trademark: protecting the brand

For most independent developers and small studios, trademarks are the most practical and effective legal tool. A trademark protects the elements that identify the source of your app — primarily its name, logo, and potentially a distinctive slogan.

When copycats strike, they often try to confuse users by adopting a name or icon that is deceptively similar to the original. A registered trademark gives you direct, actionable leverage to stop this — and is the clearest basis for an App Store trademark infringement complaint. Both Apple and Google have mechanisms to remove apps that infringe on registered trademarks, and having that registration certificate in hand dramatically speeds up the process.

There have even been instances where copycat apps claim a trademark before the original has, meaning these apps them generally win out in App Store battles. So it’s crucial to sort your trademark out before launching and giving anyone time to catch up.

While you establish “common law” rights simply by using a name in commerce, a formal federal registration provides nationwide protection and a presumption of validity. App trademark registration typically costs around $350 per class in the US — a worthwhile investment for any app showing traction.

Patent: protecting the functionality

Utility patents offer the strongest form of protection, safeguarding the novel and non-obvious functional aspects of an invention — the underlying methods, algorithms, and processes that make your app work. Unlike copyright, a patent prevents competitors from using your technical innovations even if they write their own code from scratch.

However, software patents come with significant hurdles. The process is notoriously slow, often taking two to four years, and prohibitively expensive for many indie developers, with costs frequently ranging from $10,000 to $38,000 or more. Not only that, but following the 2014 Supreme Court decision in Alice Corp. v. CLS Bank, obtaining patents for abstract software concepts has become increasingly difficult in the United States.

For well-funded startups with truly novel backend technology, patents are a critical asset. For the average indie developer building a utility app, they are rarely a practical first line of defense.

The exception: Frederik Riedel successfully patented onesec’s intervention mechanism, that is used to reduce users’ screen time, because he was worried about big tech companies copying his invention.

The global dimension: national vs. international protection

A common misconception among developers is that securing IP rights in their home country provides global protection. In reality, IP rights are territorial. A US trademark does not automatically protect your app in Europe, and vice versa.

For developers targeting a global audience, navigating international IP can be daunting. However, several frameworks simplify the process:

The Madrid System (Trademarks): Administered by the World Intellectual Property Organization (WIPO), the Madrid System allows you to apply for trademark protection in up to 132 countries by filing a single international application and paying one set of fees. This is significantly cheaper and easier than hiring local attorneys in dozens of jurisdictions.
The EU Trade Mark (EUTM): If Europe is a key market, filing a single EUTM application with the EUIPO provides immediate protection across all 27 EU member states for a base fee of €850. This is vastly more efficient than filing national trademarks in each European country.
The Patent Cooperation Treaty (PCT): For the rare indie developer pursuing software patents, the PCT provides a unified procedure for filing patent applications to protect inventions in over 150 contracting states, delaying the expensive process of entering national phases.

When deciding where to file, follow your user base and your revenue. If 80% of your subscribers are in the US and the UK, prioritize trademark registrations in those two jurisdictions before worrying about the rest of the world.

How the app stores handle disputes

When you spot a clone, your immediate goal is to get it removed from the store. Both Apple and Google provide dispute resolution processes, but navigating them requires understanding their underlying philosophies.

The Apple App Store process

Apple’s App Review Guidelines explicitly forbid copycats. Guideline 4.1(a) states: “Come up with your own ideas… Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own”.

When you submit a claim to report a copycat app through the Apple App Store Dispute Form, Apple typically forwards your complaint to the accused developer and encourages both parties to resolve the issue directly. Apple’s stated position is that it does not mediate IP disputes or investigate the underlying merits of complex legal claims.

If the accused developer fails to respond or provide a satisfactory defense, Apple may eventually remove the app. In clear-cut cases of trademark infringement—especially when the complainant provides a valid registration number—Apple often acts swiftly. However, in murkier cases involving UI similarities or copyright claims, the process can drag on, leaving the original developer frustrated.

The Google Play Store process

Google’s approach is structurally similar. Developers can submit a policy violation notice regarding intellectual property. Google forwards the complaint, encourages direct resolution, and may remove the app if the issue remains unresolved.

Both platforms have faced criticism for operating what some legal experts call a “black box” dispute system. Outcomes are decided privately, often with little explanation. This system can also be weaponized; there are documented cases of larger companies or bad actors filing baseless IP complaints that result in legitimate apps being temporarily removed without due process, simply because the platform wants to avoid liability. Beyond the legal routes, your subscription metrics can also serve as an early warning system — often long before a formal complaint is needed.

Using subscription data as an early warning system

Before you ever receive an angry customer support email intended for a copycat, your subscription metrics will likely show the first signs of trouble. Clones that successfully siphon your traffic don’t just steal random users—they steal your highest-intent users who are actively searching for your brand.

According to RevenueCat’s State of Subscription Apps 2026 report, which analyzed over 115,000 apps and $16 billion in revenue, the battle for a subscriber is won or lost almost immediately. You can use these benchmarks to detect if a copycat is impacting your funnel:

1. Monitor your Day 0 cancellation rate The report found that 55% of all 3-day trial cancellations happen on Day 0. If a copycat is intercepting your branded search traffic, users who intended to download your app will quickly realize they’ve been duped and cancel immediately. A sudden spike in Day 0 trial cancellations, especially from organic search traffic, is a strong indicator of brand confusion.

2. Watch your Download-to-Paid (D35) conversion Hard paywalls convert at a median rate of 10.7% by day 35, five times better than freemium models (2.1%). If you run a hard paywall and your D35 conversion rate suddenly drops while top-of-funnel installs remain steady or grow, it may mean lower-intent or confused users are entering your funnel while your high-intent users are being diverted to a clone.

3. Track involuntary churn anomalies If your app is cloned and the copycat aggressively monetizes users who thought they were buying your product, those users will often issue chargebacks or cancel their cards when they realize the error. The global benchmark for involuntary billing failures on Google Play is 31% of all cancellations (14% on the App Store). A sudden deviation from your baseline involuntary churn rate can signal that users are disputing charges related to brand confusion.

Theory vs. reality: the developer experience

The legal theory suggests a clear path: register your IP, file a complaint, and watch the copycat disappear. The reality experienced by developers is often much messier.

Consider the case of the Bend app, a popular stretching utility. When a near-identical clone appeared on the App Store, the original developers didn’t just rely on a simple form submission. They meticulously documented the similarities, creating side-by-side video comparisons of the onboarding flows and UI mimicry. They leaned heavily on Apple’s Guideline 4.1, engaged legal counsel to send formal cease-and-desist letters, and maintained constant pressure on both the platform and the infringing studio. It was this combined, multi-front approach that ultimately led to the clone’s removal.

Conversely, relying solely on the platforms can backfire. In one notable case involving the video app Reely, a major tech company filed a trademark complaint claiming logo similarity. Google, following its standard procedure, removed Reely without investigating the merits of the claim. The developer was forced to initiate federal litigation and secure a temporary restraining order just to force the parties to the negotiating table and get the app reinstated.

A practical playbook for protecting your app from copycats

Given the limitations of the legal system and the opacity of the app stores, how should developers protect their work? The most successful strategies combine proactive legal steps with strong business fundamentals.

1. Trademark early and often: Do not wait until you are successful to protect your brand. File a trademark application for your app’s name and logo as early as possible. When a clone appears, a registered trademark is the sharpest weapon you can wield to remove a clone from the App Store.

2. Document your development: Maintain meticulous records of your design process, code commits, and asset creation. Date-stamp your work. If you ever need to prove that you are the original creator and hold the copyright to the UI or code, this paper trail will be invaluable.

3. Build a comprehensive case: If you find a copycat, do not just send an angry email to Apple Support. Build a dossier. Create side-by-side visual comparisons. Highlight identical text strings, stolen marketing assets, and UI mimicry. Make it as easy as possible for the platform reviewer to see the blatant theft.

4. Utilize cease-and-desist letters: Often, a formal letter from an attorney on legal letterhead is enough to scare off a low-effort copycat. Many clone developers are looking for easy money and will fold at the first sign of genuine legal resistance.

5. The ultimate moat: brand and community: Legal tools are necessary, but they are reactive. The most sustainable defense against copycats is building a brand that users love and trust. A clone can copy your pixels, but they cannot copy your community, your customer support, or your reputation.

As one developer noted in a recent Hacker News discussion about the surge in AI-generated clones: “Your best moat against low effort copycats? Stamina”. Copycats are opportunistic; they rarely have the dedication to maintain the app, fix bugs, respond to user feedback, and continuously iterate. By moving faster and building deeper relationships with your users, you ensure that even if someone steals your interface, they can never steal your business.

RevenueCat Charts v3: fresher data, better decisions

Thu, 16 Apr 2026 02:12:49 GMT

We’ve rebuilt RevenueCat’s data infrastructure from the ground up.

That rewrite powers a big upgrade we’re excited to share today: Charts v3 — a new Charts experience that gives you fresh data in seconds, plus a bunch of new ways to slice, segment, and understand your subscription business.

At a high level, this new infrastructure unlocks two big things:

Real-time updates across almost every chart: instead of waiting hours or days for metrics from App Store Connect or Google Play Console, our new real-time events now flow into your charts as soon as they happen, so you can actually watch launches, experiments, and promos play out in real time.
A much faster path to new charts: because we rebuilt our analytics on a unified subscription model, it’s now way easier for us to ship new charts and dimensions — which is why, just in the last year of testing and refining this system, we’ve already added a ton of new charts and charting features.

You can see Charts v3 in your project today by enabling the “v3” toggle on the top right of any chart. When disabled, you will see the legacy chart data and new features enabled by Charts v3 will not be available.

What ‘real-time’ actually means

Previously, charts updated in batches every 2–12 hours depending on the dataset. Now, almost all charts refresh in real time as events come in, giving you:

Immediate feedback on launches, paywall tests, and promos
Better intra-day monitoring for spikes, dips, or anomalies
More consistent behavior across charts, since they’re all driven by the same live pipeline

Charts v3 currently supports App Store, Play Store, Stripe, and RevenueCat Web Billing apps, with support for our other supported stores coming soon.

Data shifts you may notice

When you enable Charts v3, you may notice some numbers shift compared to the “legacy charts”. That’s expected — and while we understand this may be temporarily disruptive, it’s ultimately a good thing. Here’s what’s going on at a high level, based on the new Charts v3 architecture:

A unified subscription model across stores

Behind the scenes, all charts are now powered by a single, normalized subscriptions model. Instead of treating each store slightly differently, we map store-specific behaviors into a shared model that’s consistent everywhere.

This new model lets us:

Distinguish product changes (e.g. switching from plan A to B) from simple renewals
Treat resubscriptions (coming back after a lapse) differently from continuous renewals
In our Active Subscriptions Movement chart, resubscriptions after a lapsed subscription are now called out as a separate positive line item. In the past, resubscriptions on the Apple App Store were instead shown as negative churn.

Other charts, like Subscription Retention and Trial Conversion, now align more closely with how you actually think about subscriber behavior (e.g. “this user changed products” vs. “this user renewed as normal”).

Refunds no longer rewrite history

Previously, when a payment was refunded, it could change metrics in already-completed periods. That made it harder to trust historic reports, and could cause numbers to ‘wiggle’ days or weeks after the fact.

With Charts v3, historical data stability is crucial:

Revenue is added on the day the purchase happens
If that payment is later refunded, the revenue is subtracted on the day of the refund, not retroactively

This means historical revenue for completed periods stays stable, and you’ll see negative revenue entries on refund dates.

The same behavior applies to conversions and LTV. The original purchase contributes to all relevant timeframes, and if it’s refunded, those contributions are removed only in the periods where the refund falls. Completed periods don’t keep shifting under your feet.

Changes to cohorting

We’ve also updated the cohorting methodology for Cohort Explorer and Prediction Explorer. Instead of defining big cohorts (like a whole month) using just the first and last calendar days, we now calculate each customer’s lifecycle relative to when they actually started, then aggregate the data.

In practice, this means:

Late-joining customers no longer have their early revenue ‘pushed’ into the next period
Cohort-based metrics like 0–30 day LTV are more consistent and easier to compare across time

Quick Reference: expected metric changes

Metric	Expected change	Reason for change
Trial Conversion Rate	Likely decrease	Only direct trial-to-paid conversions counted
Historical Revenue	May shift between periods	Refunds impact the refund date, not purchase date
Active Subscriptions	Minimal change	Counting method changed, not actual subscribers
MRR/ARR	Minimal change	Based on same active subscription count

RevenueCat mobile app charts may look different

The official RevenueCat mobile app has not yet switched to Charts v3, so you may see slightly different data until we have switched that over as well.

New charts and capabilities unlocked

Because the data model is now more flexible, we’ve been able to ship a bunch of new charts and features on top of Charts v3 already — with more on the way.

Period-over-period comparisons

A big upgrade built on Charts v3 is period-over-period comparisons. You can now compare your selected date range against the previous period with a single toggle in the Compare dropdown.

Churn rate over the last 12 months compared to the previous 12 months.

When enabled, charts will:

Plot both the current period and comparison period as separate lines
Show total values and percentage change in the summary
Let you hover over any point to see the percentage change vs. the previous period at that moment in time

Period-over-period is available on key charts like Active Subscriptions, MRR, ARR, Churn, New Customers, New Trials, Conversion to Paying, Refund Rate, and more.

New and improved dimensions

Charts v3 introduces new dimensions and tightens some existing ones, so segmentation matches how you actually reason about your business.

The segment picker has new grouping and now includes search to make it easier to find the right dimension.

New dimensions include:

Custom attributes: segment by the custom attributes you set on customers
Experiment: filter/segment charts by experiment and variant
App version: analyze metrics by the first app version a customer used
Attribution: filter/segment using Source, Campaign, Keyword, etc.

We’ve also improved existing dimensions:

Platform now refers to the customer’s first seen platform (where they originated), not the last platform they touched — so segmenting by platform is more stable over time
Country now prioritizes the app store storefront over IP-based location, aligning charts more closely with how revenue and subscribers are actually distributed across markets

For full definitions and edge cases, see the Charts v3 docs.

New Active Customers Chart

The new Active Customers chart plots all users that were seen in the period being measured, regardless of whether they’ve made a purchase. This works well to plot out your daily active users (DAU). An important note is that this chart does not yet correct for aliased customers, so in cases where the same customer appears under multiple linked app user IDs, active customer counts may be overstated.

Trial Conversion Rate

The new Trial Conversion Rate chart is cohorted by trial start date and focuses purely on the trial-to-paid step conversion, making it easier to understand how changes to acquisition, pricing, or paywalls affect payment behavior over time.

Updated Active Subscriptions Movement (state bar chart)

We’ve refreshed the Active Subscriptions Movement chart to better visualize how subscribers move between states (new, renewed, churned, product changes, resubscriptions, etc.) using a more intuitive state bar format.

Paywall charts

New Paywall Charts give you a dedicated place to understand paywall performance: conversion, drop-off, and downstream value, all segmented by the same dimensions you already use across RevenueCat.

You can also now filter and segment other charts by RevenueCat Paywalls, making it much easier to tie conversion and revenue outcomes back to specific paywall experiences and experiments.

Try Charts v3

Charts v3 is available in your dashboard today for apps using the supported stores.

If you notice differences in your metrics after switching, refer to the Charts v3 docs for a chart-by-chart breakdown of what’s changed and why — and, as always, we’d love your feedback as you start using it in your day-to-day decision making.

Why a hard paywall is the right answer for your app (until it isn’t)

Wed, 15 Apr 2026 12:52:51 GMT

As an independent growth advisor and angel investor, Phil Carter helps consumer subscription companies scale their growth engines. In a conversation with David Barnard on the Sub Club podcast, he breaks down the tension between maximizing short-term revenue with hard paywalls and building massive businesses through freemium models—and why the most powerful AI features might not need the most expensive LLMs.

Moving from checkers to chess: The multi-step paywall

For the vast majority of subscription apps, a hard paywall is the right answer. The data is clear: hard paywalls often convert five times better than freemium models. If you’re a bootstrapped startup operating with limited capital, it’s the most reliable and low-risk way to grow your business.

But for companies trying to build a billion-dollar business, freemium is often the only way to attract a massive user base at the top of the funnel. Phil Carter calls the transition from a hard paywall to freemium “moving from playing checkers to playing chess” because it requires significantly more sophistication.

Recently, Carter worked with a client to navigate this transition. Instead of simply dropping the paywall, they implemented a “multi-step paywall.” The product is free, but users are offered a seven-day trial of the best version. After the trial, they are prompted to subscribe to maintain that maximum value. Combined with pricing and packaging optimizations, this shift resulted in a 75% increase in LTV per user. The business moved from excluding users with a hard paywall to growing much more quickly through organic acquisition.

The trap of the value-to-noise ratio

With AI dramatically lowering the cost of software development, the pace of innovation has accelerated. It’s easier than ever to ship new features constantly. But this speed can become a trap.

“A fallacy that a lot of companies fall into is like, well, more products and more features equals more value and therefore we should just ship products and features as fast as we possibly can,” Carter explains.

The bottleneck isn’t development speed; it’s the capacity of the human brain to absorb the product experience. As an app becomes bloated with new capabilities, the absolute value might go up, but the complexity and noise increase alongside it. This causes the “value-to-noise ratio” to plummet. To combat this, teams must rigorously analyze which features actually drive long-term retention and aggressively prune the rest.

Why cheaper LLMs can build better products

It’s tempting to default to the most powerful frontier models from OpenAI or Anthropic when building AI features. But Carter points to Gamma, an AI-powered presentation tool that reached profitability within six months of launching its AI features in early 2023.

One of the reasons for Gamma’s rapid path to profitability was their savvy use of underlying LLMs. They didn’t always use the most powerful models. Instead, they found that for their specific use cases, longer-tail models provided performance that was “good enough” while delivering significantly faster response times and drastically lower compute costs.

“The product experience is a function not just of the output that the LLM provides, but also how fast it provides that output and how expensive it is to generate that output,” Carter notes. For many consumer apps, speed and affordability are more critical to the user experience than peak AI performance.

The 400-creative-per-month advantage

AI isn’t just changing the core product experience; it’s fundamentally altering user acquisition. Carter highlights Runna, a running app that used AI tools to exponentially increase their creative testing volume.

Runna went from producing tens of creative concepts per month to over 400. This massive increase in volume isn’t just about lowering CAC by finding winning ads faster. It creates a much more rapid learning cycle. By testing hundreds of permutations—using tools like ElevenLabs for voiceovers or Suno for background music—the marketing team learns exactly what resonates with users. Those insights don’t just optimize ad spend; they feed directly back into product roadmap decisions.

In the full episode, Phil also discusses how AI can turn the first 60 seconds of onboarding into a magical experience, why nicheification is the new strategy for crowded app categories, and the importance of building extrinsic triggers to form user habits.

Guest links:

Phil Carter on LinkedIn
Elemental Growth
Subversive Podcast
Consumer Subscription Growth Course (Maven)
@philgcarter on X

Frederik Riedel expected 12%. His app cut screen time by 57%.

Wed, 15 Apr 2026 10:37:16 GMT

After building between 50 and 100 apps, Frederik Riedel coded a weekend prototype to solve his own social media habit. When he accidentally triggered the app’s blocker just 20 seconds after installing it, he knew he had a real business. In a conversation with Charlie Chapman, the one sec founder breaks down how a single tweet drove months of growth, why ironic social media advertising works, and how an indie developer ended up with peer-reviewed research and a US patent.

The weekend prototype that proved itself in 20 seconds

Frederik Riedel had been building apps since he was 14 years old. By 2020, he had shipped somewhere between 50 and 100 apps—at one point releasing a new app every week, and even breaking App Store Connect tools that didn’t expect developers to have that many products.

But his most successful app started simply as a tool to solve his own problem during the COVID-19 lockdowns. Frustrated by how much time he was spending on Instagram and Twitter, but unwilling to go cold turkey, he built a prototype that intercepted social media app openings and forced him to do a brief breathing exercise.

The validation was immediate. “I built the first prototype on a weekend, put it on my own phone,” Frederik recalls. “Actually, when I installed the app on my own phone, 20 seconds afterwards, I accidentally ended up opening Twitter and I ran into my own app. And I was like, really, okay, I’m onto something here.”

Even the developer who had just written the code was operating on autopilot. Within two weeks of using his own prototype, his screen time dropped by 50%. He spent another two weeks polishing the app and released it as one sec.

When one sec launched, a simple screen recording of the app in action on Twitter went viral, driving thousands of downloads in the first few days. That single organic tweet fueled growth for months. But when Frederik wanted to scale, he turned to an ironic strategy: paying for ads on the very platforms his app was designed to block.

He started running ads on Instagram, and the results were explosive. “My revenue was kind of like doubling every single month,” he says.

The strategy worked because it was the ultimate form of targeted advertising. “Of course on social media, I find my target group of people that spend a lot of time on social media and want to spend less,” Frederik explains. Every single person scrolling through Instagram was a potential customer, and the ads caught them in the exact moment they were experiencing the problem one sec solves. It was the digital equivalent of his earlier strategy for a climbing app: putting physical posters up in climbing gyms.

The 57% constant and the power of peer-reviewed indie apps

Most indie developers rely on App Store reviews for social proof. Frederik went a different route: he partnered with the Max Planck Institute to conduct rigorous scientific research on one sec’s effectiveness.

The collaboration started when a researcher who used the app reached out. They set up an opt-in study where users donated their usage data. Frederik was hoping for a statistically significant 12% reduction in screen time. Instead, the data showed a massive 57% drop.

“All the experiments that we ran, they were always showing numbers around 57% reduction, which is kind of like almost seems like a nature constant of attention that you can steal from someone without noticing it,” he says.

That research became a massive competitive advantage. In a market flooded with snake-oil productivity apps, one sec had peer-reviewed evidence. Therapists began recommending it to patients. The app became a proxy for researchers who couldn’t get data directly from Meta or Snapchat, leading to partnerships with Stanford, Cambridge, and the governments of Germany, Denmark, and the UK.

Why an indie dev filed a US patent

With the research proving the app’s massive effectiveness, a friend from Silicon Valley pushed Frederik to do something unusual for a solo developer: file a patent.

The logic was simple. If the intervention worked this well, the big tech companies would eventually notice. A patent wouldn’t necessarily stop them from building their own version, but it would change the dynamic.

“This is the only way you can protect yourself from getting copied at some point,” Frederik says. “At least I wanted to give the big companies a reason to talk to me first before just copying or stealing my idea.”

It was an expensive and energy-intensive process, but having the peer-reviewed research data made the application much stronger. The US Patent Office approved it, giving this bootstrapped indie app a protective moat usually reserved for venture-backed startups.

In the full episode, Frederik also talks about getting an email from Apple for being an underage developer, how he manages a team of 18 people with zero management layer, and why he thinks Mastodon is the perfect non-addictive social network.

Guest links:

•Frederik Riedel on Mastodon

•one sec

RevenueCat supports app-to-web checkout — here’s why you shouldn’t use it

Tue, 14 Apr 2026 13:38:58 GMT

There is a version of this post that would probably perform better on social. It would say app-to-web is finally here, the economics are obvious, the app stores have been weakened, and every subscription app should rush to move checkout to the browser

I do not think that version would be very helpful

The honest version is simpler: yes, we support app-to-web checkout. We support it today with RevenueCat Billing / Web Billing, we support it with Paddle, we support Stripe Billing as a web billing system that can sync into RevenueCat, and we support Stripe Managed Payments in private beta

The other honest part is the one fewer people want to say out loud: most apps probably should not do app-to-web checkout

Not because it is impossible. Not because it is non-compliant in every case. Not because the tooling is not real. But because the financial upside is often overstated, while the operational, conversion, support, and retention side effects are understated. If you’re a large app with meaningful leverage, sophisticated lifecycle marketing, strong experimentation capabilities, and enough margin pressure to justify the work, app-to-web can make sense. If you are not, there is a good chance you are trading a simple problem for a much messier one

First, what we actually support today

If you strip away the noise and just look at the platform, RevenueCat Web is now a real product category for us. It includes a Web SDK, Web Purchase Links, a Web Purchase Button to link out from in-app paywalls, Web Paywalls, Web Funnels for web-to-app flows, and Redemption Links that help tie an anonymous web purchase back to the correct app user

The app-to-web flow we promote is straightforward in concept. A user starts on a paywall in your app, taps through to a web checkout, completes the purchase there, then comes back to the app via deep link or redemption flow and gets access unlocked. We keep entitlements in sync across app and web once the purchase is recognized

That sounds clean on a diagram because, to be fair, it is fairly clean on a diagram

In practice, the capability picture depends heavily on which billing engine you choose

Billing option	What we support today	Important caveat
RevenueCat Billing / Web Billing	Our own web billing engine with Web SDK and Web Purchase Links support, plus hosted purchase flows, subscription lifecycle handling, and customer management portal support	It uses Stripe as the payment processor underneath, but is a separate RevenueCat billing engine. Some limitations still apply, including localization gaps in some surfaces and country-specific billing-data limitations
Paddle Billing	We support importing Paddle purchases and support Paddle across Web SDK, Web Purchase Links, Web Paywalls, Web Funnels, and Redemption Links	Paddle-specific operational constraints still exist; for example, our Paddle integration does not currently support Paddle’s abandoned cart emails
Stripe Billing	We support importing external purchases from Stripe Billing and syncing entitlements back to the app Very soon, we’ll also support Web SDK, WPLs, Funnels, and Redemption Links	The main caveat is “which Stripe path are you actually choosing?.” Stripe Billing, Stripe Checkout, and Stripe Managed Payments solve slightly different problems, so teams should be precise about the implementation path they want
Stripe Managed Payments	We support this through the Stripe Billing integration, with Stripe acting as merchant-of-record for eligible transactions	It is currently a private beta / invite-only feature

That is the part I want to be very clear about, because ‘supports app-to-web’ can mean a few different things depending on what people hear. We do not just mean ‘you can hack a link into a button’. We mean there is now an actual product set for hosted web checkout, redemption, and entitlement sync. But it also does not mean every billing provider has identical maturity, identical feature coverage, or identical rollout status

There is another important nuance here. In the US, iOS developers are now permitted to guide users to web-based payment flows without additional Apple fees or restrictive design requirements following the Epic v. Apple ruling from early 2025. That’s in the US and on iOS only. For other platforms and other markets, app-to-web is sometimes possible, but always comes with additional fees, and reporting requirements. That means app-to-web is not a blanket ‘turn this on everywhere’ strategy. You need to make sure you control exactly who sees it and where

So why should most people not use app-to-web?

When people say ‘app-to-web’, what they often mean is ‘save 15% or 30% on store fees’. And what they often forget is that the fee is not the only thing that dictates how much money you take home at the end of the day

The first issue is the most obvious one:

1. Conversion usually gets worse

Every additional step between intent and payment hurts. Sending someone out of an app, into a browser or hosted checkout, through another authentication context, into a billing form, then back into the app is simply more fragile than native in-app purchase. Even if the flow is well designed, you are introducing context switching, more points of abandonment, more places for attribution to break, and more opportunities for a user to decide they’ll do it later. You might recover margin on the users who complete checkout, but if enough of them fail to complete it, the math stops looking clever

This is one of those areas where teams can accidentally fool themselves. If you only look at completed payer margin, web checkout looks great. If you look at paywall visitor to activated subscriber, it can look much worse. And for most subscription apps, the second number is the one that matters

The second issue is more uncomfortable because it can make your retention chart look better for the wrong reason:

2. People are often less aware of how to cancel web subscriptions

That can create the appearance of stronger retention or lower churn, but in many cases what you are really seeing is lower customer clarity. App store subscription management is not perfect, but users broadly understand where to go. The moment you split billing systems, some of your customers now manage on Apple, some on Google, some in Stripe, some in Paddle, some in RevenueCat Billing-backed web flows. That can absolutely reduce voluntary churn. It can also absolutely increase frustration, support load, refund requests, chargebacks, and a long tail of unhappy users who feel like billing became harder the moment they gave you money

In May of 2025, we launched a (much publicized) in-app purchase vs. web checkout experiment with an app we own. That experiment saw 6% fewer paying customers when we added web checkout. That same experiment currently has 2.7x (+170%!) more subscribers set to renew on web

	IAP only	IAP + web	Difference
Conversion to paying	7.8%	7.4%	– 5.1%
Active subscribers	211	209	-1%
Active subscribers (set to renew)	46	101	+ 119.4%
Churned subscribers	121	104	– 15%
Refunded customers	28	38	+ 35.7%

Those subscribers aren’t set to renew because, by paying on the web, they enjoy the app much more than they would if they paid via in-app purchase. They’re set to renew because they’ve forgotten to opt out of renewal

And that brings us to the third issue:

3. Chargebacks and disputes tend to become more material when you own more of the payment experience

App stores absorb a lot of mess for you. Once you move payment to the web, you get more control, but you also inherit more exposure. Tax handling, billing descriptor clarity, payment recovery behavior, lifecycle comms, cancellation UX, and support all become more consequential. Paddle and Stripe Managed Payments can help with the merchant-of-record and tax side for eligible flows, which is precisely why they exist, but that does not magically remove the conversion or support complexity of app-to-web. It just moves one painful category of operational burden off your plate

The fourth issue is the one small teams underestimate most:

4. The savings are often not that dramatic once you include all costs

We do not charge extra for RevenueCat Web itself, but the payment rails still do. In the US you pay 2.9% + 30¢ for Stripe processing, plus optional Stripe Tax fees where relevant. For Stripe Billing, our docs cite the same transaction fee plus Stripe Billing fees of 0.7% of volume, again before any tax tooling you may need. So say you’re selling a weekly subscription of $5 — you’d effectively pay Stripe close to 9%. Add the fee for Managed Payments, and you’re getting awfully close to the 15% most developers pay

If you are on Apple’s Small Business Program and paying that 15%, that is where the simplistic ‘save 12 percentage points’ narrative starts to fall apart. Between processor fees, billing software fees, tax tooling, engineering time, experimentation time, support cost, revenue leakage from lower conversion, dispute loss, and the long tail of operating multiple billing systems, your net improvement can get very small very quickly. In some businesses it will still be worth it. In many, it will not

And even if it works in a narrow segment, the fifth issue remains:

5. You are creating permanent complexity, not a temporary experiment

This is the part that almost nobody models properly

If you run an app-to-web experiment for three months and decide it was a bad idea, your web-billed users do not politely disappear. You still have to support them. You still have to honor their renewals, manage their cancellations, answer their billing questions, reconcile their subscription state, and maintain enough infrastructure so their access remains correct. Congratulations: your test is now a durable second billing stack

The app stores are opinionated, expensive, and frustrating. They are also operationally simple in ways people stop appreciating once they leave them

The hidden cost is organizational, not technical

Most discussions about app-to-web are framed as product or finance decisions. In reality, they are company decisions

You need product and growth to redesign the purchase journey. You need engineering to build routing, redemption, instrumentation, and edge-case handling. You need support to answer “Where do I cancel?” forever. You need lifecycle marketing to own the web renewal and churn experience. You need finance and ops to reason about taxes, disputes, reconciliations, and payout differences. You need legal or policy confidence on where you can and cannot show external payment paths. And you need analytics clean enough to tell whether the whole thing actually worked

That is a lot of machinery to spin up in order to maybe improve unit economics

This is why I think the average team should be much more conservative than the current conversation implies. The relevant question is not “Can I avoid app store fees?” The question is: “Am I capable of operating a better billing business than Apple or Google for this segment of users?”

For a lot of teams, the honest answer is no

When app-to-web probably does make sense

All this being said, there are real cases where I would absolutely consider using app-to-web

If you have a large US user base, high average revenue per paying user, meaningful paid acquisition economics, strong experimentation infrastructure, and enough support capacity to absorb billing fragmentation, then app-to-web can be rational. If you already have a serious web business, or if the web is strategically important beyond payments, it becomes even more attractive. If your app category naturally supports account-based behavior and cross-platform usage, users may tolerate the extra checkout friction better than they would in a lightweight impulse-purchase app

Likewise, if merchant-of-record complexity is the blocker, the fact that Stripe Managed Payments now exists, is genuinely interesting. If you want the most integrated RevenueCat-native route, RevenueCat Billing / Web Billing is what we support most directly today. If Paddle fits your tax and merchant-of-record preferences better, our Paddle path is a very capable option

If this topic is top of mind for you, on Tuesday April 28 (the day before Stripe Sessions) we’re co-hosting The Web for Apps Opportunity in downtown San Francisco:

A full day event that includes talks by RevenueCat and Stripe on how, where, and when to use web payments for your app. The afternoon concludes with a private executive dinner at 54 Mint

Apply to attend here

So this is not me saying never do app-to-web. It is me saying do it for the right reasons, with open eyes

My actual recommendation

If you are curious about app-to-web, do not start by trying to replace in-app purchases broadly. Start by treating it like a constrained experiment, with a proper hypothesis

Pick a narrow, eligible segment. Measure full-funnel conversion, not just net revenue on completed purchases. Track refunds, disputes, support tickets, cancellation confusion, and cohort quality. Check back one month, 3 months, 12 months after the experiment ends. Assume your support burden will be higher than the first spreadsheet suggests. Assume that billing fragmentation will last longer than the experiment does. Assume fee savings will compress after you include everything

And if, after all of that, the economics still work out, great. You probably have a real business case

But most teams will arrive at a less exciting and more useful conclusion: app-to-web can work, but not well enough to justify everything that comes with it

Stop measuring downloads: what to track before product-market fit

Tue, 14 Apr 2026 13:36:11 GMT

It’s such an exciting moment when you launch your app. You finally put it out into the world… now what?

It’s tempting to focus on what feels productive: building new features, testing prices, running ads. But if you don’t know whether you’re actually solving a real problem, most of that is just optimisation in the dark.

The metrics that feel good in that early phase — downloads, signups, even revenue — don’t necessarily tell you if you’re on the right track. They tell you people are showing up and trying the app, not whether they’re getting real value from it.

I see this constantly in growth audits. One client had over 90% onboarding completion, which sounds fantastic. But most users were gone by day two. Onboarding wasn’t the issue, but value was.

In this first, exciting phase of launching your new app or finding product-market fit, it’s critical to focus on metrics that reflect real value creation, not the shiny, ego-boosting ones.

We’ll talk about how to make that mindset shift, and from there:

Which metrics to ignore so you don’t get distracted
What metrics you simply can’t measure yet
What to focus on instead
How to find the one overarching metric to guide you.

We’ll also cover some traps and risks along the way, such as why retention alone doesn’t equal product-market fit.

And despite focusing on metrics here, please (she begs politely) don’t ignore qualitative signals. At this stage, qualitative feedback will guide you just as much — if not more — than quantitative data. You don’t have the luxury of large data sets yet, and that’s okay.

From there, I’ll help you define what finding product-market fit actually looks like for your app, so you leave with a clear list of metrics to focus on. This is the super-quick crash course version. If you want more depth, I highly recommend checking out my free course, How to make an app people will pay for, where I walk through this in detail and give you a full Product Strategy Canvas to apply to your own app.

Focusing on the right metrics helps you learn faster and move forward with confidence. At this early stage, that clarity makes everything feel a lot less overwhelming.

What really matters pre-product market fit

Product-market fit means building an app that solves a specific problem for a specific audience — with a solution that genuinely fits their needs.

It’s the point where you’re no longer persuading people to use your product — they want it. They love it, get consistent value from it, and choose to keep using it.

What finding product-market fit is about

The reality is that pre-product-market fit isn’t about growth.

Yes, you need some growth, enough to generate data, learn, and validate what’s working. But the core questions you’re trying to answer are:

Does my solution actually solve the problem?
Who values it the most?
What makes them come back?
What would they pay for?

A common trap at this stage is getting pulled into growth too early. Sometimes that pressure comes from investors. Sometimes it comes from a few early wins that make you feel ready to scale. You rush into paid ads, burn through runway, watch users churn, panic… and try to acquire even more users.

This is what Eric Seufert calls The Growth Trap.

Ironically, an over-focus on growth won’t help you grow. Product-market fit will.

When you fixate on growth metrics too soon, you might achieve short-term spikes, but not long-term, sustainable growth.

Instead, shift your mindset. At this stage, your job is to learn and to look for strong signals that product-market fit is emerging.

And here’s the good news: there are so many metrics you could track that I give you full permission to ignore most of them.

What metrics to ignore

It’s buzzword bingo for an early-stage founder; millions of metrics and fancy phrases thrown at you, from Cost of Acquisition to Lifetime Value. The problem? Not all of them actually matter at this stage.

So here are some of the most common metrics I give you 100% permission to ignore, or at least not obsess over:

Total downloads: Just because people download your app doesn’t mean they even open it or get value from it.
Total signups: Same idea.
Social media followers: Great for the ego, but meaningless if it isn’t actually driving awareness or value.
App store ranking: Might help growth a little, but it tells you nothing about whether you’re solving a real problem.
Day 1 download spikes: Don’t over-interpret early spikes; first users often behave differently than your eventual audience.

Other metrics, like time in app or number of sessions, can feel encouraging; they make free users look active, but none of them truly reflect value.

And that’s the key at this stage: are a specific group of users getting repeated value? If a metric doesn’t help answer that, toss it out.

Now, there are metrics that reflect value, but at launch, you often can’t measure them yet.

What metrics should you measure instead?

With this mindset shift, the metrics that matter pre-product-market fit are behavioral. It’s not about whether users showed up; it’s about whether they did the things that indicate they’re actually getting value.

Ask yourself:

Are users coming back on their own?
Are they using the core feature?
Are they willing to pay?
Are they telling others?

Together, these behaviors give you a clear picture of where users are dropping off and what you need to focus on.

The key concept here is activation. If you’re activating users, they’re more likely to retain and pay. Activation has a domino effect in early-stage startups. People won’t pay for an app they haven’t truly experienced; they haven’t reached the moment where the value clicks.

You’re looking for the behaviors that, over time, predict whether someone will stay and pay. Look for patterns across at least 2–3 cohorts before drawing conclusions. Even with small numbers, consistency matters more than volume.

Time to first value and time to core value

Two useful activation metrics building on product-led growth thinking popularised by Wes Bush:

Time to first value – Did the user experience something valuable?
Time to core value – Did they start building a habit?

For example, in a meditation app:

Time to first value might be the time to complete their first meditation session
Time to core value is when they’ve meditated at least four times in a week and started building a routine

These metrics help you understand not just whether users are signing up, but whether they’re actually engaging with and benefiting from your product.

The goal isn’t to over-index on speed, as some actions naturally take time. But in the early days, it usually takes too long, so you need to help users reach that value moment faster. It’s more about relative timing than absolute speed.

For example, in a food-scanning app, users who scanned at least 7 foods in a week were much more likely to stay than those who took 2-3 weeks to reach the same milestone.

The scanning feature was the main way users could check whether a food was safe to eat.

So the team could focus on how to help more users complete that action within a defined period, rather than just letting it happen organically, e.g., more in-app nudges to scan, examples of what you can scan with it, etc.

Active users

Alongside activation, having a measure of active users, defined by meaningful behaviors rather than just app opens, is extremely important.

Tracking whether you’re activating a higher percentage of users and doing it faster gives you a clear signal that you’re on the right track.

And, as always, this should be tied to the key behaviors you’ve identified as indicators of value.

Percentage of customers through word of mouth

Referrals are huge. If 15% or more of new users come through referrals, that’s a strong signal of product-market fit.

Word of mouth takes time to build in a new app, but if you start seeing more people talking about your product and your percentage of users acquired through word of mouth grows, that’s another clear positive signal.

What you can’t measure yet at launch

We’ve covered what you should ignore and what you should focus on.

Not to add confusion, but there are also valuable metrics that are hard to measure at launch:

Retention curves need weeks
Realized lifetime value per customer can take months to start to pin down
Same with sustainable growth

It’s not that you shouldn’t measure these metrics at all; it’s just that at launch, you can’t judge success by them yet.

Instead, focus on leading indicators — the behaviors that signal value early — rather than lagging indicators, which reflect outcomes further down the line.

Leading indicators: activation, early retention, qualitative feedback
Lagging indicators: lifetime value, revenue, long-term retention

Leading indicators act as your early warning system. They show whether something might be off track before the final results are in, letting you be proactive rather than reactive.

Retention

One of the most common metrics people tell you to track in this early phase is retention.

While it takes time to really understand your retention curves, you can start by looking at 7- and 30-day retention.

But here’s the trap: over-indexing on retention too early can be dangerous.

Apologies for the upcoming rant, but honestly, it felt much-needed. We can’t talk about pre-PMF metrics without diving deeper into the risks of equating retention with PMF.

The retention trap

Often, it feels like product-market fit is the same as retaining customers. But you can keep people around without actually solving their problem.

Strange, but I’ve seen it happen. Good retention can make an app feel like it has product-market fit before it really does.

There are four ways this can happen.

1. Gamification over value

The first trap is relying on mechanics — streaks, reminders, badges — to drive retention without delivering real value. These are classic forms of gamification.

I’ve experienced this myself. I got completely hooked on a game, loving the streaks that kept me coming back. But eventually, I realized I wasn’t really enjoying myself anymore. I was returning because of the mechanics, not the value. And yet, I couldn’t bring myself to delete the app until I quit cold turkey.

2. Retention is driven by a small group of power users

This isn’t inherently bad, but it’s something to watch closely.

It’s all about balance: are you too specific, or is your core group too small to scale? If growth only happens within this small group, your product-market fit might not be ready to scale.

You need to be specific enough to stand out, but not so niche that you’re building for only a handful of users who aren’t representative of a larger market.

3. Pricing that masks weak product-market fit

This happens when heavy discounts or extended trials are offered. Sure, it attracts a lot of users, but often bargain hunters. You might see strong retention numbers from users who signed up for an annual subscription at a very low price, but they’re not actively using your app.

4. Annual subscriptions can delay churn rather than prevent it

Annual subscriptions are great for cash flow and have plenty of benefits. But if most users aren’t actively engaging with your app, locking them in doesn’t mean they value it.

The lesson: commitment isn’t the same as conviction. Someone locked into an annual plan is not the same as someone who would be devastated to lose your app.

To avoid this trap:

Pair retention data with engagement data: if users are renewing but not actually using the app, dig deeper before celebrating
Rely on qualitative signals to understand your users’ experience and motivations

Qualitative signals to focus on

In the early days, you don’t have massive numbers, and that’s completely normal. With small sample sizes, it’s hard to distinguish noise from signal, and the variance in metrics can make even the steadiest founders nervous.

This is why qualitative signals are extremely valuable. Remember: product-market fit is qualitative first, quantitative second. You’ll feel it before you can measure it: users reaching out unprompted with feedback, telling you how much they love it, asking when features are coming, referring friends without being asked. It’s little moments like that, where growth also feels easier that tell you long before you hit statistical significance that you’re on the right track.

The Sean Ellis test

Sean Ellis studied hundreds of startups to find what separated the ones that went on to succeed. He discovered that successful startups typically had at least 40% of users who would be very disappointed if the product no longer existed.

He created a simple PMF test to measure this:

Ask users: ‘How would you feel if you could no longer use [app name]?’
- Very disappointed
- Somewhat disappointed
- Not disappointed
- I no longer use this
Follow up with: ‘Could you explain your answer?’

That second question is critical; it helps you understand what actually drives product-market fit, even if your sample size is too small for statistical significance.

That second question means that even if you don’t have enough data for significance, you can start to understand what drives PMF.

A few practical tips:

You need enough responses to get meaningful insight: at least 100 for a general sense, and 500–1,000 if you want to segment by signup reason, main feature used, or other factors
Survey the right users at the right time, ask those who should have reached their aha! moment:
- Don’t survey day-one users if it normally takes 7 days to get value
- Don’t limit it to users who’ve been around for months, either, or you risk skewed optimism

This test gives you a qualitative measure of product-market fit, helping you identify both the level of engagement and the reasons behind it.

Net Promoter Score (NPS)

The Net Promoter Score correlates strongly with this. For example, Ladder found that users who said they’d be ‘somewhat disappointed’ had much lower NPS scores than those who said ‘very disappointed’.

It can be valuable to ask, alongside your PMF question, why users would or wouldn’t promote your app. This gives insight not only into how much people value your product, but also what drives advocacy and highlights areas you can improve to turn more users into promoters.

User interviews

If you don’t have enough users for the Sean Ellis test or measuring NPS, the best recommendation I can give you is to conduct user interviews to hear first hand from customers why they love and don’t love your product.

Starting with even just 5-10 Jobs-to-be-Done (JTBD) interviews will teach you so much about:

What drives users to stay
What matters most to them

I recommend prioritizing users with whom you suspect you might have product-market fit as well as recently churned users with a similar need. That way you can understand what the difference is and what to prioritise to improve.

This also ensures you don’t get distracted by noisy users and keeps your focus on the behaviors and needs that really indicate product-market fit.

Finding your North Star Metric

As you start to narrow down which metrics actually predict value and gain insights from qualitative research, it’s incredibly helpful to have an overarching metric to guide you.

This is known as the North Star Metric: the single best metric that indicates whether users are getting value, whether you’re getting value, and whether you’re building a sustainable business.

Post-product-market fit, North Star Metrics often look like active subscribers or monthly recurring revenue. But pre-product-market fit, it’s crucial that this metric is behavioral, focused on the actions that show users are truly experiencing value.

For example:

Spotify focuses on time spent listening
Slack focuses on messages sent
Dropbox on files uploaded.

They’re all measuring core actions that signal value.

These are companies that have already found product-market fit. For you, the goal isn’t to copy their metric; it’s to find the equivalent for your app at your stage. Start with a core hypothesis:

What is the core problem you’re solving?
What behaviors would indicate it’s being solved?
And how often should that behavior occur?

For instance, a budget-tracking app might hypothesize that users who categorize at least 5 transactions per week are deriving value. Ideally, your metric includes both the specific action and the time frame you want to see.

Post-product-market fit, your North Star Metric should remain stable unless you make a major pivot. But pre-product-market fit, it’s okay to refine it as you learn more. You probably won’t know with confidence exactly what that action is or what the North Star Metric should be, and that’s completely fine.

Defining PMF for your app

Now it’s time to get practical. You’ll want to write down what your PMF definition looks like in behavioral terms.

The template I use and share in my ‘Make an app people will pay for’ course is the following:

I’ll know I’m approaching PMF when [specific user type] repeatedly [specific behavior] because my app helps them [specific outcome].

For example:

I’ll know I’m approaching product-market fit when busy parents repeatedly open the app after dinner to plan tomorrow’s meals because my app helps them save 20 minutes of decision-making stress.

Or:

I’ll know I’m approaching PMF when people trying to build new habits repeatedly log at least one habit daily for 10 days because my app helps them make it satisfying to see their streak grow.

One important note: PMF signals are directional. At this stage, you might see them in just one segment, one use case, or one geography, and that’s perfectly fine. You’ll probably start niche and expand.

If you find PMF in an unexpected segment, that’s actually valuable information. It might mean doubling down on that audience rather than trying to force-fit your original target.

Stress testing your PMF definition

To test whether your definition is strong enough, ask yourself:

Do activated users who engage in that behavior retain significantly better?
Does the pattern hold across cohorts?
Does improving the metric improve downstream outcomes?

In case you haven’t noticed, I love making you ask yourself questions. It’s so easy to rush as a startup, so it is important to force yourself to reflect on your decisions.

When to move on from this phase

So how do you know when you’ve done enough to get PMF and it’s time to shift focus?

There’s no perfect moment, but there are signals that suggest you’re ready:

40% or more of users say they’d be ‘very disappointed’ without your app
Your retention curve starts to flatten after a few weeks rather than dropping off completely
Users are coming back on their own without push notifications or reminders
You’re seeing organic referrals — people telling others without being asked
Users are willing to pay without heavy discounts or extended trials

You don’t need all of these, but if you’re seeing a few of them consistently, especially within a specific segment, that’s a good sign you’ve found something worth building on.

From here, you move into what’s often called product-model fit, making sure your monetization model matches how users experience value. That’s where pricing, packaging, trials versus paywalls, and funnel decisions come in.

You also start to focus more on channel metrics, trying to work out which channels will drive scale for you.

But those decisions around monetization and channels are so much easier when you’ve already validated that you’re solving a real problem for a specific group of people.

Time to define your metrics

Pre-product-market fit, your job isn’t to grow. It’s to learn. That means ignoring the metrics that feel good but don’t tell you anything and focusing on the behavioral signals that show whether users are actually getting value:

Ignore	Focus on
Total downloads	Users returning on their own
Total signups	Core feature usage
Social media followers	Willingness to pay
App store ranking	Users telling others
Day 1 spikes	Repeat usage in the first week
Time in app (without context)	Active users (defined by behavior)

Here’s a quick checklist to keep you on track in this pre-PMF phase:

Shift your mindset from growth to learning
Identify the vanity metrics you’re going to ignore
Define what time to first value and time to core value look like for your app
Set a behavioral North Star hypothesis
Write your PMF definition in behavioral terms
Talk to users → PMF surveys, NPS, user interviews
Focus on leading indicators, not lagging ones

It’s hard to resist the pull of growth, especially right after launch when the numbers are moving. But if you nail product-market fit first, everything that comes after — your funnel, your pricing, your ads — will work so much better.

If you want to go deeper on defining your strategy and finding the right audience before diving into metrics, that’s exactly what I cover in the StartApp School course: Early product decisions: How to build an app people will pay for. I’m excited to hear what you think!

Track in-app ad revenue alongside purchases: get the full picture on monetization

Mon, 13 Apr 2026 14:09:18 GMT

For apps monetizing through a mix of ads and in-app purchases, understanding your total revenue has historically been a fragmented, frustrating process. You’re forced to stitch together dashboards, export CSVs, and build custom pipelines just to answer basic questions: What is my actual revenue across all channels? How valuable is a user who never subscribes but watches ads for six months? What percentage of my revenue comes from ads versus subscriptions?

The result is a blind spot in your data. You’re left making slow decisions based on incomplete Lifetime Value (LTV) metrics and guesswork.

That’s why we’re excited to release In-App Ad Revenue Tracking in RevenueCat in public beta. You can see your complete monetization health, blending ads alongside subscriptions and one-time purchases, all in one place.

One dashboard for your complete revenue picture

RevenueCat now ingests ad revenue events in real time alongside your purchase data. This means no more bouncing between ad network dashboards and RevenueCat to understand your total revenue.

Here is what you can explore as part of the beta:

Unified revenue and realized LTV

Ad revenue is now folded directly into your main Revenue Chart. ‘Total revenue’ finally means total revenue. Furthermore, your Realized LTV now incorporates ad revenue, giving you a complete picture of cohort value. You can finally understand the true worth of your users, not just what your subscribers paid.

Dedicated ads reporting

We’ve added a dedicated Ads section in the Charts tab. Here, you can track the metrics that matter most to your ad monetization strategy:

Ad Revenue: The foundational number of total revenue generated from ads.

ARPDAU (Ad Users): Average Revenue Per Daily Active User, the key blended health metric for hybrid apps
Ad Monetized Users: track the number of times users clicked on ads in your app — clicks indicate user engagement with ads and can help you understand which ad placements and formats are most effective
Ad Impressions & Fill Rate: total ad displays and the percentage of ad requests successfully filled, letting you keep an eye on targeting issues or limited ad inventory
Ad RPM & CTR: revenue per thousand impressions and click-through rate to measure monetization efficiency and engagement quality
eCPM: compare monetization efficiency across different time periods, countries, or platforms regardless of total impression volume

Per-user ad visibility

The Customer Details page now includes a dedicated Ads tab. You can dive into individual user profiles to see their Total Ad Revenue, Impressions, Clicks, Fill Rate, CTR, eCPM, and impression timestamps.

How it works: one SDK, one integration

It’s incredibly simple to set up with the RevenueCat SDK. If you’re using Google AdMob, you simply replace your standard AdMob loading calls with the loadAndTrack methods from the RevenueCat SDK and that’s it. All ad events are tracked automatically.

If you’re using any other mediation platform that provides impression-level revenue data — such as AppLovin MAX, ironSource, Unity Ads, and many more — you simply call RevenueCat’s AdTracker methods in your ad SDK callbacks at the right time.

Whether you use AdMob or another platform, it’s still the same reliable RevenueCat SDK under the hood. For full integration details and code examples, check out our ad monetization docs.

What’s next for Ad Revenue Tracking

This beta is focused on getting the foundational data right and giving you a unified view of their revenue. While we do not measure campaign attribution (we are not an MMP) and we aren’t replacing your mediation platform, we are adding the crucial subscription context to your ad data.

Note: Because RevenueCat uses real-time SDK data and mediation platforms like AdMob use post-processed, fraud-filtered data, you may see slight discrepancies in the exact numbers. This is expected and fully documented.

Looking ahead, we’re working on bringing even more powerful insights to this feature. Fast-follows will include blended ARPDAU across all users, and future updates will introduce predicted LTV with ads and analytics showing how ad exposure impacts subscription conversion and churn.

Unify your data and start making better decisions based on the full picture — get started today

If your app monetizes with ads through platforms like Google AdMob or AppLovin, you can start sending ad events to RevenueCat today.

Check out the docs for more >

Any customer can request access to the feature by navigating to the Ads page in their RevenueCat dashboard.

Russia’s App Store payment block: how it impacts your MRR and what to do next

Thu, 09 Apr 2026 17:07:21 GMT

Following a recent Russian government directive, as of April 1, Apple has officially stopped processing payments for all App Store purchases and Apple Media Services in Russia. This means Russian users can no longer make new purchases or renew existing subscriptions using traditional payment methods.

While card payments have been blocked for some time, a popular loophole allowed users to top up their Apple ID balance via mobile phone operators. This new change firmly ties that loophole closed.

The status quo

For subscription app developers, this is a hard stop on a major revenue channel in the region. Unless a user already has existing funds in their Apple Account balance, their subscription will not renew.

The good news for users is that they won’t immediately lose everything. Apps and content previously purchased will remain available, and Apple has confirmed that iCloud+ data will remain accessible even after a subscription lapses. However, premium features tied to active subscriptions will inevitably be cut off once the current billing cycle ends and the renewal fails.

What we know about the block

According to reports, the Russian government ordered mobile operators to disable the Apple ID top-up option. This move is widely seen as part of a broader crackdown on online information, specifically targeting the use of paid VPN apps that allow citizens to bypass internet censorship.

By cutting off the ability to pay for these services, the government effectively restricts access to them. As a result, this blanket ban catches all subscription apps in its net, regardless of their developer HQ, app category or purpose.

Some users have already found workarounds by using gift cards to top up their Apple balance, while others are changing the country of their Apple account, or even making a second account in another country with a different bank account. The consequences (from the Russian government or Apple) of pursuing either of these methods remains unclear.

What developers can do now

For most developers, the impact on global MRR will be minimal. However, if you have a significant user base in Russia, you stand to lose a chunk of revenue. Here are a few practical steps you can take right now:

Assess the impact: check your RevenueCat dashboard to see exactly how much of your active MRR comes from Russia. This will help you forecast the upcoming drop in revenue as renewals begin to fail.
Communicate with users: send an in-app message or email to your Russian subscribers. Inform them of the change and remind them that they can still use existing Apple Account balances or redeem any App Store codes they already have.
Offer alternative payment routes: if your app is multi-platform (e.g. accessible via the web), you can direct users to complete their purchases outside the App Store ecosystem. Just keep in mind that international sanctions and financial regulations around Russia are complex and constantly shifting – make sure you understand the rules that apply to your business before accepting payments from the region.

While the situation is largely out of developers’ hands, proactive communication, a clear understanding of the data, and alternative methods (like web-to-app) can help cushion the blow.

Inside Noom’s web-to-app onboarding funnel: how 113 screens build commitment before the paywall

Thu, 09 Apr 2026 14:00:03 GMT

Noom’s web-to-app funnel is extensive, like really extensive. The weight loss subscription app has one of the longest app onboarding funnels I’ve ever analyzed. Walking through it carefully and taking notes took around an hour and a half, and even a faster ‘quick’ run-through as a typical user still clocked in at 10-15 minutes, with up to 113 screens along the way.

Yet somehow, it never feels exhausting.

Instead, the experience feels personal, thoughtful, and surprisingly educational.

Why is Noom’s onboarding flow so long?

What makes Noom’s approach worth studying isn’t just the length of the funnel, but how intentionally that length is used. Every question clearly builds toward a payoff, sensitive moments are met with reassurance, and by the end, you genuinely feel as though the plan was designed specifically for you. Noom strikes a rare balance between asking for input and delivering value, and that’s what makes the funnel work.

Before we dive in, one important note: I’m human. I know, shocking. While I’ve worked to walk through as many variations of Noom’s flow as possible, there are inevitably moments I may have missed or paths I couldn’t fully test.

At one point, users are asked ten questions with four possible answers each, that’s 262,144 potential combinations. But fear not: this human did the homework to surface the most meaningful patterns and takeaways, testing roughly 20 different paths to ensure the core learnings are well represented.

So let’s walk through what makes this quiz-based onboarding funnel work and see what you can apply to your own web-to-app funnel. You can check out the full flow here.

1. Goal selection that reduces pressure

Noom opens with a question that’s refreshingly direct: What’s your weight loss goal? That clarity matters. If you’re a weight-loss app, hiding it creates uncertainty later.

But the clever part lies in the options themselves. It’s not just “lose weight.” Users can also choose “maintain weight and get fit” or “I haven’t decided.” That final option may seem small, but it does important work: it removes the pressure to have a perfect answer on the very first screen and prevents users from feeling like they’ve already ‘failed’ before they’ve even started, especially critical when the first step is often where drop-off is highest.

Noom also allows users to switch units (stones or kilos). It sounds minor, but it matters. Confusion at this stage leads to inaccurate inputs, and inaccurate inputs erode trust. I may live in the UK, but I still couldn’t confidently tell you how much a stone is, and Noom smartly removes that friction before it becomes a problem.

2. Handling sensitive questions with care

Where Noom really stands out is in how they handle personal, potentially uncomfortable questions. The flow next asks about:

Sex assigned at birth
Gender identity
Pregnancy status
Current weight
Medical conditions

These aren’t casual questions. In a category like weight loss, where vulnerability and self-judgment often show up early, the way questions are framed is critical. Noom addresses this by consistently doing four things:

A. They explain why before you can overthink it

Noom asks sex assigned at birth. This can easily feel intrusive or irrelevant:

Noom does something many apps skip: it explains why, and it does it on the same screen. The framing is straightforward: hormones can affect how our bodies metabolize food. Whether or not every user fully agrees with the science, the key point is that it doesn’t feel like a random data grab.

They also introduce a progress indicator early on, which matters because at this stage, users are silently asking one question: How long is this going to take?

This isn’t just UX politeness, it’s trust-building. When users understand why information is being collected and how it will be used, they’re far more willing to share personal details.

Next, Noom asks about gender identity, separate from sex assigned at birth. This is one of those subtle moments where product design quietly signals: we’ve thought about real people.

Asking this way reduces the risk of mispersonalization and makes users more comfortable sharing personal information, because the app demonstrates care in how questions are framed.

Since I selected “woman,” Noom followed with a pregnancy question. They don’t let you simply continue if you indicate you are pregnant; instead, they clearly explain the app isn’t designed for that situation and require you to sign a waiver to proceed. This thoughtful approach balances user safety with transparency.

B. They reduce the mental load to keep you moving

I loved the age banding here:

Instead of forcing users to enter exact ages or navigate fiddly brackets (20–24, 25–29, etc.), Noom uses broad ranges like twenties, thirties, and forties. I mean, 21 vs. 29 years old… very different, but at least they are making it easy for us.

In a long onboarding flow, this kind of simplification matters. It maintains momentum without sacrificing the usefulness of the data, and it reduces the pressure or overthinking that can come with sharing personal information.

C. They reassure you right after the hardest moment

Next comes height and current weight. Noom knows this can be sensitive, so they soften the request with: “We don’t mean to pry, we just need this to build a plan that’s right for you.”

When you submit your weight, the app responds immediately with: “Thank you for sharing. That’s an important and hard first step.” This isn’t just polite copy, it’s a micro-moment of emotional safety, arriving right when a user might feel judged.

One interesting choice: there’s no ‘I don’t know’ option for weight. That could create friction for users who avoid weighing themselves, but my guess is that weight serves as the anchor for the results graph later. In this case, Noom prioritizes data completeness over comfort. But perhaps that same clarification it offered earlier would be helpful here, so users understand the need.

D. Personalization that feels real (even when it isn’t)

Noom asks about health conditions next, with a multi-select list and a simple UI pattern that makes it clear you can choose more than one.

What stood out is what happens after you select something: you get a supportive message (“We’re so glad you shared…”), and it works even though it’s probably not truly personalized to your exact condition (the message remains the same no matter what you fill in).

That’s a smart tradeoff. With dozens of possible condition combinations, you don’t need custom copy for every branch. A single, well-written reassurance screen can still feel personal because it addresses the emotional reality of what just happened: the user admitted something vulnerable.

Noom also continues to explain why questions are being asked as they get more serious (e.g., diabetes, eating disorders). Not every condition needs the same level of explanation, but the consistency builds trust.

Additionally, Noom adapts follow-up questions based on your answers. For example, if you indicate you have diabetes, the app asks up to two additional questions tailored to the type.

These moments of conditional logic make the experience feel tailored without requiring every question to branch infinitely.

The eating disorder question that follows is a tricky one:

As someone with close friends who have struggled with eating disorders, the waiver alone doesn’t feel sufficient. I understand that if the flow stopped entirely, some users might be tempted to skip ahead, but even with the additional confirmation step, it still feels a bit too easy.

Notably, if you answer ‘no,’ the app doesn’t ask about any previous eating disorders, so that’s something to be aware of. This feels more like a moral consideration than a UX flaw, but I do appreciate that Noom at least doesn’t continue as if nothing happened when someone answers ‘yes.’ It shows some level of responsibility in handling sensitive health information.

Their slight redemption in my eyes? Two steps later, if I enter a weight that isn’t medically healthy, they won’t let me continue until I enter a weight that isn’t classified as underweight.

3. Turn a long form into a series of small wins

After filling in a lot of personal questions, Noom takes a moment to pause and shows the following screen:

The image of people on a hand is playful and approachable, especially paired with the phrase ‘you are in trusted hands.’
The visual of climbing the line subtly signals that weight loss isn’t a straight downward journey, showing that Noom will support users through the hardest parts, like when weight temporarily increases.
The statistic, “we’ve helped 3,627,436 people lose weight,” is both specific and significant, giving the claim credibility.
The stat is backed with a data source and a defined minimum result (at least 2%), which further strengthens trust.

One minor issue: the stat is dated October 2021. Specificity builds credibility, but an older timestamp can create tension, slightly undermining the message.

4. Set expectations early, then repeat them on purpose

Throughout the flow, Noom constantly manages your expectations for what the app can and can’t do. There are three clever ways they do this:

A. The goal weight becomes the backbone of everything

Now Noom asks for your ideal weight and explains how it will use that number to predict a timeline and build a custom plan:

When you enter something unrealistic or unhealthy, the flow blocks you:

That’s a rare and important signal. Noom is willing to sacrifice a conversion rather than encourage harmful behavior, as noted earlier. It stands out as one of the clearest examples in the entire experience of the principle: we won’t optimize conversion at any cost.

B. The 0.5-1 kg message is repeated strategically

This is where Noom starts repeating a key expectation: subscribers typically lose 0.5-1 kg per week. They say it:

On the goal screen
Next to testimonials
With your projected timeline

Normally, repetition can be a UX sin. Here, it’s strategic and serves as clear expectation management. If users expected to lose three kilos a week, they’d assume the product was broken. Noom anchors users to a healthier, realistic pace before they ever pay a dime.

C. The graph reframes the competition

Noom then shows the projected journey: a steady trend line versus the yo-yo effect of restrictive dieting:

This is a subtle but important move: Noom’s competitor isn’t just ‘another app.’ It’s crash dieting, inconsistency, and short-term motivation. The graph makes that comparison visual, which is far more persuasive than simply stating it in copy.

Next, Noom asks what you want to focus on: nutrition, movement, habits, or ‘other.’ I noticed a few of these practical questions appear throughout the flow. At first, they felt a bit random, but it soon became clear that this is likely strategic: spacing out the practical, must-ask questions keeps users engaged and prevents them from getting ‘bored’ with the flow.

5. Make the payoff visible before you ask for the email

A. The event question creates a deadline

Next, Noom tries to identify a motivator, often framed as an upcoming event such as a holiday, wedding, or reunion. This makes sense: events create deadlines, and deadlines create urgency.

It can feel a bit superficial if a user’s true motivator is health, confidence, or energy. Noom softens this by including a ‘no event’ option, but the flow still nudges users to pick something, even asking them to specify a date.

B. Pace gives you control

Then you choose your pace: fast, slow, and steady, or in between.

This is a simple control mechanism that addresses a common objection: ‘This won’t fit my life.’ Even if it doesn’t drastically change the plan, it gives users a sense of agency.

Noom follows with a testimonial and repeats the weight-loss pace statistic. Here, repetition is intentional as they want that expectation firmly embedded before users even see their results.

Interestingly, how fast I indicated I wanted to lose weight didn’t seem to affect the projected end date, even though I might have expected it to.

C. The loader does conversion work

Noom shows a short ‘calculating your plan’ screen before asking for your email.

That pause does two things. It makes the result feel earned, and it gives them a natural moment to introduce the idea that something valuable is about to be revealed.

D. The email gate appears at exactly the right time

About a third of the way through, Noom asks for my email, right before showing the results graph. The timing is smart: I’ve already invested enough in the flow that I want to continue, but I’m not so deep that I feel frustrated they’re only asking now.

The CTA isn’t a generic “Submit,” it’s “See my results.” They immediately clarify what I’ll get: a personalized weight-loss timeline and an estimate of how much I can lose before my holiday, a goal I indicated earlier.

They also separate the marketing opt-in into its own step, framed as “occasional research, advice, and special offers,” signaling both low volume and higher value.

6. Deliver the ‘this was built for me’ moment

Then Noom delivers the payoff: a results screen with your goal date, your event marker, and a realistic projection.

Tone matters here. Noom doesn’t overpromise; for example, if your event is in two months, they don’t suggest you’ll magically hit your ultimate goal by then. That realism builds more trust than aggressive promises ever could.

This is also where you see why some of the earlier questions were non-negotiable. Without a starting weight, a goal weight, and a deadline, this personalized results screen couldn’t exist.

7. Use an onboarding quiz to increase buy-in, not just collect data

After the initial health questions, Noom shifts into what they call a ‘behavioral profile quiz.’

It uses sliders between two statements, repeated across 10 questions. The structure is deliberately consistent:

You always know what to do
You always see progress (“Question X of 10”)

There are also subtle visual cues built in. For example, if you choose “Agree a little more,” the background color is slightly lighter than if you select “Agree most.” These small touches guide the user’s perception without being overt.

The end result is an analysis of my profile, this time with a shorter loader and no message, followed by the presentation of my personalized profile.

I tested extreme answers, including negative self-image, to see if Noom would respond poorly. What impressed me is that it frames the results constructively, acknowledging what you said without reinforcing shame.

They’re not ignoring what I said, but they’re also not reinforcing negative self-talk. This feels like a careful balance.

8. Teach the ‘method’ inside onboarding

Rather than waiting until you have the app to start learning, Noom integrates small learning moments throughout the onboarding flow in various ways.

A. Selective empathy screens

After the profile, Noom asks practical questions about things like gym memberships, apps, and meal kits, another small, seemingly random question checked off early in the flow.

Next, the flow moves into agreement statements covering habit barriers, social impact, convenience, and decision fatigue. Interestingly, some answers trigger an additional reassurance screen, while others do not.

This creates a sense of responsiveness without forcing the flow to branch endlessly. It’s selective empathy, applied where it’s most likely to reduce drop-off.

B. The plan starts to feel more achievable

They also ask about lesson timing — “When would you like daily lessons?”—which is a smart operational detail disguised as personalization. In reality, it’s about choosing a routine that will stick.

The flow returns to the graph, with the dates moving forward, interspersed with a few practical questions along the way.

C. A product demo without showing the product

This is where Noom’s onboarding effectively becomes a product demo, without ever showing the app interface.

They introduce the green/yellow/red system through questions about what you’ve eaten, then explain calorie density. The messaging is carefully non-shaming: there are no ‘bad foods,’ only foods that help you feel fuller for longer.

Even the cravings question — mine was sweet, so I picked honey (though I wished chocolate had been listed) — becomes a teaching moment: “There’s room for it. Just be mindful.”

This is objection handling at scale, addressing questions like:

‘Will I be hungry?’
‘Will I have to give up foods I like?’
‘Is this going to be restrictive?’

Noom answers these before you even reach the paywall.

The flow then returns to another slow loader, which Noom uses again as a teaching moment to explain how the app works.

The screen slowly switches as it continues to build your plan:

D. Personalization only feels real when it cashes the cheque

When Noom asks about dietary restrictions or physical limitations, you naturally expect an immediate follow-up.

Earlier in the flow, every meaningful answer led to a tailored next step. When that doesn’t happen here, it stands out.

It’s a reminder that personalization isn’t just about collecting data; it’s about showing users how their answers shape what they see next.

This creates a sense of progress and reward: the more I share, the faster I can achieve my goal.

It doesn’t feel manipulative. Instead, it’s as if Noom is saying, “Based on what you’ve told us, we think you can do this faster than we initially thought.”

Interestingly, even when I indicate a limitation or provide ‘negative’ answers, the goal always moves forward.

9. Use a relevant bonus to turn intent into action

From there, it asks about what else you want to achieve:

Interestingly, even if you don’t provide answers about reducing stress or emotional wellbeing, you still go through a mini quiz on the topic.

Noom uses this to calculate a stress score and offers to add stress management to your plan, using a low-pressure line: you can remove it later.

This immediately raises a question: What does it cost?

Strategically, that uncertainty works in Noom’s favor, because the pricing reveal comes later — paired with a time-limited incentive. At this point, I don’t know the cost, but I’m willing to continue because the framing feels low-pressure.

This becomes important during the pricing step, where the stress management course is offered as a ‘free enhancement’ if I sign up within 15 minutes. This approach is smart for two reasons:

The 15-minute countdown creates urgency.
A free course feels more believable than a discount — I’m less likely to think ‘this countdown is fake.’

The flow then continues with a few questions about motivation and emotions, mainly to reinforce the value of the plan being offered.

Finally, they check about other goals too:

Before moving into another mini quiz on nutrition, which ties back to the earlier point about teaching the method during onboarding.

I love how, even when you get an answer wrong, Noom stays positive and non-judgmental, maintaining a consistent tone of voice throughout the entire flow.

Another final standard question to check off, and the flow is almost complete. My main thoughts: 1) Why so many options? 2) The order feels a bit random.

10. Show how the insights are used

Believe it or not, after about 100 screens, we’re nearly there! The final act brings everything together into the ultimate plan.

A. When questions turn into a plan

You see the loading screen that says Noom is ‘building your plan,’ but it’s more than just a spinner. In the background, the product is combining everything you’ve shared so far, from weight-loss goals to eating and nutrition habits.

This moment matters because it shifts the psychological contract. Up until now, you’ve mainly been answering questions; now it feels like Noom is actively working for you.

That shift is what makes the next section feel earned, rather than frustrating after a long flow.

B. The fake loader that actually does real work

Noom uses loading screens in two ways throughout the flow:

Short loaders that create a brief pause after effort.
Longer loaders that mix in additional questions, like this section.

Even if the ‘processing’ is partly theatrical, it feels more believable because the interruptions show your inputs actively shaping the plan.

They further reinforce credibility by referencing “millions of successful users,” using social proof framed as evidence of model quality.

Even after this, the app loads again, but this time it feels conversational, almost like “We’ve heard you. Now we’re doing something with it.”

It gradually reveals what’s happening and builds excitement for the final result.

11. The ‘pay what you want’ trial

Then comes one of the most unusual pricing moments I’ve ever seen: Noom asks how much you’re willing to pay for a 14-day trial, offering three options.

It’s framed with cost transparency (“it costs us X to offer this trial”) and an altruistic nudge (“help others access Noom”). Functionally, your choice doesn’t change the offer, but psychologically, it reframes pricing as a contribution rather than an extraction.

That said, I did notice the outdated date (September 2021)… yes, I’m nitpicking. On one hand, it probably costs them more now, so I’m getting a deal. On the other hand, it made me wonder why it hasn’t been updated in over three years.

Regardless of which trial price you choose, you proceed to the same offer in terms of costs after the trial.

12. What the app actually looks like? Unclear.

My biggest critique: after all of this, I still don’t know what the app experience actually looks like. I understand the plan, the psychology, the framework, and the promise, but I haven’t seen:

What food logging looks like
What the daily lesson experience looks like
What ‘success’ looks like day-to-day inside the product

For a flow this long, one or two UI glimpses could likely increase confidence right before purchase, especially for users wondering, ‘Will I actually use this?’

What makes Noom’s quiz funnel effective?

Here’s a quick recap on the key takeaways from Noom’s web-to-app onboarding funnel:

Reduce pressure at the first step. Let users ease into commitment. An ‘I haven’t decided yet’ option can prevent early drop-off without weakening intent.
Explain why you’re asking personal questions. Sensitive questions feel safer when users understand how their answers will be used to help them.
Offer reassurance immediately after vulnerable moments. A simple ‘thank you for sharing’ at the right time can dramatically increase trust.
Use progress indicators to make long flows feel lighter. Showing how far someone has come reduces perceived effort and keeps momentum high.
Set expectations early and repeat them on purpose. Repetition isn’t a UX failure when it anchors users to realistic outcomes.
Visualize the alternative you’re competing against. Noom doesn’t just sell itself. It shows why crash dieting fails and reframes the real competitor.
Make the payoff visible before asking for commitment details. Show users what they’ll get before asking for their email. Results first, data second.
Reward effort with visible progress. As users invest more, Noom moves dates forward and sharpens projections. That feedback loop motivates completion.
Use quizzes to increase buy-in, not just collect data. Consistent structure, clear progress, and non-judgmental framing turn quizzes into commitment devices.
Teach your framework during onboarding. Introducing the green/yellow/red system early removes objections before pricing ever appears.
Build commitment before introducing price. By the time Noom shows pricing, users have already invested time, effort, and emotional energy — a proven driver of paywall conversion.
Show the product, not just the promise: After such a long, thoughtful flow, users still need clarity on what day-to-day app usage actually looks like, a key area where Noom falls short.

Noom’s funnel is a masterclass in onboarding conversion — building commitment through personalization, education, and empathy. It’s long, but it never feels tedious — every step serves a clear purpose. By the end, you genuinely feel like this plan was built just for you, even while knowing some of it is smoke and mirrors. When 55% of trial cancellations happen on Day 0, Noom’s investment in pre-paywall commitment-building looks less like a quirk and more like a calculated response to that reality.For subscription apps, especially in sensitive categories like health, finance, or mental wellness, Noom’s approach offers valuable lessons in trial-to-paid conversion: how to ask for personal information thoughtfully, build trust, and convert users through education rather than pressure — making it a blueprint for any wellness app funnel.

The blended ARPU framework: how to measure hybrid monetization

Thu, 02 Apr 2026 12:31:04 GMT

Hybrid monetization may be a hot topic, but it’s not a passing fad. Today, utilizing multiple avenues for revenue is a survival tactic — a lever to counter AI-induced variable costs, increased UA pressure and rising competition from the new 14,000 subscription apps joining the market each month.

Yet according to the State of Subscription Apps 2026, only 10% of apps run true hybrid models (subscriptions + ads, consumable, or lifetime subscriptions). Why? Because there’s a barrier, not a technical one, but a measurement challenge. Without a unified metric, teams default to evaluating the performance of hybrid monetization in silos. In this blog, I’ll provide a solution to that exact problem.

The clash of ads vs. subscription mental models

Part of the difficulty in measuring hybrid monetization is the divided mental models between ad-first and subscription-first teams — and the subsequent division that comes with monitoring hybrid performance.

The mental model for ads-first teams is: more sessions = more impressions = more revenue.

So when subscriptions become a strategic priority, the first reaction is usually caution. Typical concerns sound like:

“If we push paywalls, impressions will drop”
“If users subscribe, we lose high-value ad traffic”
“Retention might fall if we add friction”
“We shouldn’t disturb what’s already working”

Teams panic when ads ARPU dips, even if total revenue per user is rising. There can be concern that introducing stronger monetization would:

Hurt retention
Trigger uninstall spikes
Reduce session depth

And because ads performance responds instantly while subscriptions compound, ads movement often shows up first in dashboards.

On the flip side, if you introduce ads into a subscription-heavy culture, you’ll often hear:

“Leaning into ads discourages higher-value subscriber growth”
“Ads revenue hides product problems”
“Free users aren’t our priority”
“Free users get too comfortable”
“The funnel isn’t pushing hard enough”

Tracking blended ARPU is one way to solve this. It becomes your primary subscription app KPI, while ads and subscriptions become supporting metrics. When you monitor total revenue per user instead of individual streams, you stop killing good subscription experiments because of short-term ads volatility.

Why do ads and IAP behave differently?

In hybrid monetization apps, advertising and in-app purchases operate on fundamentally different time horizons, yet this distinction is often overlooked in how teams measure and optimize revenue.

Advertising revenue responds immediately — users see ads, clicks generate income, and the impact shows up in your metrics within hours or days. Subscription revenue, on the other hand, compounds gradually over time as users renew month after month, building predictable recurring revenue that may take quarters to fully materialize.

When you evaluate these revenue streams separately, as some teams do, they naturally appear to compete with each other. You might see that showing more ads increases ad ARPU but seems to hurt subscription conversion, or that pushing subscriptions harder reduces ad impressions. This apparent tension is reinforced by how some analytics dashboards are structured: Ad ARPU lives in one report, IAP ARPU sits in another, and the two rarely interact.

This organizational split encourages teams to optimize locally — the ads team pushes for more impressions, the subscription team advocates for aggressive or contextual paywalls — rather than thinking globally about total user lifetime value.

In a recent monetization review across a large utility app portfolio, we made a deliberate shift in our approach: ads and IAP would no longer be evaluated as competing channels, but rather as one unified revenue system.

Making this shift required developing a shared metric that could capture the combined contribution of both streams and reflect their true interdependencies. This allowed us to move beyond the misleading choice between ad revenue and subscription revenue, and instead optimize for the mix that maximized total value per user.

What is blended ARPU?

When you’re running an app with hybrid monetization, you need a way to see the complete picture of how much revenue each user is generating on average. That’s where ‘blended ARPU’ comes in. ARPU (or average revenue per user) is one of the most fundamental metrics in the app business. The ‘blended’ part means we’re combining all your different revenue sources into one number, rather than looking at them separately.

The formula itself is straightforward:

Blended ARPU = ad ARPU × % free users + IAP ARPPU × % paid users.

Let’s break down what this means:

Ad ARPU is the average ad revenue you make per user (usually the free users who see ads)
You multiply that by the percentage of your user base that’s on the free tier
Then you take IAP ARPPU (the average revenue per paying user from subscriptions or purchases) and multiply it by the percentage of users who’ve paid for something

Add those two pieces together, and you get your blended ARPU: the true average revenue you’re making per active user across your entire app, regardless of whether they’re paying subscribers or ad-supported free users. This is the exact structure we use in our internal tracking spreadsheet to monitor monetization health across different apps.

What makes this metric so powerful is how it reframes the questions you ask. Instead of fragmenting your analysis by asking “Did ad revenue drop this month?” and separately “Did subscriptions increase?”, you can ask one unified question: “Did total revenue per active user increase?”. That shift in perspective changes everything about how you make decisions. It prevents you from accidentally optimizing one revenue stream at the expense of overall profitability, and it helps you see whether changes you’re making, like adjusting ad frequency or changing paywall triggers, are actually improving your business or just shifting money around between buckets.

How to implement a blended ARPU tracker

You can talk about unified monetization strategy all you want, but until you actually build it into your regular cadence of meetings and reviews, teams will default back to optimizing in silos. That’s why we introduced a biweekly blended ARPU tracker across our focus apps and committed to reviewing it consistently with product managers. The key word is ‘consistently’ — this isn’t a metric you check once a quarter when someone asks about it. It’s the framework for every monetization conversation, reviewed every two weeks.

Each app snapshot in our tracker includes a carefully-chosen set of metrics that tell the complete story:

We track monthly IAP revenue and monthly ad revenue separately so we can see the individual components
We calculate free user ARPU (how much ad revenue we’re generating from non-paying users) and subscriber ARPU (how much paying users contribute)
We include paid user percentage because the mix between free and paid users dramatically affects your blended number — an app with 5% paid users will look very different from one with 20% subscribers, even if both have similar total revenue
Then we calculate the blended ARPU itself using the formula we discussed
We also include D1 retention (the percentage of users who come back the day after installing) because monetization changes always need to be balanced against user experience and engagement
Finally, we track biweekly deltas (the change from the previous period) so we can immediately see if experiments or product changes are moving the needle in the right direction

What’s crucial about this structure is the hierarchy: blended ARPU is the primary KPI. Everything else is context. When we sit down for a review, we don’t start by debating whether ad revenue went up, or whether a new paywall performed well. We start with one question: did blended ARPU improve? Then we use all the other metrics to understand why it moved and what levers we can pull to improve it further.

For example, the tracker may look like this:

App	Active users	% Paid	Ads revenue	IAP revenue	Ad ARPU	Sub ARPPU	Blended ARPU	Key insight
App 1	8.3M	0.23%	$567k	$20k	$0.07	$2.82	$0.07	Sub share stabilizes blended ARPU despite install decline
App 2	5.4M	0.44%	$171k	$72k	$0.05	$3.29	$0.06	Higher sub penetration clearly lifts blended ARPU
App 3	2.3M	0.08%	$82.7k	$13.5k	$0.04	$7.71	$0.05	Even low penetration adds measurable lift

Even at low paid percentages, subscriber ARPPU is dramatically higher than ad ARPU. That means small increases in paid share can meaningfully shift total revenue per user. That insight alone reshaped prioritization across the portfolio.

Hybrid monetization framework: how to tell the difference between revenue cannibalization vs. false alarms

Once you’ve committed to blended ARPU as your north star metric, you need a clear system for monitoring it — not just tracking the number, but understanding when to react and when to stay the course. We formalized our monitoring system into three distinct layers that create a structured escalation process, preventing both overreaction to normal fluctuations and delayed response to genuine problems.

Primary KPI: blended ARPU

At the top sits the primary KPI: blended ARPU. This is what we care about most, the ultimate measure of whether our monetization is getting stronger or weaker. Beneath that, we track a set of monitoring metrics that help us diagnose what’s happening under the hood. These include:

Ads revenue per free user (are we monetizing our free tier effectively?)
Impressions per DAU or daily active user (are users seeing the right volume of ads?)
Retention metrics at key intervals: D1, D3, and D7

These monitoring metrics aren’t goals in themselves; they’re diagnostic tools that explain movements in blended ARPU and help us identify which specific lever might be broken or underperforming.

Escalation triggers

The third layer consists of escalation triggers: the conditions that prompt us to actually intervene or reverse a change. We escalate when:

Blended ARPU falls meaningfully and stays suppressed
Ad ARPU drops without a corresponding lift in subscription revenue to compensate for it
We see a sustained retention collapse that threatens the underlying health of the app

Sustained is important here — we expect volatility in app metrics, that’s the nature of the business, so minor dips in ad impressions from one week to the next are completely normal. Small retention fluctuations during funnel optimization experiments are par for the course. What matters is the trend, not the daily noise.

This discipline is what prevents us from making costly mistakes. When you run a subscription experiment that reduces ad impressions, e.g. by showing an earlier paywall, ad revenue will naturally dip in the short term. Teams that only monitor ad metrics in isolation will panic and roll back the change prematurely, never giving the subscription revenue time to compound and overtake the lost ad income. By anchoring to blended ARPU and only escalating when it remains meaningfully suppressed, we give experiments the runway they need to prove themselves while still catching genuinely harmful changes before they do lasting damage.

Revenue vs. ads calculator: how many subscribers do you need to offset ad revenue loss?

One of the biggest obstacles to unified monetization thinking is that the tradeoffs feel abstract and therefore scary. When you’re considering a change that might reduce ad impressions — like introducing a paywall earlier in the user journey or limiting interstitial frequency — the ad revenue loss is immediate and visible, while the subscription gain is hypothetical and delayed. This asymmetry paralyzes decision-making.

To make these tradeoffs tangible and give teams confidence to experiment, we built a simple calculator that answers one critical question: if ad revenue dips, how many new subscribers do we actually need to offset that loss?

The math is straightforward:

Subscriber ARPPU ÷ ad ARPU = the number of free users equivalent to one subscriber.

In other words, this tells you how many ad-supported users one paying subscriber is ‘worth’ in pure revenue terms.

Let’s walk through a real example from one of our apps: in this case, subscriber ARPPU is approximately $2.82 per month. Ad ARPU is about $0.07 per month. Divide $2.82 by $0.07, and you get ~40.

That means one subscriber generates the same monthly revenue as 40 free users watching ads. Put another way, if you convert just one user out of every 40 free users into a subscriber, you’ve maintained exactly the same revenue — while dramatically improving your monetization quality and reducing your dependence on ad networks.

Note that this ratio varies significantly across different apps depending on their monetization mix, subscription pricing, and ad density. In our portfolio, we’ve seen numbers ranging from as low as 60 free users per subscriber in apps with lighter ad loads and premium subscription tiers, all the way up to nearly 190 free users per subscriber in apps with aggressive ad monetization but lower-priced subscriptions.

Regardless of where your specific app falls, knowing this number transforms the conversation. When product managers see that converting a relatively small number of users — say, improving your paywall conversion rate by just 2–3% — can offset the loss of thousands of ad impressions, the fear of “losing ad revenue” to push subscriptions becomes manageable. The tradeoff is no longer a vague anxiety; it’s a quantifiable bet with clear success criteria. You know exactly what conversion rate you need to hit to break even, and anything above that is pure upside.

Let’s look at how this would look in practice:

1. Core exchange rate example

Here, there’s a subscriber vs. ads tradeoff:

Metric	Value	Explanation
Subscriber ARPPU	$2.82	Avg monthly revenue per subscriber
Ad ARPU (free users)	$0.07	Avg monthly ad revenue per free user
Free users per one subscriber	40.3	$2.82 ÷ $0.07

In this scenario, one subscriber generates the same revenue as ~40 free users. So if you convert one out of every 40 free users, revenue remains flat. Anything above that is incremental upside.

2. Breakeven scenario example

For this example, imagine ads dip but there’s subscriber lift:

Scenario variable	Value
Monthly active users	5,000,000
% Free users	99.7%
Ad ARPU	$0.07
Subscriber ARPPU	$2.82
Hypothetical ad ARPU drop	-$0.005

After this, the revenue impact would be:

Calculation step	Result
Revenue loss from ad ARPU drop	$24,925
Required new subscribers to break even	8,841
Formula used	$24,925 ÷ $2.82

For this scenario, if your experiment generates more than 8,841 additional subscribers, it is revenue-positive — even if ads ARPU dips slightly.

Blended ARPU benefit: revenue stability

One of the often-overlooked benefits of using blended ARPU as your primary metric is that it’s inherently more stable than looking at ad revenue or subscription revenue in isolation — and that stability is what allows you to make better decisions with more confidence.

Ads ARPU fluctuates wildly on a daily basis. Ad network fill rates change, eCPMs (effective cost per thousand impressions) vary based on advertiser demand and seasonality, and even small changes in user behavior — like slightly fewer sessions per day — can cause noticeable swings in ad revenue. If you’re monitoring ads ARPU closely, you’ll see it jump up and down constantly, which creates anxiety and makes it difficult to distinguish between meaningful trends and random noise.

Similarly, IAP ARPU fluctuates with the rhythm of your promotional calendar and trial cycles. When you run a discount campaign or offer a special trial period, you might see a short-term spike in conversions followed by a drop-off once the promotion ends. You’ll also see natural cycles tied to when trials convert to full subscriptions or when annual renewals come through. Each of these creates peaks and valleys that can look alarming if you’re only tracking subscription metrics.

Blended ARPU smooths those movements because it’s averaging across two revenue streams that often move in different directions or on different timescales:

When ad revenue dips slightly one week, subscription revenue might be steady or growing
When a promotion ends and new subscription sign-ups slow down, ad revenue from your stable free user base continues flowing

The result is a much clearer signal of your total monetization health — one that cuts through daily volatility and helps you see the actual trend. This doesn’t mean blended ARPU never moves or that you should ignore changes in it. Rather, it means that when blended ARPU does move significantly, you can have much higher confidence that something meaningful is happening, not just normal statistical noise. That clarity is what enables disciplined decision-making and prevents teams from overreacting to the everyday ups and downs that are simply part of running a hybrid monetization business.

The chart shows ads and IAP moving independently while blended ARPU remains comparatively stable. That stability allows teams to make rational long-term decisions.

Embracing blended ARPU

Ads and subscriptions do not have to compete with each other, cannibalizing revenue in an endless internal tug-of-war. They can and should work together as complementary parts of a single, coherent monetization strategy. The problem is that without a unified metric to measure their combined contribution, teams will inevitably optimize in silos — the ads team pushing for maximum impressions, the subscription team advocating for aggressive paywalls — each defending their own territory and reacting to short-term noise in their individual metrics rather than long-term trends in overall business health.

Blended ARPU gives you a stable lens through which to view total revenue health. It cuts through the confusion of competing dashboards and contradictory signals. It tells you, in one number, whether the changes you’re making are actually improving your business. And perhaps most importantly, it creates alignment across subscription app growth teams — everyone is now optimizing for the same thing, which means product decisions can be made faster and with more confidence.

The beauty of this approach is that it isn’t complicated. You don’t need sophisticated machine learning models or expensive analytics platforms. The formula fits in a single spreadsheet cell. What it requires instead is discipline: to review the metric consistently, to let experiments run their course instead of panicking at the first sign of volatility, and to escalate only when blended ARPU shows sustained weakness (rather than reacting to every minor fluctuation!). In hybrid monetization, discipline beats fear every time. Fear tells you to protect your existing ad revenue at all costs. Discipline tells you to measure holistically, experiment thoughtfully, and trust the data. That shift in mindset is what ultimately unlocks the full potential of a hybrid model, allowing you to serve both free and paying users well while maximizing the lifetime value of everyone who comes through your door.

Google Play’s billion-dollar billing leak: How to recover the subscribers you’re losing to payment failures

Thu, 02 Apr 2026 10:51:51 GMT

When a subscription cancels on Google Play, most developers assume the user decided to leave. The billing infrastructure is Google’s problem, right? You build the product, Google handles the payments. If a charge doesn’t go through, that’s between the user and their bank.

The data tells a very different story.

In our 2026 State of Subscription Apps report – covering 115,000+ apps and over $16 billion in tracked revenue – 32.3% of all Google Play cancellations are involuntary billing errors. Not users churning. Not users who decided your app isn’t worth it. Users whose credit card expired, whose prepaid balance ran out, or whose bank flagged a routine charge. They wanted to keep paying. They just couldn’t.

On the App Store, that number is 15.2%. Still significant, but less than half the Google Play rate.

As we put it in the report: “The primary platform difference is not unsubscribe behavior – it’s billing reliability.”

For a $1M ARR Android app, a 32% involuntary cancellation rate translates to north of $300K/year walking out the door. And unlike voluntary churn – which requires product changes, retention experiments, and long feedback loops – involuntary churn is a recoverable revenue stream with well-documented playbooks and near-immediate ROI.

This is probably the highest-return retention work most Android developers aren’t doing. We’ll walk through why the gap exists, what Google Play gives you to fix it, what you need to build yourself, and what recovery actually looks like.

Why Google Play leaks more than Apple

The 2x gap between Google Play and the App Store isn’t a quality problem on Google’s end. It’s structural – a consequence of how each platform’s users interact with payments.

As Jacob Eiting discussed on the Sub Club podcast episode covering the report: “The Apple platform is way more oriented around keeping your credit card up to date. Everything is Apple Pay. You’ve got your Apple subscription to keep your photo library in the cloud. It feels like as a platform, they do kind of more strongly incentivize you to keep your billing updated, keep money flowing through their systems.”

Google Play users, particularly in developing markets, often don’t have that same web of tied services. Their Play Store payment method can go stale for months before they notice. Google also allows prepaid cards and carrier billing in markets where balances frequently run dry – payment methods that Apple doesn’t support at the same scale. As Jacob put it: “Your balance runs out and then the billing fails. The physics are just very different.”

Our report’s retention data reinforces this pattern. Jeff Morris Jr., writing in the expert commentary section, notes that the challenge in emerging markets isn’t long-term retention of a good user – it’s “overcoming initial billing or usage friction.” By the 3rd renewal cycle, all geographies converge to within a few percentage points of each other. The users are there, the payment infrastructure just isn’t keeping up.

The underlying decline categories tell you everything about why this is recoverable. The vast majority of billing failures are “soft” declines – generic declines, insufficient funds, expired cards – that are temporary, situational, and recoverable with retries and a little nudging. By some industry estimates, roughly a quarter to a third of US payment cards are reissued annually, creating a constant background rate of stale credentials even among engaged, willing-to-pay subscribers.

The user didn’t leave, their card did.

The practical upshot: Android developers have both a bigger problem and more granular tools to fix it. The question is whether they’ve configured those tools.

The 60-minute fix: platform tools most developers haven’t touched

Here’s the thing that makes involuntary churn different from almost every other retention problem: the highest-impact interventions are configuration changes, not code. Google provides a 60-day total recovery window with built-in retry logic, payment update prompts, and user notifications. But the default settings leave significant recovery on the table.

If you do nothing else after reading this post, do what’s in this section.

Grace periods: keep the user subscribed while Google retries

Google structures its recovery window into two phases. The grace period keeps the user subscribed with full access while Google retries the payment. If recovery fails during that window, the account hold suspends access but continues retry attempts. As of Google’s December 2025 policy change, the total window is capped at 60 days, with the account hold duration auto-calculated as 60 minus whatever grace period you configure.

Grace periods are now enabled by default on all auto-renewing base plans and can be set for up to 30 days (expanded from earlier limits at Google I/O 2025). During this period, Google retries the charge, emails the user, and sends notifications prompting a payment update. Your app still returns the subscription as active via queryPurchasesAsync(), meaning apps that check entitlements through the standard API handle grace periods automatically with no code changes. If payment recovers during the grace period, the original billing date is preserved – the user never knows anything went wrong.

Google’s published data on the impact is hard to argue with: enabling grace periods delivers a 57% higher recovery rate from renewal declines.

Account holds: the second-chance window

Account holds kick in when the grace period expires. The user loses access, the subscription state shifts to SUBSCRIPTION_STATE_ON_HOLD, and queryPurchasesAsync() stops returning the subscription. This is important – you need to explicitly check for the on-hold state to show the right messaging in your app. Google continues retrying in the background for the remainder of the 60-day window. If the user fixes their payment during account hold, access resumes but the billing date resets to the recovery date.

Google reports that adding account hold on top of grace periods produces 35% higher payment decline recovery and 8% lower involuntary churn. In early cohort data, combining grace period and account hold tripled the decline recovery rate from roughly 10% to 33%.

The In-App Messaging API: two lines of code, 2x recovery

Now, the tool that almost nobody uses. The In-App Messaging API is a single call – BillingClient.showInAppMessages() with InAppMessageCategoryId.TRANSACTIONAL – that displays a Google-rendered snackbar when a user in grace period or account hold opens your app. It shows once per day, includes a direct link to fix payment on Google Play, and requires no custom UI work on your end.

Google’s data shows this produces a 2x increase in user recovery and growth in overall subscriber spend. Two lines of code. Call it on every app launch. If you implement one thing from this post, make it this.

If you’re using RevenueCat, this is already handled – the SDK shows Google Play’s In-App Messages automatically starting in v7. No additional code needed. You can disable it via .showInAppMessagesAutomatically(false) if you want to manage it yourself, but for most apps, the default behavior is exactly what you want.

What about Apple?

The App Store’s involuntary churn rate is less than half of Google Play’s, and more of the recovery happens automatically – billing retry is always on for all auto-renewable subscriptions, and since iOS 16.4, Apple shows a Billing Problem Message to users without any API call on your end. The one thing you should actively opt into is the Billing Grace Period in App Store Connect – set it to 28 days. Apple’s own data shows 90% of billing issues resolve within that window. That’s it for iOS. The rest of this post focuses on Google Play, where the problem is bigger and the developer toolkit is more hands-on.

The Google Play configuration checklist

The total time investment here is about an hour: verify grace periods are enabled and set to the maximum appropriate duration for each base plan (up to 30 days), confirm account hold is set to auto-calculated for a full 60-day window, and add the In-App Messaging API call to your app launch flow.

That’s it. You’ve just recovered a meaningful chunk of your involuntary churn.

If you’re using RevenueCat, grace period and account hold states configured in the Play Console are detected automatically – subscriptions in a grace period remain “active” in your entitlement checks, and a BILLING_ISSUE event fires to your webhooks and connected integrations the moment a payment fails. The Subscription Status chart in the dashboard also surfaces a dedicated “Billing Issue” status, so you can see at a glance what percentage of your active MRR is currently at risk from payment failures. It’s a useful gut check after you’ve made configuration changes – you can watch the billing issue cohort shrink in real time.

Subscription Status chart in RevenueCat

But platform-level tools are a floor, not a ceiling.

The full dunning stack: push, email, and deep links

Once you’ve configured the platform defaults, the next layer of recovery comes from developer-side dunning – the industry term for communicating with users about failed payments and prompting them to fix it. This is where you move from “configuration” to “engineering investment,” but the ROI remains strong.

Push notifications and in-app messaging

The timing cadence matters more than the copy. Fire the first push notification on Day 0 when the decline is detected via Google’s Real-Time Developer Notifications (RTDN). Follow up on Days 1–3, then Day 7, then Day 14. After that, diminishing returns set in.

Keep the tone helpful, not alarming. “We’re having trouble renewing your subscription – tap to update your payment method” works better than anything that sounds like a warning siren. The user didn’t do anything wrong; their card did.

Calibrate your in-app messaging to the subscription state. During the grace period, the user still has access – a non-blocking banner or snackbar is appropriate. During account hold, escalate to a more prominent modal explaining that access is suspended, with a clear call-to-action.

Google’s In-App Messaging API already handles a once-daily in-app prompt during grace period and account hold, so your developer-side push notifications serve as a complementary channel – catching users who haven’t opened the app.

To trigger all of this, you need Real-Time Developer Notifications set up via Google Cloud Pub/Sub. The billing-related notification types to handle are SUBSCRIPTION_IN_GRACE_PERIOD (type 6), SUBSCRIPTION_ON_HOLD (type 5), SUBSCRIPTION_RECOVERED (type 1), and SUBSCRIPTION_EXPIRED (type 13). After receiving any RTDN, call purchases.subscriptionsv2.get to fetch the full subscription state – RTDNs signal that something changed but don’t carry complete details.

If you’re using RevenueCat, this plumbing is already done for you. The BILLING_ISSUE event fires automatically to your connected integrations – Braze, OneSignal, Iterable, Customer.io, and others – so you can trigger dunning campaigns directly from the tools you’re already using without building your own RTDN processing pipeline. The event includes grace_period_expiration_at, giving your campaigns the exact deadline to work with.

Deep linking to payment settings

Every extra tap between your dunning message and the payment update screen costs you recovered subscribers. The best recovery flows route users directly to the right screen with a single tap.

On Android, link to: https://play.google.com/store/account/subscriptions?package={packageName}&sku={skuId} – this takes users directly to their specific subscription on Google Play.

On iOS (for your cross-platform setup), use AppStore.showManageSubscriptions(in:) in StoreKit 2 (iOS 15+) to display the subscription management sheet without leaving your app.

If you’re using RevenueCat, the managementURL property on CustomerInfo returns the correct platform-specific URL automatically. This means your in-app billing error UI can include a one-tap “Fix payment” button that works across both stores without hardcoding store-specific URLs or maintaining platform branching logic.

Email dunning sequences

Email catches users who aren’t opening your app or aren’t seeing push notifications. A 3–5 message sequence over 14–28 days works well, shifting from friendly notification (“Heads up – we couldn’t process your payment”) to urgency (“Your subscription is at risk”) to final warning (“Last chance to keep your subscription”). Personalize with the user’s name and the specific features they’ll lose access to. Make the call-to-action button prominent and link directly to payment update.

One nuance worth flagging: pre-dunning emails that warn about upcoming card expirations – sent before a failure happens – sound good in theory but can backfire in practice. They can prompt users to reconsider whether they want the subscription at all, especially if the app isn’t top-of-mind. For active users, in-app prompts about expiring cards tend to be safer than email.

Recovery benchmarks: what to expect

Recovery rates vary based on how many of these tools you actually activate. Here’s what Google’s published data suggests, supplemented by their developer case studies:

Platform defaults only (no grace period optimization, no developer intervention): roughly 10–15% recovery of failed payments. This is where most apps sit today.
Optimized grace periods + account holds + In-App Messaging API (about an hour of configuration): roughly 30–35% recovery on Google Play. Google’s published data shows the combined effect of grace period and account hold triples recovery from the baseline. The In-App Messaging API doubles user recovery on top of that.
Full dunning stack (push notifications + email sequences + deep links on top of the platform tools): the incremental gains from each channel compound. In Google’s published Truecaller case study, implementing RTDN-triggered messaging alongside grace periods and account hold recovered 40% of at-risk subscribers – up from 15% before the changes.

Now consider what a recovered subscriber is actually worth. Our 2026 State of Subscription Apps data shows that a subscriber who survives their 1st monthly renewal has a 73–82% chance of making it to their 3rd. Every billing failure you recover in cycle 1 is a subscriber who gets the chance to become one of those high-retention renewals. Conversely, our reactivation data shows that once a monthly subscriber actually churns, only about 20% come back within a year – and for annual subscribers, it’s a dismal 5%. Preventing the loss is dramatically more valuable than winning the user back later.

Whichever tier you’re operating at, make sure you’re measuring the impact. Track your billing error cancellation rate by platform (RevenueCat’s Subscription Retention chart excludes unresolved grace period transactions, so your retention numbers reflect actual recovered subscribers). Compare cohorts before and after you extend grace periods. The feedback loop here is fast – you should see movement within a single billing cycle.

Fix billing before you buy more users

Involuntary churn is one of those rare problems where the diagnosis is clear, the tools already exist, and the returns are immediate. The instinct to treat billing failures as the platform’s problem is understandable – but the data is unambiguous. A third of your Google Play cancellations are subscribers who wanted to keep paying.

The highest-impact work is configuration, not code. Extend your grace periods. Enable account hold. Add Google’s In-App Messaging API. That’s an afternoon of work that recovers real revenue starting the next billing cycle.

Fix billing before you buy more users.

“Money will come” – How Super Unlimited built the #1 VPN by not optimizing for revenue

Wed, 01 Apr 2026 12:56:35 GMT

Tanuj Chatterjee is the CEO of Super Unlimited VPN — the #1 VPN app in the world by downloads, with over a billion installs and more than a million new downloads every day, almost entirely organic. In a conversation with David Barnard and RevenueCat CEO Jacob Eiting, he breaks down the product-driven growth loop that got them there, the deliberate decision to leave money on the table, and what five years of A/B testing has taught him about the gap between what looks good and what actually converts.

The screenshot redesign that kept losing

Super Unlimited’s App Store screenshots are, by Tanuj’s own admission, a little stale. The team has spent years trying to fix that. They’ve tested modern layouts, updated colors, new content arrangements, and contemporary design trends. The results have been consistent: 80% of the time, the new version loses.

“People just like to see what they were used to seeing,” Tanuj says. “In many cases, we have gone back to the original ones that we had.”

The finding cuts against one of the most common instincts in app growth: that better design means better conversion. For an app sitting at the top of App Store search, the risk of a major visual overhaul is asymmetric. Disrupting a proven asset is more dangerous than the upside of a marginal lift. The team still tests — methodically, one variable at a time — but they’ve learned to treat the data as the authority, not their aesthetic judgment.

Why a low conversion rate is part of the strategy

Super Unlimited’s free-to-paid conversion rate is, by most subscription app standards, quite low. Tanuj is fine with it.

“Our free version is that good,” he says. “You don’t want to throttle or take things away from the free version. There’s a reason we have the word unlimited in our name.”

Free users can access dozens of countries and cities, watch a couple of ads, and use the VPN without restrictions. The paywall exists — premium subscribers get no ads, top-tier servers, multi-platform access, and priority support — but it’s designed to be easy to dismiss. There’s a large X in the corner. No dark patterns.

The logic is a numbers game. Super Unlimited’s LTV is modest compared to a Spotify or a Netflix. But their top of funnel is enormous, and it’s almost entirely organic. The free experience generates the ratings volume and return-visit signals that feed the App Store algorithm, which keeps the downloads coming. “Our top of the funnel is our superpower,” Tanuj says. “Don’t mess with it.”

The countries where they lose money on purpose

Super Unlimited serves users in countries where the economics don’t work. Turkey, Myanmar, and other markets with low CPMs, high infrastructure costs, or active internet censorship are not profitable. The team knows this and serves them anyway.

When Turkey banned Instagram for 11 days last year, Super Unlimited received 15 million downloads in four days — roughly 30-40% of Turkey’s internet population. The revenue from those users didn’t cover the cost of serving them.

“We just think it’s the right thing to do,” Tanuj says. “People should have access to information. They should not be constrained by just propaganda.”

This isn’t purely altruistic. The geopolitical spikes that come with being a global VPN have a compounding effect: each spike drives the app to a new normal at a higher baseline once the event passes. But the decision to serve loss-making markets is a deliberate one, made on values grounds, not just financial ones.

What happened when support moved into the product team

At most companies, customer support is a separate organization. It presents KPIs to the product team once a month. The feedback loop between user pain and product fix takes weeks.

At Super Unlimited, the head of support reports directly to the head of product.

“I have been at companies where product and support was a totally separate organization,” Tanuj says. “The pace at which the feedback loop goes into the product side is a lot less.”

When a spike in support tickets from Uganda signals a service quality issue, the product team knows the same day — not next month. A recurring question about a feature becomes a UX fix in the next sprint, not a FAQ entry. For an app where service quality is the primary competitive advantage, the speed of that loop is the speed of improvement.

The episode also covers how Super Unlimited thinks about paid search when you’re already the #1 organic result, why they’re betting on Windows as their next growth vector, and the infrastructure decision — bare metal servers for the data plane, cloud for surge capacity — that makes their unit economics work at scale.

Guest links:

Tanuj Chatterjee on LinkedIn
Super Unlimited VPN
Hiring in Asia and Europe: jobs@superunlimited.com

Kotlin Coroutine bridges: converting any callback-based Android API to suspend functions

Tue, 31 Mar 2026 23:26:22 GMT

Most Android platform APIs and third party SDKs were designed around callbacks. The Google Play Billing Library uses PurchasesUpdatedListener. Location Services uses LocationCallback. Bluetooth GATT uses BluetoothGattCallback. Camera2 uses CameraCaptureSession.StateCallback. If you have been writing Android code for more than a few months, you have written deeply nested callback chains that are hard to read, hard to test, and hard to reason about when errors occur at any stage. Kotlin coroutines solve this with suspend functions, but the platform and most SDKs do not hand you suspend functions out of the box. You need a bridge.

In this article, you’ll explore the suspend coroutine bridge pattern in detail, tracing how it converts callback based APIs into clean suspend functions, how to handle different callback shapes from single value results to multi parameter success and error pairs, how to design exception hierarchies that preserve error semantics across the bridge, why you should always reach for suspendCancellableCoroutine rather than the older suspendCoroutine — even when the underlying callback API has no native cancellation — and how production SDKs like RevenueCat apply these patterns at scale across 20+ API surfaces.

The fundamental problem: Callbacks do not compose

Consider a common billing flow on Android. You need to connect to the billing service, query products, then initiate a purchase. With the raw callback API, this looks like:

Each callback nests inside the previous one. Error handling is scattered across if checks and separate override methods. There is no structured way to propagate failures up the chain. And this is only two callbacks deep. A full billing flow, connecting, querying, purchasing, acknowledging, involves four or five nested levels.

The suspend function equivalent reads like sequential code:

This is not a language feature you get for free. Each of those await functions requires a bridge that converts the underlying callback into a coroutine suspension point. Let’s trace through exactly how that bridge works.

The core bridge: `The core bridge: suspendCancellableCoroutine`

Kotlin provides two primitives for bridging between callback based code and coroutines: suspendCoroutine and suspendCancellableCoroutine. They look almost identical — both suspend the current coroutine and hand you a continuation that you later resume with a result or resumeWithException with an error — but only one of them is safe to use in real code: suspendCancellableCoroutine.

The plain rule, stated up front: do not use suspendCoroutine in application or library code. Its continuation is not tied to coroutine cancellation, so when a parent Job is cancelled the leaf cannot tear down. The coroutine stays parked, holding references to its scope and context, until (or unless) the callback eventually fires. That is a structured concurrency hole and, in practice, a latent memory and resource leak.

Worse, cancellation and exceptions further up the tree can’t propagate past a coroutine that refuses to finish, which is how a single stuck bridge wedges a whole screen’s scope. suspendCancellableCoroutine closes the hole by giving you a CancellableContinuation that participates in cancellation, even when the underlying callback based API has no cancellation support of its own. Every example in this article uses it.

The simplest bridge handles a single value callback:

The pattern has three parts. First, call suspendCancellableCoroutine to pause the coroutine and receive a CancellableContinuation. Second, call the callback based API, passing an anonymous implementation that captures the continuation. Third, inside the callback, call resume or resumeWithException to deliver the result and unfreeze the coroutine. When the underlying API supports teardown, register a cleanup block through invokeOnCancellation so cancellation actually releases the resource instead of waiting on a callback that may never come back.

One important rule: you must call resume or resumeWithException at most once per non cancelled continuation. Calling it zero times means the coroutine hangs forever (unless cancelled from outside). Calling it twice on a live continuation throws IllegalStateException. After cancellation, CancellableContinuation.resume simply drops the value, so you do not need to guard every resume with an isActive check — but every non-cancelled code path through your callback must reach exactly one resume call.

Success and error callbacks: The two-path bridge

Most SDK APIs split their callbacks into success and error paths. This maps naturally to resume and resumeWithException. Let’s examine how RevenueCat’s Android SDK bridges its offerings API.

Looking at the awaitOfferings extension function:

Notice the structure. The onSuccess path uses a method reference continuation::resume directly. When the callback signature matches (T) -> Unit and the continuation expects T, a method reference is the cleanest form. The onError path wraps the raw PurchasesError in a PurchasesException before passing it to resumeWithException. This is necessary because resumeWithException expects a Throwable, but the SDK’s error type is a plain data object, not an exception.

The @JvmSynthetic annotation prevents this extension function from appearing in Java code, since Java callers should use the callback version. The @Throws annotation generates the throws clause in the bytecode so Java interop and documentation tools correctly report what this function can throw.

The callback factory: Abstracting interface boilerplate

Before the suspend bridge can work, there is another layer of bridging. Many Android SDK APIs accept typed callback interfaces, not lambda pairs. For example, Google Play Billing uses PurchaseCallback with onCompleted and onError methods. RevenueCat’s internal API uses ReceiveOfferingsCallback with onReceived and onError.

Writing anonymous implementations of these interfaces inside every suspend function creates noise. The solution is a set of factory functions that convert lambda pairs into typed callback objects.

Looking at the callback factory for offerings:

This is a small function, but it matters at scale. RevenueCat’s SDK has factory functions for offerings, customer info, store products, purchases, login, sync, and more. Each one converts the (onSuccess, onError) lambda pair into the specific callback interface the underlying API expects.

The purchase callback factory handles a more complex shape:

Notice the asymmetry. The success callback delivers two values: the transaction and the updated customer info. The error callback also delivers two values: the error and a boolean indicating whether the user cancelled. This is not a simple (T) -> Unit shape. Bridging this to a suspend function requires additional design decisions.

Multi-value callbacks: Wrapper classes

When a callback delivers multiple values, you need a container to return them from a single suspend function. The approach is straightforward: define a data class that bundles the values.

Looking at RevenueCat’s PurchaseResult:

The suspend bridge then constructs this wrapper in the success path:

Two things are worth noting here. First, the success path wraps both values into a PurchaseResult so the caller gets a single typed return value. Second, the error path uses PurchasesTransactionException instead of the regular PurchasesException. This is because the error callback carries an extra userCancelled boolean that callers need to distinguish user initiated cancellation from actual errors. The exception hierarchy preserves this information.

Exception hierarchies: Preserving error semantics

A common mistake when bridging callbacks to coroutines is losing error information. Wrapping every error in a generic Exception(message) throws away the structured error code that callers need for programmatic error handling.

Looking at RevenueCat’s exception design:

The exception wraps the original PurchasesError object, preserving the typed PurchasesErrorCode enum. Callers can use a when expression on the code to handle specific error conditions:

The transaction exception extends this with the cancellation flag:

This hierarchy means callers can catch PurchasesException for all errors, or catch PurchasesTransactionException specifically for purchase errors where they need to check whether the user cancelled. The is check works naturally:

The key observation: the exception hierarchy mirrors the callback signature shapes. A callback with (error) maps to PurchasesException. A callback with (error, userCancelled) maps to PurchasesTransactionException. This is not accidental. It is a deliberate design that makes the suspend API as expressive as the callback API.

The `Result<T>` variant: Exceptions are not always what you want

Not every caller wants to use try/catch. Some prefer kotlin.Result<T> for composable error handling. RevenueCat provides a second variant for every suspend bridge:

The key difference: the error path calls continuation.resume(Result.failure(...)) instead of continuation.resumeWithException(...). From the coroutine’s perspective, the function always completes successfully. It returns a Result that the caller unwraps:

This pattern is useful in pipelines where you want to chain operations without try/catch blocks:

The purchase Result variant follows the same pattern:

The error information is not lost. The PurchasesTransactionException is still inside the Result.failure, so callers who need the userCancelled flag can check it:

This dual API approach, throwing suspend functions and Result returning suspend functions, gives consumers the choice without forcing one style. The SDK does not pick winners. It supports both.

The lambda convenience layer: Bridging before the bridge

There is a middle layer between the raw callback interface API and the suspend bridge that is worth examining. RevenueCat provides extension functions that accept lambda pairs instead of typed callback objects:

This is a two step bridge design. The lambda extension (getOfferingsWith) converts lambdas to a typed callback. The suspend extension (awaitOfferings) converts the lambda extension to a coroutine. Each layer does one thing.

Notice the default error handler:

internal val ON_ERROR_STUB: (error: PurchasesError) -> Unit = {}

This allows callers who do not care about errors to omit the error handler. This is useful for fire and forget operations, but should be used carefully since silently swallowing errors is a common source of bugs.

The purchase version has its own stub:

internal val ON_PURCHASE_ERROR_STUB: (error: PurchasesError, userCancelled: Boolean) -> Unit =
    { _, _ -> }

Two separate stubs for two different callback shapes. Each matches the exact lambda signature its callback requires.

Real-world application: Bridging Google Play Billing directly

The same suspendCancellableCoroutine pattern applies to any callback based Android API. Here is how you would bridge Google Play Billing’s acknowledgment API:

And the consume API follows the same structure:

Even the billing client connection, which has two separate callback methods (onBillingSetupFinished and onBillingServiceDisconnected), bridges cleanly:

The onBillingServiceDisconnected method is called after a successful setup when the connection is later lost, not as an alternative to onBillingSetupFinished during the initial connection. This is an important subtlety. If both methods could fire during setup, you would need additional state tracking to ensure exactly one resume call.

Why `suspendCancellableCoroutine` is always the right default

The earlier rule — “do not use suspendCoroutine in application or library code” — deserves its own section, because it’s easy to look at the two function names and assume they are equally valid tools for different jobs. They are not. suspendCoroutine is a low level primitive whose semantics predate the structured concurrency model we actually build on today, and its behavior is fundamentally incompatible with cancellation.

Here is what actually happens when you call suspendCoroutine inside a cancellable scope. The continuation you receive is a plain Continuation<T>. It has no knowledge of the Job that invoked it. When the parent Job is cancelled — because a ViewModel is cleared, a LaunchedEffect leaves composition, a coroutineScope { } block throws, or the user navigates away — the cancellation signal travels to every child that participates in structured concurrency. Your suspendCoroutine leaf does not participate. It cannot be cancelled, so Job.cancelAndJoin() cannot complete, sibling failures cannot propagate past it, and the entire scope is held open waiting for a callback that may never fire.

The practical consequences are the ones you would expect from a leak:

The continuation retains the calling coroutine’s context, including references to lifecycle-scoped objects like ViewModels, Activitys, or Composers. Those objects can no longer be garbage collected.
Any resource registered in the surrounding scope — a database session, a Bluetooth GATT handle, an open socket — stays alive until the callback eventually comes back.
Exceptions in sibling coroutines cannot be delivered in a timely way; the scope can’t finish cancelling its other children while the leaf is stuck, so failures silently disappear or surface seconds (or hours) later, detached from their cause.

suspendCancellableCoroutine is the fix, and it is the fix even when the underlying callback based API has no native cancellation to hook into. Its continuation participates in the coroutine’s Job graph: cancellation of the parent immediately resumes the continuation with a CancellationException, the leaf tears down, the scope unwinds, and references are released. The underlying callback can still fire later — you just ignore it, because CancellableContinuation.resume on an already-cancelled continuation is a safe no-op. The in-flight network request or SDK call keeps running to completion on its own, but it no longer holds your coroutine hostage.

The upgrade from suspendCoroutine to suspendCancellableCoroutine is almost always free. For callbacks you have no control over, the change is a single-word rename:

For callbacks whose underlying operation can be cancelled or whose resources should be released eagerly, add invokeOnCancellation for cleanup:

That’s it. You get correctness at no complexity cost. There is no category of “short lived, non cancellable” callback where suspendCoroutine is the pragmatic choice — short lived operations still need to honor cancellation, because the thing that is actually short lived is only short lived on average. Network calls stall. App processes freeze mid request. An SDK callback that “always fires quickly” has a long tail of cases where it doesn’t, and those are exactly the cases where a leaked scope matters most.

Treat suspendCoroutine as a platform primitive that exists mainly so that suspendCancellableCoroutine can be built on top of it. In the code you write, always reach for suspendCancellableCoroutine.

Applying the pattern beyond billing

The bridge pattern is not limited to billing APIs. The same approach works for any callback based Android API. A few examples:

For FusedLocationProviderClient, which delivers location through LocationCallback:

The Google Tasks API doesn’t expose a cancellation hook on lastLocation, but the bridge still uses suspendCancellableCoroutine: when the caller’s scope is cancelled, the continuation tears down immediately and the in-flight Task is left to complete on its own — its eventual callback simply finds an already-cancelled continuation and is a no-op.

For SharedPreferences, which uses OnSharedPreferenceChangeListener for change notifications:

The common structure is always the same: wrap with suspendCancellableCoroutine, register the callback, resume when the callback fires. What changes is the callback shape, how many values you need to capture, and whether cancellation cleanup is needed.

Common mistakes to avoid

Resuming zero times

If there is a code path where the callback never fires, the coroutine suspends forever. This is especially common with connection listeners that have multiple callback methods:

Using suspendCancellableCoroutine here means a parent-scope cancellation can still tear the coroutine down, but if no cancellation arrives the bridge is still wedged forever waiting on a callback that never came. The right primitive doesn’t save you from a missing resume path.

The fix is to ensure every callback path reaches a resume call, or use suspendCancellableCoroutine with a timeout:

Resuming twice

If a callback can fire multiple times (like a location listener that delivers updates continuously), the suspend bridge is the wrong tool entirely. Each call to resume after the first throws IllegalStateException, regardless of whether you used suspendCoroutine or suspendCancellableCoroutine. For repeating callbacks, use callbackFlow instead:

suspendCancellableCoroutine is for one shot callbacks. callbackFlow is for streaming callbacks. Choosing the wrong primitive leads to crashes or hangs.

Losing error type information

Wrapping all errors as Exception(error.message) strips away the structured error data callers need:

The extra work of defining a typed exception class pays for itself every time a caller needs to handle specific error conditions differently.

Conclusion

In this article, you’ve explored the suspendCancellableCoroutine bridge pattern from its simplest form, a single value callback, through the production patterns used in RevenueCat’s Android SDK: multi value wrapper classes, typed exception hierarchies, callback factory functions, and dual API styles with both throwing and Result returning variants. The pattern is always the same three steps: suspend the coroutine, register the callback, and resume exactly once. And it always uses suspendCancellableCoroutine, never the older suspendCoroutine, so every leaf in your coroutine tree honors structured concurrency.

Understanding this bridge is practical knowledge for any Android developer. Most of the platform APIs you use daily, billing, location, Bluetooth, camera, were designed around callbacks. Converting them to suspend functions makes your code sequential, testable, and composable. The patterns covered here, especially the callback factory layer, the typed exception hierarchy, and the Result<T> variant, are directly reusable in your own projects.

Whether you’re bridging Google Play Billing’s PurchasesUpdatedListener, wrapping a legacy networking library, or building a suspend friendly API for your own SDK, these patterns provide the foundation for clean, correct coroutine integration on Android.

As always, happy coding!

— Jaewoong (skydoves)

AI features are eroding your subscription app’s margins — here’s how to fix it

Thu, 26 Mar 2026 13:16:10 GMT

Right now, many subscription apps are adding AI features as quickly as possible. And it’s working — the product demo looks impressive, engagement spikes, the feature quickly becomes central to the app and user experience. But something else starts happening underneath the surface. With every generation, every prompt, and every “generate again” button click, the cost of serving your users is quietly (but rapidly) increasing.

Working with several AI-powered subscription apps recently, I started noticing this pattern. The very behavior you are trying to encourage — more usage, more exploration, more interaction — can now compress your margins if monetization and infrastructure are not designed in tandem.

AI is not just another product feature. It is infrastructure. So if you’re not modeling AI usage against ARPU, churn, and LTV before you ship it, you may be increasing engagement while quietly destroying your economics.

User engagement isn’t free anymore

Subscription businesses are structurally efficient. Or they used to be. Once you’ve built the core product experience, the marginal cost of serving an additional subscriber inside the app is typically close to zero, and the economics compound as you scale. (Thomas Petit talks about this in his blog on why hybrid monetization should now be the default for subscription apps.)

AI, on the other hand, disrupts that elegance. By introducing AI-powered features, you introduce variable cost at the feature level. Every time a user triggers an AI interaction, tokens are consumed, inference endpoints are called, and a third-party provider bills you for compute (the hardware resources used to make AI models work).

In short, your cost structure becomes inextricably linked to usage.

This creates a subtle but important tension — the same engagement you’ve worked so hard to increase now drives incremental cost. Higher engagement increases AI calls → more AI calls increase infrastructure spend. And unless revenue expands proportionally, your gross margin begins to shrink.

5 Ways to reduce AI spend in your app

So what does this mean? AI features are inherently a margin shrinker? No, not quite. AI means subscription businesses need to think more like cloud infrastructure businesses. Meaning usage is no longer just a growth metric, but also a cost driver.

1. Apps should buy AI infrastructure, rather than build it

I recently spoke with a portfolio Ops Manager working across several AI products and they described a familiar problem — the music generation API powering one of their apps became unstable, and suddenly even paying users couldn’t access the core feature. Complaints rose, reviews worsened, and monetization performance became harder to interpret.

This is what makes AI different from traditional app features. The question isn’t just whether users want the feature, it’s whether your infrastructure can deliver it reliably enough to support retention and revenue (without breaking your economics).

This is why I’d generally encourage thinking carefully about the infrastructure you choose. Training large datasets or creating your own models can make sense if you’re running a large-scale AI platform, but most subscription apps are far better served by using third-party APIs (e.g. Open AI’s ChatGPT, Google’s Gemini, Anthropic’s Claude) — particularly if you’re still experimenting with monetization and feature or product-market fit.

Running your own models introduces a number of challenges:

GPU overhead
DevOps complexity
Model maintenance risk
Fixed monthly burn (regardless of usage)

It’s a dangerous position to be in. So for many growth-stage subscription apps, using API-based foundation models makes more sense:

Paying per token converts AI into a variable cost that scales with actual usage
If a feature fails to move install-to-paid conversion, trial starts, ARPU, or retention, you can shut it down and your cost disappears with it

TL;DR: Variable cost preserves strategic agility. Fixed infrastructure locks you into experiments that may not justify themselves.

2. Treat AI usage like paid media spend

Subscription teams are usually obsessive about acquisition cost. They track CAC, payback periods, and ROAS down to the decimal. But many of the same teams treat AI usage casually, even though AI tokens are just another form of spend.

Every time a user triggers an AI feature, you pay for it. The longer the prompt, the longer the response, and the more often users hit ‘regenerate’, the higher your cost becomes. Think of it the same way you think about paid ads: every impression costs money, every click costs money. AI works the same way — every request has a price.

One AI team I spoke with saw this effect immediately when they changed their credit system. They moved from a restrictive daily allowance to a flexible monthly pool. Generation volume increased overnight. Some users burned through a large portion of their credits on the first day. The feature hadn’t changed, the usage constraints had. And with AI products, usage constraints directly affect infrastructure cost.

Smart teams design AI features with cost in mind. They limit how long responses can be, and avoid unnecessary explanations from the model unless the user actually needs them. Small decisions here matter more than you think. For example, asking an AI model to write a 600-word explanation is far more expensive than asking it to return a structured, 30-word answer.

At scale, those choices can significantly reduce AI costs. Across millions of requests, that is not a small optimization. It is a meaningful gross margin lever.

3. Use the cheapest AI model that gets the job done

Another common cost leak is sending every AI request to the most powerful model available. It feels safe. Teams assume the best model will produce the best experience. But in many cases, it just produces the highest bill.

Not every task requires a powerful model. Many AI features are doing relatively simple work; things like tagging content, formatting text, summarizing information, or generating short outputs. Smaller, cheaper models can handle these tasks perfectly well and deliver the same user satisfaction. Users won’t be able to tell the difference between a premium and mid-tier model, but your infrastructure bill will definitely show it.

Reserve expensive models for complex work that genuinely requires deeper reasoning, and use cheaper models for everything else. Choosing the right model for each task is one of the highest-leverage cost optimizations available to AI-powered apps.

4. Reuse AI results instead of regenerating them

User behavior is more repetitive than most teams expect. Especially in productivity and utility apps, users tend to ask for the same kinds of things again and again. Similar prompts, similar transformations, similar workflows. If your app generates a brand new AI response every time, you may be paying repeatedly for answers that have already been generated. Similarly, users may ask something then come back another time and ask again, rather than scrolling back to find the original conversation.

These are prime times to reuse results whenever possible: save common outputs, store reusable templates, and pre-generate responses for frequent requests so they can be served instantly instead of regenerated. Even small improvements here can have a big impact. If you can reuse results for just 20% of requests, your AI costs can drop significantly.

5. Gate AI features behind monetization

We’re already seeing a pattern of apps limiting AI usage in their free tier and gating advanced capabilities behind subscription plans — typically spread across pricing tiers to reflect compute cost, as well. Changes like this are not shocking to users, but can make a big financial impact to you.

Some apps even implement daily or monthly usage caps to prevent a small group of heavy users from driving disproportionate infrastructure cost. Consider a heavy AI user that costs you $0.15 per month, but later purchases an annual plan that generates $29.99; the economics are comfortable. But if that same user never converts and continues consuming AI indefinitely, the economics quietly deteriorate.

One team I spoke with introduced a quota system in their AI-powered learning product. New users received an initial credit allowance, with additional usage unlocked through paid packages. Models like this understand that usage and cost are relative.

Another AI app team I worked with chose not to offer a traditional free trial, since trial users were able to generate large volumes of output, consume API cost, then churn before ever paying. Instead, the team tested a one-time credit allowance that let users evaluate the quality of the product without exposing the business to unlimited inference cost.

The real risk with free AI credits is not simply that users use them. It’s that they use them before the product is good enough to make them convert. In that case, you’re funding churn, not activation.

This is what makes AI monetization for subscription apps fundamentally different from traditional subscription packaging — you’re not just pricing access to value. Every change made to monetization or pricing and packaging affects a wider infrastructure economy. Usage and retention analysis are invaluable; work to understand who uses what, how often, and why, then revisit your P&P and compute costs hand-in-hand.

The unit economics of AI

The whole conversation around AI’s hidden cost is difficult to quantify, though it’s easier if you already have your own AI features or app running, so let’s anchor it in familiar subscription metrics.

Assume you have a subscription app with these stats:

Monthly ARPU: $6.00
Normalized annual ARPU: $4.20
Blended ARPU across the user base: $5.10
Monthly churn: 5%
Gross margin (before AI): 85%

You then introduce an AI feature. The average AI-active user makes 10 requests per month, each consuming 1,000 tokens. Each token costs you $0.002, making the cost per active AI user (and 1,000 tokens) $0.02.

With 300,000 MAU and 15 percent AI engagement, you have 45,000 AI-active users. That results in a monthly AI cost of $900, or $10,800 annually. That is manageable.

Now imagine usage increases and routing shifts toward more expensive models. Cost per active AI user rises to $0.10 per month. With the same 45,000 AI-active users, monthly cost becomes $4,500, or $54,000 annually.

Whether or not that sounds like a lot depends on many factors. But ultimately, it depends on whether the AI feature increases LTV more than it increases cost per user. In other words…

Is the AI feature worth the cost?

Suppose install-to-paid conversion is 4% across one million annual installs, producing 40,000 paying users. With an average LTV of $42, baseline annual subscription revenue is $1.68 million.

If the AI feature increases install-to-paid conversion by just 0.5 percentage points, paid users rise to 45,000. That is 5,000 incremental subscribers, representing $210,000 in additional revenue.

Against $54,000 in annual AI infrastructure cost, the feature generates far more revenue than it costs to run. Ergo, it’s worth the cost.

However, if conversion doesn’t move enough and retention does not improve, you’re spending $54,000 to increase engagement metrics that do not affect revenue. Gross margin declines, contribution margin per MAU shrinks, and the feature becomes an expensive distraction.

This is how AI quietly kills subscription businesses.

Everyone is fixated on AI, but no one is fixing retention

Does this mean AI needs to increase conversion in order to justify its cost? Ideally, yes. But it can also improve retention.

With monthly ARPU of $6 and churn of 5%, theoretical steady-state LTV is approximately $120. If AI reduces churn to 4.6%, LTV rises to roughly $130. That is a $10 increase per subscriber, and across 20,000 subscribers, that’s $200,000 in incremental value.

Going back to the original figure, if AI costs $54,000 annually but produces even modest retention improvements (in the example, a 0.4% reduction), it can be one of the highest-return investments available.

Before getting too excited and adding new AI features, it’s worth remembering that retention improvements need to be observed in cohort data, not inferred from engagement alone. The improvements from AI need to be measurable.

Reading AI’s value: AI cost belongs in your revenue dashboard

RevenueCat already gives you a clear view of the metrics that drive subscription performance: ARPU, churn, LTV, and cohort retention. That’s half of the puzzle. If your app includes AI features, you need to be analyzing your AI infrastructure costs alongside those metrics.

In practice, this means combining your AI usage data with your subscription metrics to understand how usage affects margins.

You should know things like:

AI cost per MAU
AI cost per AI-active user
AI cost per paying user
AI cost as a percentage of ARPU
AI cost relative to blended ARPU

Looking at these numbers next to your subscription metrics makes it much easier to understand whether AI is strengthening your business or quietly eroding your margins.

At $6 ARPU and $0.18 AI cost, you’re spending ~3% of revenue. Fine. At $3.50 ARPU and $0.60 cost, that jumps to 17%. That’s not a feature cost, it’s a structural margin problem.

Blended ARPU in hybrid monetization

In hybrid monetization models combining ads and subscriptions, the analysis becomes more nuanced — if AI cost applies broadly to free users as well as subscribers, then cost per MAU needs to be evaluated against blended ARPU.

Putting that into numbers, imagine subscriber ARPU is $6, ad ARPU is $0.20, and blended ARPU across MAU is $0.95. If AI costs $0.06 per MAU, then that is ~6% of revenue. If AI costs $0.20 per MAU, it consumes >20% of blended revenue.

Analyzing the metrics is crucial in understanding how AI is reshaping your monetization model. Hybrid operators must be especially disciplined in protecting blended margin, but any teams working with AI features must be conscious of how it impacts margins.

Operator checklist: before shipping AI

Before launching any AI feature, you should be able to answer the following with numbers:

Which metric are you targeting? Install-to-paid conversion, trial starts, trial conversion, retention, or ARPU expansion?
What lift do you hypothesize? A 0.3 conversion increase? A 0.2 churn reduction?
What is the projected AI cost per active user and per paying user?
What percentage of ARPU will AI consume at expected usage levels?
At what usage threshold does AI push gross margin below your acceptable range?

If you can’t answer these questions, shipping isn’t strategic.

AI only works if the economics do

For years, subscription apps benefited from a simple economic model, and more engagement usually meant more value and better retention, with barely any increased cost. AI has changed that for good.

This doesn’t mean AI is bad for subscription businesses. In many cases, it can improve retention, increase conversion, and expand LTV. But those outcomes aren’t guarantees; they happen when teams treat AI as both a product feature and a cost layer.

Teams need to manage AI the same way they manage acquisition spend or infrastructure. Reuse results, route tasks to cheaper models, gate access behind monetization, and track AI cost alongside subscription metrics like ARPU and LTV. The most successful AI apps are not simply adding features, they are designing the entire system around the economics of usage.

“Solve time, and they’ll pay you”

Wed, 25 Mar 2026 14:30:28 GMT

Antoine van der Lee is the developer behind SwiftLee, a wildly popular iOS development blog, and RocketSim, a developer tool that supercharges the Xcode simulator. In a conversation with Charlie Chapman on the Launched podcast, he explains how RocketSim grew from a personal side project into a business approaching $100K ARR, entirely without traditional marketing. It’s a masterclass in building for your own needs, listening to your users, and understanding that the most powerful thing a developer tool can sell is time.

The pitch that writes itself

When it comes to selling developer tools, the value proposition can sometimes get muddy. Are you selling a better UI? A new workflow? For Antoine, the pitch for RocketSim is much simpler, and it comes directly from his head of sales.

“He just tells me it’s so easy to sell RocketSim,” Antoine says. “And the reason is RocketSim is focused on reducing time spent, and it creates more time to work on actual features. There are so many solved problems in the world, but if you manage to solve the one limitation factor, which is time, and give more time to people, they will pay you.”

It’s a framing that cuts through the noise. When you pitch a “network monitor” or a “recording tool,” you’re asking developers to change their habits. When you pitch “five minutes saved every day,” multiplied across a team of engineers over a year, the ROI becomes undeniable. You aren’t selling a feature; you’re selling the ability for developers to get back to the work they actually enjoy.

The 2-year open GitHub issue

In an era of AI agents and instant answers, it’s easy to feel like every technical problem should be solvable in an afternoon. But Antoine’s journey with RocketSim proves that some problems just require you to grow into the solution.

For two years, he had an open GitHub issue for a feature that would allow developers to slow down the network specifically for the simulator, without affecting the rest of the Mac’s connection. “Every single answer you would basically find on Stack Overflow,” he recalls. “But I created that issue like, ‘Okay, I want to create a solution that works just for the simulator.’ And that issue has been open for two years. I just couldn’t find the answer.”

Instead of forcing a bad solution, he let it sit. He went to conferences, talked to other developers, and waited for new APIs. When he finally cracked it, the payoff was immense. “The moment that it worked was so amazing because I was literally thinking about it for two years,” he says. It’s a reminder that persistence is often just as important as raw technical skill.

How 40 trials became 120

When deciding what to build next, it’s easy to get distracted by shiny new APIs or personal pet features. Antoine took a different approach: he maintained a public roadmap and let his users vote.

The top-voted feature was a network monitor. When he finally released it, the impact was immediate and measurable. “I saw the active trials going from 40 a day to 120 a day,” he notes.

The lesson is straightforward but often ignored: building exactly what your users are asking for doesn’t just satisfy your current audience—it acts as a powerful re-engagement tool for developers who churned because the app lacked a specific capability. “That really just proves if you build what your users want, the real fields will follow,” he explains.

The focus trap of going full-time

The dream of going “full-time indie” is having five uninterrupted days a week to work on your app. But when Antoine finally made the leap—having already matched his salary and built RocketSim to nearly $100K in recurring revenue—he discovered a counterintuitive truth: more time doesn’t automatically mean more output.

“When I was full-time indie, I let loose of all the things that I learned as a side hustle,” he admits. “So I didn’t prioritize anymore. I didn’t plan anymore. I just started the day and I was like, ‘Okay, let’s see what I’m going to do today.’”

When you’re building a side project on nights and weekends, the extreme scarcity of time forces you to be ruthless about prioritization. When those constraints vanish, it’s easy to fall into the trap of doing everything at once and finishing nothing. To succeed as a full-time indie, Antoine had to consciously rebuild the strict habits and boundaries that made him effective when he only had a few hours a week to spare.

In the full episode, Antoine also discusses the irony of AI agents killing the blogs they were trained on, why he actively cross-promotes with competing newsletters, and the time he tried to become a world champion in darts.

Guest links:

The Android paywall conversion gap: why the problem isn’t your trial, it’s your funnel entrance

Wed, 25 Mar 2026 06:46:34 GMT

Android’s subscription conversion rate, compared to iOS, looks like a platform problem. When RevenueCat analyzed over 115,000 apps and $16 billion in revenue for the 2026 State of Subscription Apps report, the numbers were clear: on Android, the median download to paid conversion at day 35 sits at 0.9%, while iOS lands at 2.6%. That’s a nearly threefold gap. The instinct is to blame the trial, or the audience, or some fundamental difference in how Android users behave. The data says otherwise.

Looking one level deeper in the same dataset, trial to paid conversion on Android is 32.5%. On iOS, it’s 32.6%. Once a user starts a trial on either platform, they convert at statistically the same rate. There is an important caveat: Android’s trial-starter pool is likely more filtered. Because Android surfaces fewer trials overall, the users who do start one tend to be higher-intent. That selection effect partly explains why the rates equalize. Even so, the primary lever is clear: Android apps are sending far fewer users into that first stage. Closing the gap starts with getting more users to begin a trial in the first place.

In this article, you’ll explore the two-stage Android paywall funnel and where Android apps lose users, how Google Play’s offer and tag system controls which subscription option is surfaced to users, how RevenueCat’s SubscriptionOptions selection works and where silent misconfigurations occur, what the data shows about hard paywalls versus freemium models, and how to use RevenueCat Experiments to close the gap systematically.

The fundamental problem: Two stages, one broken

The download to paid journey has two distinct stages, and they behave differently.

The first stage is download to trial start: the user installs your app, reaches your paywall, and decides whether to begin a free trial. The second stage is trial start to paid: the trial ends, and the user decides whether to continue as a subscriber.

The RevenueCat data shows these two stages behave very differently on Android. A user who starts a trial converts at 32.5%, close to the 32.6% on iOS. But Android apps are sending far fewer users into that first stage. The bulk of the conversion gap lives in stage one.

One data point makes this concrete: 89.4% of all trial starts happen on the day of install. Users who download with high intent act immediately. Users who do not start a trial on install day rarely return to do so later. That makes the first paywall impression on Android the moment that determines most subscription revenue. Everything downstream from that moment, including your trial experience, your onboarding, your product, performs about as well on Android as on iOS. The question is whether users reach that moment at all.

Stage one: What determines whether users see a trial

Two things control whether a user is presented with a free trial on Android: what you show (the paywall type) and when you show it (the timing). Both are fully within your control.

The paywall type gap

The RevenueCat data breaks down paywall models by D35 download to paid conversion, RevenueCat’s measurement window for capturing conversion across trial lengths up to one month. Hard paywalls, where users must interact with a subscription offer before accessing core features, achieve a median D35 conversion of 10.7%. The top 10% of hard paywall apps reach 38.7%. Freemium models, where users get some access without paying, convert at a median of 2.1%.

That’s a fivefold difference in conversion with nearly identical annual retention. Hard paywalls retain 27% of subscribers at 12 months. Freemium retains 28%. For most app categories, the hard paywall numbers are substantially better. If your product delivers clear, immediate value in a single session, a hard paywall is almost certainly the right model. Categories where freemium remains appropriate are those with network effects or long value-discovery cycles, such as social apps and community tools, where acquiring a broad user base matters before monetization.

Paywall model	Median D35 conversion	Top 10% D35 conversion	12 month retention
Hard paywall	10.7%	38.7%	27%
Freemium	2.1%	—	28%

There is one case where freemium shows a late-conversion advantage: at week six, freemium apps convert 22.9% of that cohort compared to 15.3% for hard paywalls. If your product has a long discovery cycle where value builds gradually over weeks, freemium captures users that a hard paywall would lose.

The paywall timing gap

The 89.4% Day 0 trial start rate has a direct implication for timing: show your paywall in the first session. Every session after the first is a sharply diminishing return.

This doesn’t mean presenting the paywall before any onboarding. Apps that show a paywall before a user understands the product’s value typically see worse opt-in rates. The pattern that works is: deliver one compelling value moment first (a single completed task, a key feature reveal, a concrete output), then present the paywall. On Day 0.

The hidden failure: When offer misconfiguration silently suppresses trials

Even if your paywall type and timing are right, there’s a second source of trial failures on Android that is harder to spot: the subscription offer itself may not be visible. This is a Google Play configuration issue, and it can happen without any error.

How Google Play structures subscription offers

Every subscription on Google Play consists of a base plan and, optionally, one or more offers. An offer defines a promotional pricing phase (a free trial, an introductory price, or both) that precedes the base plan price. Offers are represented in the Billing Library as ProductDetails.SubscriptionOfferDetails.

Each SubscriptionOfferDetails object has a list of pricing phases, a set of offer tags, and an offer token used to initiate the purchase. The pricing phases tell you the price and duration of each stage. The offer tags are strings you define in the Play Console at either the base plan level or the offer level. The Billing Library returns the union of both sets in getOfferTags(), so a tag set on the base plan automatically appears on all offers under it.

When RevenueCat fetches your products, each SubscriptionOfferDetails is converted to a GoogleSubscriptionOption. Looking at the conversion in subscriptionOptionConversions.kt:

The offerId is null for base plans and set for offer-based options. The offerToken is what gets passed to the billing flow when the user taps “Start free trial.” The offerTags carry the labels you assigned in the Play Console.

How RevenueCat selects the default offer

Once your product has a list of GoogleSubscriptionOption objects, RevenueCat groups them in a SubscriptionOptions collection and exposes a defaultOffer property. This is the option your paywall shows unless you explicitly select a different one.

The selection algorithm in SubscriptionOptions.kt works as follows:

The algorithm filters out any offer tagged rc-ignore-offer or rc-customer-center, then selects the offer with the longest free trial. If there is no free trial, it selects the offer with the lowest introductory price. If no offers pass those checks, it falls back to the base plan with no promotional phase at all.

That fallback is the silent failure. If your trial offer is tagged rc-ignore-offer, if it is not attached to the right base plan, or if it simply has no offer tags at all and your app relies on tag-based filtering, defaultOffer returns the base plan. Your paywall renders. Everything looks fine. No error appears. But the trial is gone.

Detecting what your paywall is actually showing

Before optimizing anything else, verify that defaultOffer on your product resolves to an offer with a free trial. The SubscriptionOption interface exposes a freePhase property for exactly this check:

A non-null freePhase means the option includes a free trial phase. introPhase similarly checks for introductory paid phases. If your defaultOffer has a null freePhase and a null introPhase, no promotional phase will be shown. You can also check defaultOffer?.isBasePlan directly: a true value means the SDK found no eligible offer and fell back to the base plan. Either way, inspect your offer configuration in the Play Console.

You can check this in code after fetching offerings:

Run this during development and confirm the output matches your Play Console offer configuration. If hasFreeTrialOption is false and you expected a trial, the offer is not being selected. Check offer tags, verify the offer is in the correct base plan, and confirm the offer is active in the Play Console.

One structural difference to be aware of

Before moving to tracking and experimentation, it is worth naming one platform-level difference that the Android-iOS comparison does not fully capture.

On iOS, Apple sends a system-level push notification before a trial ends, reminding the user it will convert to paid. Google Play does not send an equivalent system notification. This means iOS gets a built-in re-engagement nudge at the critical trial to paid moment, and Android does not. On Android, that reminder is entirely your responsibility: an in-app banner, a push notification from your own backend, or a re-engagement flow triggered when the user returns near the end of their trial.

This structural difference partially explains why the trial to paid rates look similar despite the very different trial-starter pool sizes: iOS has a platform assist at the conversion moment. On Android, the same result requires explicit implementation. If your Android trial to paid rate is below your iOS rate, the absence of a trial-end reminder in your app is a likely contributor.

Tracking paywall performance with PresentedOfferingContext

Once your offer configuration is correct, the next step is understanding which paywall placement drives the most trial starts. RevenueCat’s PresentedOfferingContext lets you attach a placement identifier to every purchase, so your analytics can segment by where in the app the paywall appeared.

PresentedOfferingContext carries three fields:

The offeringIdentifier is the offering from your RevenueCat dashboard. The placementIdentifier is a string you define to label the surface: "onboarding_paywall", "settings_upgrade", "feature_gate", and so on. The targetingContext carries rule data when you are using RevenueCat’s targeting feature.

When you initiate a purchase, this context travels with the transaction and appears in your RevenueCat dashboard and webhook events. You can then compare trial start rates and D35 conversion across placements and determine which surface is worth optimizing first.

Trial length: The overlooked variable

Beyond offer visibility and paywall type, trial duration has a measurable impact on trial to paid conversion. The RevenueCat data shows a clear pattern:

Trial length	Trial-to-paid conversion
4 days or fewer	25.5%
17 to 32 days	42.5%

Apps offering longer trials show roughly 17 percentage points higher trial to paid conversion in the dataset. This is a correlation: apps that offer longer trials tend to be more deliberate productivity and creative tools where longer trials reflect a conscious product strategy, not just an arbitrary setting. Extending your trial duration does not guarantee a 17-point improvement. Yet the pattern suggests that for apps where value compounds over time, a 4-day trial may end before a user has had a meaningful product experience, while a 14 or 30-day trial gives the product enough time to demonstrate its value.

Yet 55% of all trials in the dataset are now 4 days or shorter, up from 42% the previous year. Only 5% of apps offer 17 or more days.

If your trial to paid rate is below the 32.5% Android median, trial length is worth testing. It is one of the higher-leverage variables to run through RevenueCat Experiments without needing to ship new code.

Measuring and iterating with RevenueCat Experiments

All of the variables discussed so far (paywall type, timing, trial length, offer selection) interact in ways that are hard to reason about without measurement. What works depends on your specific product, your audience, and your category.

RevenueCat Experiments lets you run A/B tests against these variables without shipping code changes or building backend infrastructure. You create a variant offering in the RevenueCat dashboard with a different configuration: a different trial length, a different default offer, or a different package lineup. RevenueCat randomly assigns users to control or variant, tracks their behavior through the full trial and conversion cycle, and surfaces D35 conversion, LTV, and trial start rate broken down by variant.

Once your experiment is running, you can monitor trial state per user via EntitlementInfo.periodType in CustomerInfo:

The periodType tells you the current phase of the user’s subscription. This is useful for building trial-aware UI: showing a banner when a trial is about to expire, adjusting messaging based on subscription phase, or triggering a re-engagement paywall for users whose trial ended without converting.

Putting it together

The Android conversion gap is primarily a funnel-entrance problem with identifiable causes. The threefold difference in D35 download to paid between Android and iOS does not reflect a platform ceiling. It reflects the aggregate effect of offer misconfiguration, freemium models that suppress trial uptake, and paywalls shown too late or not at all. A structural platform difference also contributes: Android does not send system-level trial expiration reminders the way iOS does, so re-engaging users near trial end requires explicit implementation on your side.

The path to closing the gap follows a specific sequence. First, confirm that defaultOffer on your active offering resolves to an option with a non-null freePhase. If it doesn’t, fix the Play Console offer configuration before changing anything else. Second, if you are running freemium, run an experiment against a hard paywall variant and measure both trial start rate and 12-month retention. Third, if you are already running a hard paywall, test a longer trial duration. Fourth, add placementIdentifier to your PresentedOfferingContext so you can attribute trial starts to specific surfaces.

Each of these changes is measurable. RevenueCat Experiments gives you the infrastructure to test without guessing, and the D35 and trial to paid metrics give you the signal to act on.

In this article, you’ve explored how the Android paywall conversion problem lives primarily in stage one of a two-stage funnel, how Google Play’s offer and tag system determines which subscription option is surfaced, how RevenueCat’s SubscriptionOptions.defaultOffer algorithm selects a trial and where silent misconfigurations occur, what the data shows about paywall model choice and trial length, the structural platform difference around trial reminders, and how to diagnose and iterate using RevenueCat’s tooling.

Understanding where the gap lives changes what you build. Most of the work is in stage one: getting users to see and start a trial. The Android user who starts a trial converts at nearly the same rate as the iOS user. The work is making sure they get the chance to start, and giving them a reason to convert before that trial ends.

Why free trials don’t make sense anymore (and what user acquisition tactic to try instead)

Mon, 23 Mar 2026 17:54:54 GMT

Since subscription apps first started to gain in popularity, free trials have been a foundation for most user acquisition (UA) marketers, serving as the main proxy event to attract real long-term subscribers. But this tactic, like so many other elements of our industry, has been changed by AI and vibe-coding. It’s now harder than ever to run campaigns optimizing towards a free trial, largely due to the enormous competition and overall declining trial conversion rates.

As the State of Subscription Apps 2026 shows, there’s a growing trend of trials shortening to three days — despite data encouraging the opposite; showing that trials with 17+ days convert 70% better (42.5% paid conversion rate vs. 25.5%).

State of Subscription Apps 2026 — trial-to-paid, by trial duration

Even with this huge discrepancy, nearly half of all apps now use trials of four days or less, seeking immediate revenue and shorter payback periods that make publishers’ margins more affordable from the UA perspective.

This is not a coincidence. AI has drastically changed the whole market: by adding variable and rising costs to the use of its technology, AI has forced publishers and developers to look for higher average revenue per user (ARPU) in the shortest time possible, in order to can’t cover these costs and sustain the business. Otherwise, the apps become unmarketable themselves, making the product-market fit (PMF) process harder than ever.

If you also consider the popularity of how web-to-app campaigns can help you to nail signal engineering, we can easily draw the conclusion that free trials don’t make much sense anymore. But is that a fair blanket statement? I think it’s true, but that doesn’t mean free trials are over. We can still play with a more advanced version of this conversion event.

Before exploring what that looks like, let’s dive into the reasons why free trials became so popular on subscription apps.

Free trials: the purchase proxy event

The title speaks for itself: The free trial event has been the foundation of endless companies’ UA strategies for a simple reason — a free trial is the closest event to purchase. What’s more, the event can filter purchase intention, without sacrificing the volume that ad networks need to optimize performance efficiently.

When AI didn’t exist and the offer of apps was more limited, free trials were widely used as a technique to convince the user to convert, with publishers heavily relying on their products and UX to make the conversion effective. But that doesn’t apply anymore. Today, hard paywalls with direct subscriptions are becoming more present, with data showing they generate close to double the upfront revenue vs. freemium apps.

State of Subscription Apps 2026 — day 35 download-to-paid, freemium vs. hard paywall

This growing shift away from free trials is clearly visible when you compare 2026’s report vs. 2024. We can see how all categories have seen a 14% increase in the non-trial strategies (28% in 2024 in non-trial strategies vs. 32% in 2026) where free trials are non-existent.

State of Subscription Apps 2024 — trial strategy

State of Subscription Apps 2026 — trial strategy, by category

With such a fast evolution, publishers need to adapt to the new reality since ChatGPT normalised paying $20/month for an AI chatbot. And the shortest path for that is playing with pricing, which explains this change in the overall trial strategy.

Web campaigns: a lever pushing free trial extinction

At this point, it’s no longer a new topic: web and web-to-app funnels are now the norm for the biggest publishers due to multiple reasons:

The 30% fee you save due to Apple or Google’s commissions
Higher flexibility and speed to run multiple A/B tests with the onboarding and pricing
Higher accuracy on campaign attribution without relying on SKAN and its limitations
Higher purchase intention in users
More and new inventories where you have more control to filter purchase intention
Retargeting is real for iOS users

Although it’s true that, at the moment, web onboarding doesn’t make too much sense for small publishers that are under the 15% commission — due to the additional complexities you have to handle (tax compliance, 3% fee to Stripe or similar, managing refunds internally, platforms to build onboarding, etc.) — the change in strategy of the biggest players has directly affected the trends in the market. Now, even small devs are pushing to copy these strategies.

With this current outlook, the question is no longer whether to move away from the classic free trial, it’s about what you replace it with, and when. The market has split:

Hard paywalls with direct subscriptions: for apps with strong PMF and vitality
A more sophisticated version of the free trial mechanic, that preserves the volume ad networks need while dramatically improving signal quality

The second option is what I like to work with — and in my opinion, it will be the future standard when it comes to signal engineering.

At App Growth Annual 2025, I did a workshop where I explained the immediate effect that paid trials (introductory offers) have in your activation metrics and UA performance. Today, I see more and more companies applying this strategy on their web campaigns, as these normally target users with real purchase intention easier than app campaigns.

Trial qualifier or paid trial events aren’t mutually-exclusive

As shown in my article on intro offers, introducing paid trials in your app or web campaigns can drastically change your numbers. But you have to pay close attention to monitoring the conversion rate after the paid trial — this strategy effectively harms your short-term lifetime value (LTV), compared to a hard paywall with a direct subscription.

The State of Subscription Apps report shows that ~30% of new subscribers now enter through intro offers (median).

State of Subscription Apps 2026 — share of new payers acquired via an intro offer, by category and revenue tier

The $0.99 first month model doesn’t just improve conversion — it fundamentally changes what signal you’re feeding the algorithm. You’re no longer training the network on “users who clicked a free button”. You’re training it on users who handed over a credit card, which is a completely different behavioral profile. That’s a gamechanger if you’re able to target those users efficiently with a correct creative strategy in your paid campaigns.

This started to become more popular on web and web-to-app campaigns since you could use specific channels to filter purchase intent in the upper funnel part of the metric, just by launching channels with inventories with high control capabilities — unlike the automated app campaigns which are now the norm in all ad networks that offer app campaigns promotion.

For example, when launching Google Ads with a search campaign, you have the possibility of creating specific ad groups for each audience segment. Within these, you can target different purchase intent levels by just playing with the keywords. A good strategy would be using keywords with and without “free” in the term, to see what’s the performance towards that trial qualifier event.

Using this type of advanced targeting with a paid trial has become a really successful tool for many publishers that wanted to boost the algorithm with real paying signals on day 0, instead of proxy events whose median averages 30–35% vs. the real subscription (source: SOSA).

But for me, this isn’t going to be the norm in the near future. Trial qualifiers will take this role. And the most positive news is that you don’t have to do one or the other, you can keep paid trials for your web campaigns where you have more control over the intention of the users, while utilizing trial qualifiers for app campaigns.

Looking again at the State of Subscription Apps 2026, we see that nearly all trial starts happen on day 0 across categories. Users who don’t try immediately during the onboarding rarely try at all.

State of Subscription Apps 2026 — time to trial, by category

With this data, the main takeaway is clear: trial qualifier events are the best tool for advertisers right now. Here’s why:

You still feed the algorithm with signals on day 0, but without forcing the user to use a credit card
You still optimize towards an event that happens immediately before the purchase, but with a deeper intent than the classic trial
And most importantly (in my opinion) you have full control to play with the signals that you send for this trial qualifier event, because you have access to the purchase behaviour of your users

So how do you get started implementing this in your campaigns?

The new free trial: how to set up an advanced free trial

Personalisation of the trial qualifier event will heavily depend on the app category, subscription tiers offered in the paywall, and the historical behaviour and data you can analyze from the classic trial start event. But as an initial setup, you can create the trial qualifier event based on the following conditions:

1. Time without cancelling the free trial

Most trial cancellations happened within the first two hours after starting the trial. The data shows cancellation is at its highest on day 0, closely followed by day 1.

State of Subscription Apps — % of trial cancellations, by day and trial duration

These cancellations are users who just want to see what’s behind the paywall but they will never purchase. However, they will contaminate the signals you send to ad networks when working with the trial, making your overall performance worse — so these are the first users that need to be filtered out. In this case, you should analyze the historical data to see which time filter accommodates better to your app.

2. Time without cancelling the free trial + engagement

Some products have drastic differences in LTV, retention, and payback periods between users; specifically those who stick to the product and use it actively, versus those who just subscribe and forget about the app. So a smart way of nailing the trial qualifier is to add engagement signals [that happened in the first session] to the time without cancelling metric. This creates a more robust and reliable signal that you can send to the ad network to optimize your campaigns.

One word of warning is to avoid being very picky with the engagement points during this first session, otherwise you will sacrifice too much signal volume and your campaigns will struggle to optimize.

3. Time without cancelling the free trial + sending an additional signal the day after the trial started

This is similar to the first point, but with a deeper complexity, as you send two signals per user instead of just one. This strategy is based on sending the initial signal two hours after trial starts, and then another extra signal the day before the trial ends. For example, if you have a 3-day trial, you would send one initial signal two hours after the trial starts, and another signal if the user keeps the trial active on day 2. This helps with the volume of events, making the optimization of campaigns easier for ad networks. At the same time, it adds difficulty to calculate the real trial conversion rate and incrementality.

4. Automate trial qualifier mapping

If you want to go one step further, you can now use the new RevenueCat integration with Appstack, and automate mapping your trial qualifier events in just a couple of clicks. With this integration you’re able to send campaign users to specific paywalls made with RevenueCat, allowing you to fully customize the user experience, from when they watch an ad all the way to completing onboarding in your app. I think this is a unique feature in the market which will dramatically change the way paywalls are made and tested, since you can now feed these tests to users with deep purchase intent.

Ultimately, I suggest you take these initial ideas and start playing with the trial qualifier event, then compare the performance of these campaigns against your classic free trial campaigns. Once you find a winning path, you can start an ongoing process of filtering your signals until you reach the perfect balance between signal quality and quantity for the ad network.

Ready to revamp your free trial?

I know this article may sound somewhat dramatic, and of course there will be cases where you still get a better performance with classic free trials. However, according to what I see everyday working with different apps, we’re rapidly moving to the immediate pursuit of results (thanks to the increasing marginal costs attached to AI). So I believe in the near future we’ll have most apps refining their free trial signals in this way, allowing them to be more accurate with ad delivery — and overall maximizing the efficiency of every dollar invested in their UA.

The State of Subscription Apps in 10 minutes: lessons, trends, and benchmarks for 2026

Thu, 19 Mar 2026 16:16:53 GMT

Each year, our State of Subscription Apps report sets out to understand what’s changing in the industry; what’s new, what’s over, and what’s on its way. This year, our dataset grew again: over 115,000 apps, representing more than $16 billion in revenue. And we analyzed the data from all 115k+ of them.

If you thought last year’s report was a behemoth, look away now. This year, we’ve delivered 338 pages, ready to give you every metric, benchmark, or trend you could possibly need.

To summarize David Barnard’s own words, “There’s a lot of apps making a lot of money.”

But, if you (shockingly) don’t have time to read every single page (like David and Jacob did), then this rundown’s for you. Strap in.

1. Subscription app growth is no longer a spectrum

2026 shows a huge polarization in app growth. Where maintaining steady growth (e.g. 5–15% YoY) was previously considered safe and healthy for an app business, today’s data shows this middle ground evaporating beneath our feet.

Market dynamics — user acquisition costs, algorithm changes, platform fees, AI unit economics — now heavily reward the top performers, creating a mobile app economy that mirrors broader wealth inequality: the rich get richer, and indie developers struggle to stay afloat.

The data:

Top quartile: the top 25% of subscription apps grew their monthly recurring revenue (MRR) by 80% or more year-on-year
Bottom quartile: the bottom 25% of apps saw their MRR shrink by more than 33%
The divide: this creates a massive 113-point gap between the winners scaling aggressively and the apps bleeding revenue
Comparison to 2025: last year’s data saw the revenue gap increase between the top 5% and bottom 25% (with the top earning 400x more, up from 200x in 2024) – a trend the 2026 data confirms and quantifies for the first time in growth rate

Median year-on-year monthly recurring revenue growth rate, by developer HQ — State of Subscription Apps 2026

What next?

App teams can no longer rest on ‘good enough’. There is no safety blanket. If you’re growing at the median rate (5–17%), you’re at risk of falling into the bottom quartile and slipping through the cracks. Teams need to shift from maintenance mode to aggressive growth optimization.

→ Your next step: learn about the Subscription Value Loop, a framework for app growth

2. Hard paywalls convert 5x better than freemium

We’ve all heard the rhetoric that “hard paywalls kill user experience”. Well, consider that mythbusted. Across categories, Day 35 trial-to-paid conversion is 5x better when apps feature a hard paywall. Contrary to popular belief, hard paywalls are not scaring users away or ‘forcing’ them into buying before ready — this narrative only belittles users, who are subscription-savvy and will only convert when they want to. Today, users are engaging with hard paywalls, and it’s giving apps faster payback.

This choice [hard paywall vs. freemium] changes your unit economics completely. Same ad spend. Dramatically different revenue on day one. — Sven Jürgens, Mobile Growth Consultant

While paywall type impacts conversion, long-term retention equalizes across both access methods. Freemium apps continue to convert well into Week 6 and beyond, meaning the full conversion picture is a longer game than you may think.

So freemium doesn’t mean less success — and there are many successful freemium apps that prove this — but the data definitively proves that hard paywalls convert better, and convert quicker. In 2026, freemium may feel like the safer option, but it’s not necessarily the best choice.

The data:

Conversion: hard paywalls have a median Day-35 trial-to-paid conversion rate of 10.7%, compared to just 2.1% for freemium apps — this is roughly a 5x advantage
Retention: freemium apps retain 28% of yearly subscribers after 1 year, while hard paywall apps retain 27%, making the difference statistically negligible
Revenue per install: hard paywall apps generate 8x higher RPI at day 60, compared to freemium ($3.09 vs. $0.38)
Comparison to 2025: while freemium D35 conversion has remained at 2.1% since 2025, hard paywall conversion has gone down ~2% (12.1% in 2025), suggesting a broader reluctance to convert

Day 35 download-to-paid, freemium vs. hard paywall — State of Subscription Apps 2026

What next?

Switch to a hard paywall (if you dare 😈). Hard paywalls offer an upfront ROI, giving you a chunk of cash to reinvest in growth. If you’re relying on a freemium model to build goodwill, you’re sacrificing massive top-of-funnel revenue for a just 1% retention bump a year later. Given the aggressive market, it’s a risky move to take.

→ Your next step: discover what the best subscription apps get right about paywalls

3. The Day 0 buyer’s remorse window

Plot twist: your 3-day trial is actually a 1-hour trial. Yep. 55% of all trial cancellations happen on Day 0. So while developers are designing a three-day experience, the modern consumer’s attention span is demanding instant proof of value.

Teams can no longer assume users spend days exploring all app features before making a decision; the reality is that users treat app trials like impulsive retail purchases. They subscribe to get past the paywall, immediately experience and assess the core features, then cancel to prevent being charged. If you don’t deliver an aha! moment in the first 60 minutes, the subscriber is already gone.

The data:

Day 0 cancellations: exactly 55.4% of all 3-day trial cancellations occur on Day 0
The drop-off: an overwhelming 84% of 3-day trial cancellations happen between Day 0 and Day 1
Comparison to 2025: last year, ~51% of 3-day trial cancellations happened on Day 0 (showing a ~4% increase this year), suggesting users quickfire cancel instinct is only increasing

% of trial cancellations, by day and trial duration — State of Subscription Apps 2026

What next?

Treat your onboarding flow as your primary retention mechanism. If a user doesn’t hit the aha! moment in their very first session, they’re going to quickly toggle off auto-renew. Revisit your trial length — does it need to be three days? (More on this next.)) Consider the features you give access to in a trial — what shows value instantly, and what takes up space? Figure out the most direct route to proving value, then build it.

→ Your next step: stop chasing growth hacks — learn how how to fix your onboarding first

4. The 7 day trial is alive and kicking (sometimes)

The subscription app industry is obsessed with short trials, but what do the numbers actually show? Is the 7-day trial really dead?

In short, no.

Trials of 17-32 days convert 70% better than 3-day trials (42.5% vs 25.5%). Yet, 46% of apps are moving to trials of 4 days or less. Why? Growth teams are under market and economic pressure to show fast revenue.

Most developers do 3-day free trials for cashflow. You want the money in three days, not 30 days. [Or you’re looking to] get conversion data faster, to compound onboarding and paywall experiments. — David Barnard and Jacob Eiting speak about on Sub Club

Short trials force a fast decision from users, often resulting in high abandonment (see the Day 0 cancellation rate of 3-day trial vs. longer), while longer trials give users time to integrate an app into their daily habits, and reduces nerves about accidental auto-renewal. 3-day trials are useful for app teams, but the reality is you’re sacrificing long-term conversion for a short-term dopamine dashboard spike.

The data:

Long-trial conversion: trials of 17–32 days convert at an incredibly high median of 42.5%
Short trial conversion: trials of <4 days convert at just 25.5%, meaning long trials convert ~70% better
Comparison to 2025: last year, trials were increasing in length, but today, despite the data, trials of <4 days rose from 42.1% in 2025 to 46.5% in 2026

Trial-to-paid, by trial duration — State of Subscription Apps 2026

What next?

Deep dive into your category’s trial and retention data. Watch the crowd, but don’t feel locked in to follow them. Try experimenting with longer trial length and see how your conversion and retention changes. Show value upfront, then give users adequate time to experience it.

→ Your next step: determine the optimum trial length for your app

5. Annual subscriptions aren’t the guarantee you think they are

When users buy an annual subscription, it feels like a sigh of relief for the developer. You relax, assuming that annual sub means 12 months to prove the app’s value. 12 months to demonstrate each carefully-designed feature, and deliver a clear message of “I should keep using this app” come Year 2.

But the data reveals a harsh truth: over one third of users cancel auto-renewal within the first month. Users aren’t stupid, and they don’t think of an annual subscription as a rolling purchase — they consider it a one-off payment for this year, then immediately protect their wallet. Meaning that Year 2 revenue you’d already relied on? It’s gone before Year 1 has even really begun.

The data:

Month 1 churn: the first month accounts for 35% of all annual cancellations
The cancellation curve: after the Month 1 spike, cancellations drop to just 3–10% for the middle of the year, before spiking again in Month 12 (pre-renewal)
Comparison to 2025: ~56% of annual subscribers cancelled in Year 1 in 2025, while this worsened to ~72% in 2026; however the Month 1 cancellation spike remains fairly comparable between years

Cancellation timeline for annual subscriptions — State of Subscription Apps 2026

What next?

App teams can no longer rely on users ‘forgetting’ about an annual subscription. The battle for Year 2 starts in Week 1. You don’t have 11 months to win an annual renewal, you need to preemptively convince users to not cancel auto-renew. This means intensive value reinforcement from the moment they download, and win-back campaigns throughout the first two months to persuade users to toggle auto-renew back on, while they’re first engaged.

→ Your next step: explore the pros and cons of annual subscriptions, then learn how to improve your annual subscription uptake

6. The Google Play tax

For Android devs, growth is actually an engineering problem. 31% of Google Play cancellations are involuntary billing failures — over double the rate of the App Store (14%).

When an app loses a subscriber, blame usually falls to the product features or pricing. However, for Android apps, nearly a third of churn isn’t because the user hated the app, it’s simply because their credit card failed, expired, or was declined, and the app’s billing infrastructure wasn’t robust enough to recover it.

This money is unclaimed revenue: growth isn’t just about ads; it’s about plugging the technical leaks in Google Play’s ecosystem through better retry logic and grace periods.

The data:

Google Play billing failures: a massive 31% of all subscription cancellations on Google Play are due to billing errors
App Store comparison: on the App Store, billing errors account for only 14% of cancellations
Comparison to 2025: Google Play’s billing errors have worsened, from 28.2% in 2025 to 31% this year; meanwhile the App Store’s improved, reducing billing errors by 1.1% (15.1% in 2025 vs. 14% in 2026)

Cancellation reasons, by app store — State of Subscription Apps 2026

What next?

If you have a significant Android user base, your highest ROI activity is optimizing your dunning process (billing retries) and enabling grace periods. Handled appropriately, Android apps can almost instantly recover 15-20% of lost revenue, without acquiring a single new user.

→ Your next step: learn how to counteract the Google Play billing leak, and set up winback campaigns for lapsed subscribers

7. The AI paradox: acquisition beast, retention nightmare

AI sells like crazy, but it doesn’t stick. While AI-powered apps generate 41% more revenue-per-user, those same apps churn 36% faster than non-AI apps. The problem isn’t convincing users to download your AI app (clearly, users want to pay for AI), the challenge is keeping them invested.

Amidst the vibe coding hype and established developers watching as new apps dilute market real estate, the data proves AI apps aren’t in it for the long haul (yet). AI features are driving massive trial revenue, yet many AI apps suffer from an alarming lack of product-market fit. Users may be willing to pay a premium to try AI tools, but once they download, they’re not finding the long-term utility to justify its hefty pricetag.

Yes, vibe coded apps can ship fast. Yes, AI features act as a massive top-of-funnel magnet, but this doesn’t guarantee the same audience further down the line. It doesn’t mean they can sustain a user base. Experienced developers still have an edge: stamina. They know how to maintain an app, build trust with an audience, and grow revenue. That is the real differentiator between what apps succeed and which fall behind — not who can build an app fastest, what AI features it has, or whether a human or agent wrote the lines of code.

The data:

The AI premium: AI apps sustain a 41% Year 1 realized LTV premium compared to non-AI apps ($30.16 median vs. $21.37 median)
The churn problem: Despite the high revenue, AI monthly plans retain 36% worse over 12 months than traditional apps
Comparison to 2025: AI apps showed 12-month payer retention of 9.2% (App Store) and 11.5% (Google Play), comparable to traditional apps in respective categories; suggesting 2026’s sharp dip in retention is a problem emerging after AI apps settled into mainstream and users had longer to assess them

Retained subscribers after 12 months, by AI vs. non-AI — State of Subscription Apps 2026

What next?

Shipping fast or relying on AI hype isn’t enough. If you add AI to your app, use the influx of cash to build a genuine user experience and robust backend. Don’t rely on novelty or one-off AI gimmicks. These will only churn in a few months. Look to established apps for retention and growth lessons, then use AI to make them happen fast. The long game will be won not by AI vs. non-AI, but by whoever can utilize AI and human expertise.

→ Your next step: revisit core value offered to users and secure product-market fit

Looking to 2027

The data from 2026’s State of Subscription Apps report highlights emerging shifts in the app industry, from the influx of new apps (14,000+ a month!) to the rapid dissolving of the average app’s revenue safety net. But many of these trends are not surprising — Google’s billing leak has been a prominent issue for several years, and the relationship between trial length and conversion isn’t new either. What is clear from 2026’s data is that apps can no longer afford to ignore these accumulating changes and known issues.

‘Good enough’ is no longer good enough. Just as quickly as top apps are growing their revenue, the lower quartile are churning it. Subscription apps that are designed with user value as the core and marketed with intention have found their place in the ecosystem. Their success compounds over time, and the rest of the app store is left fighting over scraps. All that’s left is for teams to decide which side of the line they wish to sit on come 2027’s report.

The 7-day trial, and other free trial myths: how to choose the right trial length for your subscription app

Thu, 19 Mar 2026 14:28:56 GMT

I once got a 34-day free trial. Not 30 days, not ‘one month’, but thirty-four days.

It was for YNAB, a personal budgeting app. At first, it felt completely random. Most free trials hover between five and nine days, so why 34?

But when I opened the app, it all made sense.

Budgeting doesn’t deliver instant value; you need a full cycle:

A payday
Bills going out
Real behavior over time

YNAB wasn’t trying to impress me in a week. They were giving me enough time to actually experience the product.

That moment really stuck with me. It made me wonder: are we, as an industry, selling ourselves short by defaulting to seven-day trials?

In 2024, just over half of all trials fell within the 5–9 day range, up from 2023. In 2025, trials are getting even shorter. Trials of four days or less gained share, rising to almost half (46.5%) of all trials.

Trial duration, year-on-year — State of Subscription Apps 2026

While we’ve all heard “the 7-day trial is dead” generalization thrown around, that seems to be because trials are only getting shorter. So, despite all the nuance we’re about to explore, the industry default is becoming more entrenched, not less.

And that’s the problem. A seven-day trial isn’t inherently bad; it’s just rarely questioned. Trial length deserves the same level of thought as onboarding, activation, and retention.

Because at the end of the day, trial length isn’t a pricing decision. It’s a product decision.

Hannah Parvaz, Founder of Aperture, puts it:

“I’m very much in the ‘trial length is a design decision, not a default’ camp. Across multiple subscription apps, the biggest mistake I see is treating trial length as a growth lever in isolation, rather than anchoring it to time-to-value and confidence-building.”

That idea — that trial length is a product decision — sent me down a classic Daphne rabbit hole: what actually determines the right free-trial length?

Before trial length: should you even offer a trial?

Before we dive into different trial lengths, there’s a more important question to answer first:

Do you even need a trial?

Optimising trial length is meaningless if the trial itself is the wrong strategy.

I used to think trials were a must. After all, most apps across categories offer some form of trial, according to the State of Subscription Apps 2026:

Trial strategy, by category — State of Subscription Apps 2026

Not a single category has a majority of apps without some form of trial. The closest is from Social, who have the highest no-trial strategy at 43.6%.

I read an article by David Vargas that completely changed how I think about trials — he frames it this way:

“We have to remember that a free trial is just one strategy. It relies on how ‘sticky’ the product and features are to convince users to subscribe.”

What really caught my attention was an experiment where David removed the free trial entirely.

It felt bold (my favorite type of experiment) and slightly terrifying. But the context mattered. They were seeing strong trial-to-paid conversion, yet paid acquisition wasn’t working; the cost per acquisition was too high once they factored in how many trial starts were needed to land a single paying customer.

Removing the trial nearly doubled lifetime value and unlocked paid growth.

That’s an important consideration, even if you keep a trial. Unless your trial is very short, you’ll usually end up optimising paid channels for trial starts rather than purchases. And if conversions occur outside the attribution window, ad platforms optimize for people who like starting trials, not for those who actually pay.

So the first principle is this:

Don’t touch trial length until you’re clear on whether a trial should exist at all.

Testing removal sounds scary, but if your trial isn’t pulling its weight, it’s worth questioning the assumption or focusing first on adding real value with your trial. As Dan Layfield, Founder of Subscription Index (ex-Codeacademy and Uber), puts it:

“Trials are your friend so long as they are visible, clear, and appealing to your users.”

Once you’re convinced your trial should exist, then it’s time to debunk some trial myths.

The myth: shorter trials convert better

Our instinct is simple: shorter trials create urgency, urgency drives action, and action drives conversion. Simple, right?

It’s the same line of thinking as running a 24-hour sale or telling users an item is almost sold out. It’s a massive kick up the rump.

And sure, there are situations where short trials help, especially if you want to quickly optimize paid campaigns for purchases. But the data shows it’s more nuanced.

According to RevenueCat’s State of Subscription Apps report, shorter trials come with huge day 0-1 cancellation spikes. For three-day trials, over 55% of users cancel almost immediately. Compare that to around 31% for 30-day trials.

% of trial cancellations, by day and trial duration — State of Subscription Apps 2026

That early cancellation doesn’t automatically mean poor intent. Often it’s driven by:

Lack of trust
Fear of forgetting to cancel
And the classic: “I’ll cancel now just in case”

What’s interesting is that the longer the trial, the less cancellations. 84% of 3-day trial cancellations and 64% of 7-day trial cancellations happen between day 0–1. The risk isn’t late, it’s right at the start.

So no, shorter isn’t automatically better. But now I’ll get annoying: longer isn’t automatically smarter either.

Longer trials: when they help, and when they hurt

When people hear this, they often jump straight to: “Longer must be better.”

But blindly following aggregate data is just as dangerous as defaulting to a seven-day trial.

Yes, 17–32 day trials do show higher trial-to-paid conversion on average (a 42.5% median conversion vs. <4 day trials’ 25.5% conversion rate):

Trial-to-paid, by trial duration — State of Subscription Apps 2026

That sounds great, but we often assume trial-to-paid conversion automatically equals a better outcome, and that’s where things get tricky.

For example, I worked with a wellness app where our key activation metric was consuming two long-form content pieces within 14 days. Each piece lasted about 45 minutes and was tied to (but not exclusively) a weekly live session. That behaviour was a strong predictor of long-term retention.

So we asked the obvious question: why run a seven-day trial when our activation window is 14 days?

Time for an experiment: we A/B tested a 7-day vs 14-day trial. While the longer trial drove slightly more trial starts, fewer people converted overall.

Not because people were abusing it or needed more time, but because activation didn’t improve. People weren’t consuming more content; they were delaying. Classic procrastination. It performed worse in converting to paid, and we reverted to the 7-day trial.

That’s the dark side of long trials we’ve all experienced. A long gym trial feels painless to postpone, but a short, paid intro lesson you need to book within seven days forces action. “I’ll use it later” quietly becomes “I never really did.”

The takeaway: trial conversion is just a leading metric. What actually matters is:

Revenue per user over time
Retention
Sustained engagement

There’s even a great SaaS study by Hema Yoganarasimhan, Ebrahim Barzegary, and Abhishek Pani showing that shorter trials (seven days) can outperform 30-day trials on acquisition, retention, and profitability.

That being said, a user who converts on day seven and churns on day eight is not a win.

So if you’re feeling a little confused right now, that’s fair, I’ve just dismantled both extremes (sorry!). But fear not, there is an answer: trial length only makes sense in context.

Across teams, Hannah Parvaz has seen a few consistent patterns emerge:

“If the core value is experienced in one session, long trials often hurt paid conversion. In these cases, shorter trials (or even no trial at all, with strong reassurance) outperform because users either get it quickly or they never will.
“If value compounds over time (habits, learning, behaviour change), a longer trial can work, but only if the onboarding actively guides users to the aha! rather than passively waiting for it to happen.
Seven days is rarely optimal by default. It’s often too long for fast-value products and too short for slower, trust-based ones. We’ve seen better outcomes with everything from three days to 30 days, depending on how quickly users hit a meaningful milestone.”

Let’s dive deeper into that context to better understand the nuances, then we’ll outline a framework to determine the right trial length for your app.

Pricing matters for trial length

One thing that’s easy to forget when discussing trial length is how closely it’s linked to pricing and packaging.

A 14-day trial before a $5 monthly plan behaves very differently from a 14-day trial before a $120 annual commitment. In the first case, the user’s risk is low. In the second, the psychological bar is much higher: users need more proof, more confidence, or simply more time before paying feels justified.

This is why you’ll often see longer trials attached to annual plans, or trials offered only on annual pricing. It’s not about generosity, it’s about reducing perceived risk. A higher price or longer plan requires potentially a longer trial.

Headspace saw a strong conversion lift by offering a 14-day free trial with its annual plan, while offering seven days with its monthly plan. It sounds like it made users more comfortable to commit to a longer plan and helped make their annual plan more attractive.

Not only that, but with shorter subscription periods, adding a trial can almost be overkill and may even devalue your app. Weekly subscriptions, for example, already act like a trial, so you might not need another free trial on top of that. For apps that do offer a free trial with a weekly plan, they often offer only three days vs. a full week, since giving a full week free essentially devalues the subscription.

Category matters more than you think

There is no universal ‘best’ trial length (though the data would suggest leaning towards longer). When you break down trial data by category, the differences are striking:

Trial durations, by category — State of Subscription Apps 2026

Gaming apps overwhelmingly favor very short trials, often under four days. Longer trials invite abuse, with players optimising for completion rather than habit formation.

Photo & Video apps also skew short, because value is immediate; users can edit meaningful content quickly and see the tool’s benefits.

By contrast, Health & Fitness, Education, and Travel apps require more time for progress or focus on more serious commitments (e.g. booking a vacation). Trials of 5–9 days are far more common here, which helps explain why seven days became the industry default.

But common doesn’t mean correct. Hence my polite begging: please don’t default to seven days. The key principle is that trial length should align with activation time, not pricing norms or industry practices.

Engagement is the silent killer of long trials

Long trials often look good on the surface, but in reality, they’re much harder to manage. It’s a classic case of Instagram versus reality — the gorgeous holiday photo versus the food poisoning that left you bedbound.

A long trial with YNAB works because the burden shifts to the product; they actively guide users through workshops, live sessions, and a clear methodology.

YNAB’s web-to-app funnel is focused on you attending a live free workshop

The trial isn’t passive. Rather, it’s structured, and sadly, that’s rare.

For most apps, the question isn’t: “Can we get someone to try it once?” It’s: “Can we build a habit before they lose momentum?”

To do that, you need to:

Drive repeat usage
Prevent procrastination
Continuously build perceived value

I experienced this recently with GOWOD, a mobility app offering a 14-day trial. The onboarding was strong; they started with a mobility assessment, which is great (my hip mobility definitely needs some work).

But mobility is one of those things we know we should do, but rarely prioritize. A long trial made it easy to delay. I started the trial during a busy period, thinking I’d surely find time to complete some sessions.

In reality, I didn’t manage more than two in 14 days, definitely not enough to build the habit. If I’d had a clearer goal or challenge, I might have stuck to it, e.g. committing to X sessions per week for the two weeks and measuring my mobility again afterwards.

Freemium and free trials

Freemium complicates things even further. I’ve seen apps offer such generous freemium access and long trials that I honestly start wondering if they want people to pay at all.

A study by Ling Zhang and Jiang Duan, focused on a freemium SaaS company, found that longer trials increase trial starts but don’t necessarily improve conversion. If users aren’t getting enough value to pay, trial length won’t save you. But here is where the study gets interesting: longer trials did boost delayed conversion: users who had more time to test premium features come back to convert later on.

This explains why apps like Strava and Medium deliberately offer 30-day trials despite appearing ‘simple’. They’re not optimizing for immediate conversion — they’re playing a longer game.

Take into consideration the various factors that impact a lot of freemium apps:

The value of network effects: a lot of freemium apps depend on word of mouth for growth — and also for valuable data, e.g. Strava needs enough users in an area for a sport to segment leaderboards. Medium readers feed the algorithm on which content is engaging and which isn’t.
Value accrues over time: in Strava’s case, I can also imagine that many of their data features (e.g. analyzing your performance) take more than a week to appear. Freemium apps tend to be ‘slow burns’, and if you’re offering premium features only behind a paywall (vs. allowing a taster of features upfront) a longer trial may add value. The same goes for Medium, where readers build up a list of writers and content they like. This also increases the switching costs over time.

So there’s an additional layer of complexity: does a longer trial create network effects or switching costs that outweigh lower immediate conversion? For platform businesses, the answer is often yes.

If you’re freemium, the real question isn’t trial length — it’s how much value must be locked behind the paywall for paying to make sense, while still keeping free users engaged enough to strengthen the ecosystem.

The psychology behind trial length

Once you zoom out, trial length is really about psychology.

Loss aversion is the big one. Ending a trial can feel like losing something you already own, especially when users have:

Invested time
Created data
Built routines

This isn’t strictly about duration; it’s about investment. Photo editing apps can create loss aversion in just a few days. Games can do it even faster. Other products need longer.

That links closely to the endowment effect. The more effort users put in, the harder it feels to walk away. Think IKEA furniture: frustrating to build, yet weirdly hard to get rid of once assembled (unless, like me, you manage to break it while building).

But longer trials only work if investment feels natural and repeatable, not a one-off setup task, but something that builds over time.

On the flip side, urgency is where shorter trials shine. They force early engagement and reduce procrastination.

Every trial sits on a tension line:

Urgency vs. habit formation
Speed vs. depth

Usage frequency matters:

Daily-use apps can build habits quickly.
Weekly or monthly cadence products need longer exposure.

Now add cognitive load into the mix (slight psychology 101 here, but bear with me!):

Complex products require learning time
Simple products don’t — causing unnecessary friction

The simplest way to frame it is this: your trial should be long enough to form a habit, but short enough to avoid being forgotten.

A practical framework to choose your trial length

To make this actionable, I like thinking in terms of natural usage habits — a concept popularized by Phiture’s Mobile Growth Stack.

Before choosing a trial length, ask three key questions inspired by this model:

How often must users engage to experience value? Consider the balance of usage frequency and number of engagement moments. For example, with one app, helping users make five new friends vs. just one hugely improved retention.
When does the first real aha! moment happen? This isn’t the end goal (like running a marathon with Strava), it’s the point where users see clear progress, like completing the first few workouts, or achieving some measurable milestone.
What behavior must exist before paying makes sense? Identify the minimum meaningful behaviour that signals the product is valuable and worth paying for. This is the threshold where the trial converts into a paying experience.

Even then, I can’t recommend enough that you should run a test: measure both the short and long-term impact of any trial duration change. That’s why thinking through the questions above first is so important.

If you’re still unsure, here are some rough guidelines (not rules!) to help:

3–7 days: simple utilities, games, and quick-value apps
7–14 days: daily-use apps where time is needed for habit formation
14–30 days: weekly cadence tools, like a project management app, where users need 2–3 cycles to see value
30+ days: complex analytics or reporting tools, where onboarding, guidance, and meaningful data collection take time

Advanced thinking: not all users need the same trial

If you have a big enough user base, you can take trial experimentation further. Different users may benefit from different trial lengths:

Fast activators vs. slow starters
Freemium-activated users vs. cold starts
Monthly vs. annual plans (some teams only offer trials on annual plans)
Trials as part of win-back flows

The caveat: complexity only helps if you execute it well. Over-engineering monetization often creates confusion rather than clarity.

It’s also worth noting that there are App Store limitations around trial length and setup. To get fancy like YNAB, you may need a web-based trial (luckily, web-to-app is all the rage these days). Just ensure the user experience matches what users see in-app—otherwise, Apple may reject your app.

Alternatively, if you want to test extended trials for specific users, you could use promotional offers on iOS. On Android, you can defer a subscription’s expiry via code.

This kind of segmentation is typically only viable once you have strong activation signals and enough volume to avoid muddying your results.

Beyond the 7-day default

So please don’t default to seven days. While it isn’t a bad starting point for most apps, there are plenty of cases where shorter or longer trials could have a more meaningful impact.

First, decide whether a trial should exist at all, and ensure it effectively activates users. Be bold, like David, and test removing it entirely. If you test trial length, use the right measures of success: trial starts, and trial-to-paid conversion rates aren’t the full scorecard — activation, retention, and revenue are.

Next, understand your users’ psychology. Do they need urgency or time to invest? Does loss aversion play a role? Context matters, as gaming thrives on short trials, while Health & Fitness apps often default to longer ones for good reason.At the end of the day, the right trial length isn’t the one that converts the most users. It’s the one that creates customers who actually stick around.

Announcing StartApp School: Free courses from the experts who’ve scaled what you’re building

Thu, 19 Mar 2026 09:24:10 GMT

At RevenueCat, we get a front-row seat to what separates the apps that scale from the ones that stall. We see the pricing experiments that work, the paywalls that convert, and the retention strategies that keep users coming back month after month. We wanted to package those insights into something builders can learn from directly – so we’re launching StartApp School, a completely free educational resource to help you turn your app into a profitable, lasting business.

We’ve partnered with operators who’ve done this work firsthand to build practical, strategy-focused courses covering the pillars of app growth. No fluff, no theory for theory’s sake — just the frameworks and decisions that matter at each stage.

Four courses, available now

We’re launching with four courses that cover the ground where most apps either break through or break down: monetization, acquisition, retention, and product strategy.

Finding the idea worth building

Most apps don’t fail because of bad code – they fail because nobody validated whether people would pay. Daphne Tideman (Growth Advisor & Consultant) walks you through finding your niche, pressure-testing willingness to pay, and building a launch roadmap that doesn’t waste your first six months.

Turning your paywall into a revenue engine

Most apps leave serious money on the table at the paywall. Vahe Baghdasaryan (Founder & CEO, Tangent) breaks down the psychology behind when and why users pay, and teaches you how to run repeatable pricing and placement experiments that compound over time.

Acquiring users without burning your budget

Paid UA is easy to start and expensive to get wrong. Natalia Drozd (Marketing & Growth Lead) covers how to pick the right channels, build creatives that actually convert, and scale spend without watching your CAC spiral out of control.

Keeping the users you already have

Acquisition gets the glory, but retention pays the bills. Alice Muir Kocourková (Growth Consultant) teaches you how to build lifecycle messaging that converts free users, reduces churn, and wins back the ones who slipped away.

Built for people who are already busy

Each course is made up of short video lessons you can work through at your own pace – binge a full course in an afternoon or knock out one lesson over coffee. Complete a course and pass the quizzes to earn a certificate.

Test your understanding as you work through the lessons

More courses coming throughout 2026

We’re starting with four, but we’re not stopping here. We’ll be adding new courses throughout the year covering more of the problems you’re actually dealing with as you grow.

Enrollment is free and open now.

Explore StartApp School →

Have a topic you want us to cover? Tell us on Twitter or LinkedIn.

How Coconote hit $1M ARR in 4 months with no paid ads

Wed, 18 Mar 2026 13:41:04 GMT

As co-founders of the AI-powered note-taking app Coconote, Brett Bauman and Zack Hargett bootstrapped their way to $6.7M in ARR and an exit to Quizlet in under two years. In a recent episode of Sub Club, they explained the counterintuitive growth engine that got them there: a disciplined focus on organic content, a premium pricing model that built trust, and a series of small product bets that delivered huge conversion wins. It’s a playbook for anyone trying to build a durable consumer subscription business in a world where paid acquisition is no longer the default answer.

The growth engine wasn’t ads — it was creators

From day one, the Coconote team made a critical decision: they would not rely on paid ads. Instead, they went all-in on organic content, building a small, agile team of about 25 part-time content creators. Their insight was that in an algorithm-driven world, the quality of the content matters more than the size of the audience.

“The strategy wasn’t to find an influencer who had an audience,” Zack explained. “The strategy was to find a content creator who produces great content.”

They actively avoided creators represented by agencies, which they saw as a signal that the “alpha” was already gone. Instead, they looked for creators with 5-10K followers and a personal email in their bio — a sweet spot for finding raw talent. This hands-on approach allowed them to build a growth engine that was not only cost-effective but also more authentic and resilient than a traditional ad-based model.

For retention, trial extensions beat discounts

When it came to retaining users, the team tested the standard playbook of offering discounts to users who tried to cancel. But the data revealed a more powerful strategy: offering a trial extension. They found that many users weren’t canceling because of the price; they just hadn’t had enough time to fully experience the product’s value.

“We’re able to retain 25% of people from canceling,” Brett noted. “And [the trial extension] was the most successful one by far, and it really keeps people on that auto-renew.”

By offering seven more days, they addressed the user’s real objection without devaluing the product. It was a simple, non-obvious insight that had a significant impact on their conversion and retention rates, proving that sometimes the best way to keep a user is to give them more time, not a lower price.

Small onboarding changes, big conversion wins

Coconote’s growth wasn’t just about marketing; it was also driven by a relentless focus on product optimization. The team ran numerous experiments to improve their onboarding flow, and two changes, in particular, stood out.

First, they doubled the length of their onboarding to 15 screens. While this might seem like adding friction, it actually increased trial starts by 16% by giving users a more personalized and value-driven introduction to the app. Second, they moved the login screen from the beginning of the onboarding to after the paywall. This simple change eliminated a 10% drop-off from users who were unwilling to create an account before seeing the product’s value.

The takeaway

In the full episode, Brett and Zack go deeper on their pricing strategy, the psychology of building a premium brand for a student audience, and the emotional journey of navigating an acquisition while still running the business day-to-day.

Guest links:

Brett Bauman: LinkedIn, X/Twitter
Zack Hargett: LinkedIn, X/Twitter
Quizlet Careers

Apple guidelines explained: remote testing your iOS app (without getting your account banned)

Wed, 18 Mar 2026 13:00:14 GMT

If you’re a developer trying to optimize your app’s revenue, A/B testing and remote configuration aren’t just nice-to-haves – they’re how you find your edge. You need to test paywalls, tweak onboarding flows, and roll out features gradually to see what actually moves the needle

But there’s a lingering fear: If I change my app remotely without going through App Review, will Apple ban my account?

Short answer: No, as long as you understand the rules of the game

Apple isn’t against A/B testing. In fact, they offer their own Product Page Optimization tools for testing App Store assets. The key to testing safely inside your app comes down to understanding the difference between changing data and changing code – and respecting the spirit of the review process

Let’s break down what you can (and should) be testing remotely, how to do it safely, and where the hard lines are drawn

The green light: what you should be testing

The golden rule for remote testing is Guideline 2.5.2. It states that apps “may not download, install, or execute code which introduces or changes features or functionality of the app”

Notice the word code

If you are using remote config (like Firebase or RevenueCat Offerings) to change data – JSON payloads that tell your existing, pre-compiled code how to behave – you are generally in the clear. Here are the high-impact areas you should absolutely be testing:

Paywall UI and copy: changing the background color of your paywall, swapping out the hero image, or testing “Start Free Trial” versus “Subscribe Now” is perfectly fine. The code to render a button is already in the app; you’re just telling it what text to display. This is the lowest-hanging fruit for conversion optimization
Pricing and packaging: swapping which StoreKit products are shown on your paywall (e.g., testing an annual vs. monthly default, or introducing a new tier) is standard practice. As long as the products themselves are approved in App Store Connect, dynamically choosing which ones to display is safe and encouraged
Feature flags for gradual rollouts: if you’ve built a new feature, included the code in the binary you submitted to Apple (and made sure the reviewer could actually access it), and just want to turn it on for 10% of your users to monitor crash rates or engagement, you’re safe. The feature was there during review, even if it was dormant
Onboarding flows: re-ordering the screens in your onboarding flow or changing the text on those screens to better explain your value proposition is a great use of remote config. You’re optimizing the user journey using existing components

The nuance: it’s about the spirit of the review

Where developers get into trouble isn’t usually the mechanism of remote config, but what they are configuring. The most common trap is bypassing the spirit of the App Review process

Let’s look at a classic example: testing a hard paywall versus a soft paywall

A soft paywall allows users to dismiss it and use some limited version of the app. A hard paywall blocks all access until the user subscribes. Developers often want to A/B test these two approaches to see which yields higher LTV

The problem? A hard paywall fundamentally changes the nature of the app. If your App Store metadata and screenshots show a free app with optional premium features, but a remote config flag suddenly locks 50% of your users out of the app entirely, you’ve created a discrepancy

Apple reviewed and approved a freemium app. You are now delivering a paid-upfront experience. This violates Guideline 2.3.1 (Accurate Metadata) because customers don’t know what they’re getting when they download the app

It’s not the remote config that gets you rejected here; it’s the bait-and-switch. If you want to test a hard paywall, the safest approach is to submit the app with the hard paywall active for review, ensuring your App Store presence accurately reflects that experience

The red light: what will actually get you banned

While Apple is generally fine with data-driven A/B testing, there are a few lines you absolutely cannot cross. Apple’s Introduction to the guidelines is very clear: “If you attempt to cheat the system (for example, by trying to trick the review process… your apps will be removed from the store and you will be expelled from the Apple Developer Program”. Here’s what to watch out for.

The ‘Review Detection’ pattern

This is the most common fatal mistake. Developers use remote config to detect when their app is being reviewed by Apple (often by checking IP addresses or looking for specific test accounts) and show a clean, compliant version of the app. Once approved, they flip a switch and turn on aggressive monetization tactics. Apple actively looks for this, and if they catch you, your account is gone

The web checkout swap

Following the Epic v. Apple ruling, developers in the US can now link to external web checkouts. But many developers misinterpret this ruling and use remote config to swap their IAP paywall for a web checkout after review. This is a fast track to rejection for several reasons:

The ruling requires most apps to still offer IAP alongside the external link. You can’t just replace it entirely
The ruling only applies to the US storefront. If your remote config enables web checkout globally, you’re violating guidelines in every other country
Changing the fundamental payment mechanism post-review is seen as hiding functionality

The native Stripe SDK trap

Another common misunderstanding of the Epic ruling is thinking you can now use Stripe’s native mobile SDK (like Payment Sheet) to process digital subscriptions inside your app. You can’t. Apple allows a link that opens the default browser (not a WebView) to an external checkout page. If you use remote config to turn on a native Stripe checkout for digital goods, you will be rejected. If you turn it on after passing review with an app that didn’t show this checkout, you risk an account ban

Downloading executable code

You cannot download new JavaScript or native code that adds entirely new screens or functionality that wasn’t in the reviewed binary. You can change the data that populates a screen, but you can’t download the screen itself

The yellow light: navigating the grey area

Even when you’re playing by the rules, you might stumble into Guideline 5.6: Developer Code of Conduct. This guideline states that apps should not engage in “manipulative practices” to trick users into making unwanted purchases

Because “manipulative” is subjective, this creates a grey area for certain types of tests:

Exit offers: when a user tries to close your paywall, you pop up a secondary offer with a discount. Is this a smart e-commerce win-back strategy, or is it manipulative? We’ve seen apps get rejected for this under Guideline 5.6, yet many top-grossing apps do it every day
Aggressive back-to-back paywalls: showing a paywall during onboarding, and then immediately showing another one if the user declines, often triggers a 5.6 rejection

If you’re going to experiment in these grey areas, transparency is your best friend. Never try to hide your experiments from App Review. If you’re testing an exit offer, make sure it’s active in the build you submit. Use your App Review notes to explain your A/B testing setup: “We are currently running an A/B test on our paywall flow. The reviewer may see either Variant A or Variant B”

Remote testing is a powerful tool for growth. As long as you’re using it to optimize the user experience and find the right pricing – rather than trying to sneak unapproved features past Apple – you can test with confidence.

A loving note from our editor: you may have noticed this blog post is missing periods at the end of many paragraphs. Please don’t be thrown off or think we haven’t spotted this; it is simply the signature trademark of Rik Haandrikman, VP of Marketing at RevenueCat. For more of his antics, follow Rik on X (you’ll know you’ve found the right account when you stop seeing periods).

Build web-to-app funnels to convert more traffic

Tue, 17 Mar 2026 13:45:33 GMT

The path from ad click to paying subscriber is rough. Users move through app store listings, download waits, onboarding screens, and a paywall. Each step bleeds users, and by the time someone reaches your paywall, you’ve already lost most of the people you paid to acquire.

Web-to-app funnels flip this. You capture, qualify, and convert users on the web before they ever touch the App Store. But building one has always meant stitching together landing page tools, payment processors, analytics platforms, and custom code to connect it all back to your app.

RevenueCat Funnels is now in public beta, and it replaces that entire DIY stack.

A no-code builder for web-to-app onboarding funnels

RevenueCat Funnels lets you design multi-step web experiences in a visual editor, connect them with branching logic, and deploy them to a hosted URL — build and deploy without touching web development, infrastructure, or engineering queues.

If you’ve used the RevenueCat Paywall Builder, the editor will feel familiar. It’s the same drag-and-drop system, expanded into a full canvas where you connect multiple screens into complete acquisition journeys.

Here’s what the end-user experience looks like: a prospect clicks your ad, lands on your funnel, taps through onboarding screens and survey questions, hits a web checkout, and completes their purchase. They get a Redemption Link, download your app, tap the link, and their subscription is already active.

Inside the editor

You build funnels by placing steps on a canvas and connecting them. A step can be either a screen (a customizable page with text, images, buttons and surveys), a checkout (powered by RevenueCat, Paddle or soon Stripe Billing), or even your own custom authentication flow.

Connect steps with triggers like button taps or form submissions. Then layer in branching logic to personalize the journey:

Show a different offer to visitors arriving from a specific ad campaign by branching on URL parameters
Route users to different onboarding paths based on their survey answers
Detect a visitor’s country via IP and localize the experience automatically

When you’re happy with the flow, hit publish. You’ll get a hosted URL to point your ads, emails, and social posts at.

Templates get you live fast

You don’t have to start from a blank canvas. RevenueCat Funnels ships with pre-built templates you can customize. Pick one, drop in your branding, tweak the copy and flow, and publish. Going from zero to a live funnel takes minutes.

Analytics that show where the money goes

Every funnel includes built-in analytics right in the RevenueCat dashboard.

The General Metrics tab shows unique sessions, conversion rate, and revenue over time. Segment the data by traffic source, campaign, country, or other dimensions to understand which channels drive the highest-value subscribers.

The Step-by-Step Metrics tab breaks down conversion and drop-off at every step, so if users are dropping off at a specific screen, you’ll know exactly where to focus. This view is early in the beta and will get more detailed over time.

The analytics also include a customer lifetime selector, letting you measure revenue from a given day’s sessions over a defined window (day 0, 7-day, 14-day, and more). This is the same concept as Realized LTV in Charts, useful when you’re running trials and need to compare true ROI across campaigns.

Funnels captures UTM parameters (source, medium, campaign, content, term) automatically, so you can tie every dollar of funnel revenue back to the campaign that generated it.

Who should try RevenueCat Funnels

Running paid acquisition?

Build a funnel that takes ad traffic through a quiz, presents a tailored offer, collects payment on the web, and sends users to your app with their subscription already active. You keep full attribution visibility and skip app store commissions.

Growth marketer tired of waiting on engineering?

Swap screens, test different survey questions, and adjust branching logic yourself. Check results in the analytics dashboard. Ship changes in minutes, not sprints.

Indie developer without a web team?

RevenueCat hosts everything and handles checkout through Web Billing. This makes it much easier to get started.

Running influencer or campaign-specific promotions?

Create one funnel, then add a branch where visitors with a specific campaign code see a special discount or promotional content. A single funnel can serve multiple audiences by branching on campaign codes.

What’s included in the public beta

The public beta includes everything you need to build, deploy, and measure web-to-app funnels:

Visual funnel editor with drag-and-drop screen builder
Pre-built templates
Survey components (multi-select and single-select)
Branching logic based on URL params, country, browser info, and survey answers
RevenueCat Billing checkout
Paddle Billing checkout
Custom domains
Hosted deployment with a shareable URL
Redemption Links connecting web purchases to app entitlements
Analytics dashboard with conversion rates, drop-off, revenue, and customer lifetime value selector
Automatic UTM parameter tracking
Integrations with Amplitude, Mixpanel and Meta
Localization management
Autosave

Funnels is included in your RevenueCat plan at no additional fee. Purchases made through Funnels count toward your MTR, same as any other RevenueCat transaction.

What’s on the roadmap

The team is building A/B testing within funnels now. The AppsFlyer integration is on the roadmap. Stripe Billing support is coming shortly after launch. More input types like email collection and freeform text are also on the way. If there is anything missing that you’d like to see us build, we’d love to hear from you.

Get started

Here’s how to create your first funnel:

Set up RevenueCat Web with Paddle or RevenueCat Billing with a connected Stripe account
Open the Funnels section in your RevenueCat Web dashboard
Create a new funnel from a template or start from scratch
Design your screens, add branching logic, and connect a checkout step
Publish and share your funnel URL

The full setup guide is in the Funnels documentation.

RevenueCat Funnels is available now in public beta for RevenueCat customers. Open your dashboard and build your first funnel.

Firebender now supports RevenueCat MCP and OAuth

Tue, 17 Mar 2026 02:17:41 GMT

Android developers spend most of their time in Android Studio, but managing a subscription business has always required a browser. You write code in the IDE, then switch to a tab to check MRR, open another to configure offerings, and switch again to design a paywall. Each switch breaks your flow and fragments your attention. Firebender eliminates this by connecting to RevenueCat’s MCP server directly from the IDE, letting the AI agent create paywalls, manage offerings, packages, and entitlements, and query revenue metrics through conversation.

In this article, you’ll explore how Firebender integrates with RevenueCat’s MCP server, including how OAuth sign-in establishes the connection, how you manage offerings, packages, and entitlements through natural language, how AI paywall generation works end-to-end, and how you can query revenue analytics using the Charts API without leaving Android Studio.

Firebender connects to RevenueCat’s MCP server using OAuth 2.0. To get started, open Firebender’s settings inside Android Studio or IntelliJ and add the RevenueCat MCP server. Once added, you’ll see an option to sign in with your RevenueCat account.

Clicking sign in opens your browser for authorization. Firebender handles the token exchange automatically and stores your credentials securely. After authorization, the agent fetches your projects and prompts you to select which one to work with. From that point on, the agent operates within the scope of that project.

The OAuth flow requests scoped permissions for project configuration, charts and metrics, and customer information. This means the agent can read and modify your offerings, packages, entitlements, and paywall configuration, and query your revenue data, but only within the bounds of the permissions you’ve granted. Tokens refresh automatically when they expire, so you stay connected across sessions without manual intervention.

Once you connect your RevenueCat account to the Firebender, then you’ll see the result below with the available MCP tasks:

Managing your subscription infrastructure through conversation

Once connected, you can manage your entire RevenueCat project configuration through conversation. The agent supports creating, reading, updating, and deleting offerings, packages, entitlements, and products. You describe what you want, and the agent takes care of the API calls.

Creating offerings and packages

To set up a new offering with packages, you can ask the agent directly:

“Create a new offering called Premium with a monthly package at $9.99 and an annual package at $79.99”

The agent creates the offering, sets up both packages, and attaches the appropriate products. If any of these resources already exist, the agent detects the duplicates and reuses them instead of creating new ones.

You can also add products to existing packages without having to rebuild the entire structure:

“Add a weekly package to my existing Premium offering”

The agent fetches your current offering structure, confirms what’s already configured, and adds the new package without touching anything else.

Configuring entitlements

Entitlements connect your products to feature access in your app. Setting them up manually through the dashboard involves navigating through multiple screens and attaching each product one by one. Through conversation, the same setup takes a single prompt:

“Set up an entitlement called pro_access and attach it to all my subscription products”

The agent creates the entitlement, lists your existing products, and attaches each one. If some products are already attached to a different entitlement, the agent reports that back so you can decide how to proceed.

You can also set up entitlements for specific products only:

“Create an entitlement called premium_features and attach it to my annual and monthly products”

The agent handles the lookup, creation, and attachment in sequence without requiring you to provide product identifiers manually.

Querying your project

Beyond creating and modifying resources, you can ask the agent to describe what’s currently configured in your project. This is useful for auditing your setup or understanding what might be missing before submitting a build for review.

“Show me all my offerings and which ones have paywalls”

The agent fetches your offerings and paywall data and presents a summary of what’s configured and what’s missing. Offerings without paywalls are called out explicitly.

“What products do I have configured? Which ones aren’t attached to any package?”

The agent cross references your products, packages, and offerings to surface orphaned resources. Finding these manually through the dashboard is time consuming, especially as your project grows. The agent does it in a single query.

AI Paywall generation

The most direct use of the Firebender and RevenueCat MCP connection is end to end AI paywall generation. You describe what you want, and the agent handles every step: creating the offering, setting up the packages, attaching products, and triggering AI paywall generation with your app context.

A prompt like this is all you need to get started:

“Generate a paywall for my fitness tracker app targeting health conscious users”

The agent creates the supporting offering and package structure if it doesn’t exist, then submits the paywall generation job with context from your prompt. RevenueCat’s AI uses that context to generate copy, imagery, styling, and template selection suited to your app and audience.

The agent monitors the generation job in the background. When the paywall is ready, a notification appears with a direct link to the paywall builder where you can review the design and publish it. You don’t need to poll the dashboard or wait in a tab for the job to finish.

You can run multiple generation requests in sequence. The agent tracks each job independently, so you can ask for a “premium” paywall and a “freemium” paywall back to back, and both are monitored separately without conflict.

If you want to iterate on a paywall for a specific promotion or seasonal campaign, you can generate a new one based on an existing offering:

“Generate an AI paywall for my existing Premium offering. The campaign is a summer fitness challenge with a discount on the annual plan.”

The agent picks up the existing offering and package structure and submits the generation job with the campaign context you’ve described. Once Firebender generates a new paywall, you will see the result in the paywall editor like below:

Analyzing revenue with the Charts API

The agent has access to 21 chart types from RevenueCat’s Charts API, including MRR, ARR, churn rate, trial conversions, active subscriptions, new paid subscriptions, and retention cohorts. You can ask analytical questions in plain English and get data backed answers without opening a browser.

“What’s my MRR trend over the last 6 months?”

The agent queries the MRR chart with the appropriate date range and resolution, then presents the trend in a readable format. If there are notable changes in the data, you can follow up with more specific questions.

“Show me trial to paid conversion rate by week”

The agent queries the trial conversion chart with weekly resolution and returns the breakdown. You can then compare specific weeks or ask for the overall rate across a custom date range.

“Compare revenue this month vs last month”

The agent fetches revenue data for both periods and presents the comparison. This kind of quick check is useful between code reviews, before a release, or when you’re iterating on paywall design and want to see whether recent changes have affected revenue.

“What’s my churn rate for annual subscribers?”

The agent queries the churn chart and applies any available segment filters to narrow the results to annual subscribers. Segmented churn data gives you a clearer picture of how different subscription tiers are performing independently.

Because the agent can combine analytical queries with project configuration, you can move from a data question directly into action:

“My trial conversion rate dropped this week. Show me what paywalls I have live and which one is attached to my default offering.”

The agent pulls the chart data and your current paywall configuration in the same session, giving you both the signal and the context to act on it without switching tools.

Conclusion

In this article, you’ve explored how Firebender connects to RevenueCat’s MCP server through OAuth 2.0 sign-in, how you can manage offerings, packages, and entitlements through natural language conversation, how the agent handles end-to-end AI paywall generation, including job monitoring and notification, and how the Charts API integration lets you query revenue data directly from the IDE.

This changes the shape of the workflow. Checking MRR, creating a new offering for an A/B test, or generating a paywall for a seasonal campaign used to require opening a browser, navigating through the dashboard, and context switching back to the IDE. With the MCP connection in place, all of those operations happen inside Firebender through conversation. The agent carries out the API calls, monitors async jobs, and brings results back to where you’re already working.

Whether you’re launching a new app and setting up your subscription infrastructure for the first time, iterating on a paywall to improve conversion, or tracking churn after a pricing change, Firebender keeps you in your development flow. You spend less time switching tabs and more time building.

Beyond SKAN: why standard app campaigns no longer define mobile UA

Mon, 16 Mar 2026 11:22:31 GMT

For years, mobile app user acquisition (UA) was built almost entirely around SKAdNetwork (SKAN), Apple’s privacy-first attribution framework. While SKAN is still required for iOS compliance, modern app teams are now embracing web-to-app funnels, experimenting with creative testing, and exploring first-party attribution methods. UA has evolved, and SKAN is no longer its center of gravity. It’s a baseline signal, rather than a source of truth.

Today, teams are moving beyond standard app campaigns and rebuilding their campaign structures. Read on to understand the user acquisition strategy from top-performing app studios in the world, and how they run enhanced ad campaigns to make more money.

App campaigns under the hood: what isn’t working

As everyone knows, if you work with a mobile app and plan to spend money on paid ads, ad networks (Meta, Google, TikTok, etc.) offer a dedicated campaign type for advertisers to use. While each ad network has different naming — e.g. Meta and TikTok call it ‘App promotion’, while Google calls it ‘Google app campaigns’ — the goal is the same: to offer a dedicated advertising product for mobile apps looking to drive installs or specific user actions, like purchases.

For the sake of this article, I’ll refer to this type of campaign as a ‘standard app campaign’ (SAC).

SACs have been the standard way for almost every single app to run ads. They are pretty straightforward to set up, easy to understand, and designed specifically for mobile apps by sending all users to the same place: the app store product page.

Surrounding that moment, there are three crucial levers to make profitable paid ads:

Pre-app store: test new ad creatives
App store: app store optimization (ASO)
Post-app store: onboarding and paywall optimization

But, even if you successfully use those levers, SACs have four main problems that impact all app advertisers:

Measurement and attribution problems, caused by the implementation of SKAN and native models like Meta’s aggregated event measurement (AEM)
Limited reach, since most app campaigns’ inventory cannot reach what web campaigns do — based on Paddle data, there is only a 15% overlap between app campaigns and web campaigns
Limited control over ad placement and campaign types, caused by campaign automation
Retargeting constraints on iOS due to privacy limitations, which make it hard to target with precision

Because of these problems and consequences, a new trend has emerged in the last two to three years: web-to-app.

The web-to-app trend

So, what the hell is web-to-app?

A good definition is: it is a marketing approach that brings users to a dedicated web-to-app funnel before guiding them to a mobile app. Here, users complete a personalized onboarding flow, subscribe, and then install the app.

Over the past few years, more and more apps have been testing and adopting web-to-app campaigns. By doing so, some companies have come to view SACs as no longer part of their marketing strategy.

Nathan Hudson, Founder & CEO at Perceptycs, wrote a good article on the reasons web-to-app became popular:

Don’t pay any fees to Apple or Google
Get your money faster
Say goodbye to SKAN and ATT attribution struggles
Build and deploy onboarding experiments faster
Reach new audiences
More control and more customization

For these reasons, lately, many app growth teams are focused on web-to-app. And new startups have emerged offering no-code tools to build and customize your web onboarding experience.

However, as Thomas stated on the Sub Club podcast, some apps are adopting this trend for the wrong reason: just to avoid app store fees. What these apps don’t know is that web-to-app also has a set of hidden costs, like:

Managing your transactions online introduces a host of additional complexities that can outweigh the benefits for many businesses
Apps still have to pay a 3% (often higher) fee to a payment processor like Stripe
Paying for expensive third-party tools to build the web onboarding experience
Dealing with global tax compliance and legal structures
ASO rankings will take a hit because fewer people see your product page and download the app

Based on my personal experience, web-to-app can become a nightmare for apps making less than $1M a year — since they pay app stores just 15% (rather than 30% like >$1M apps), the savings are almost non-existent.

Based on this report from AppFigures, only 0.28% of new apps made more than $1M a year in 2024, which basically means — if you’re pursuing web-to-app solely for the purpose of avoiding app store fees — then for 99% of apps it doesn’t make much financial sense.

But what if there’s a middle ground? A user acquisition strategy that could combine the best of both worlds between standard and web-to-app campaigns

Enhanced app campaigns: 8 benefits

Enhanced app campaign (EACs) is a new marketing protocol we’ve developed at Appstack. They consist of web campaigns that redirect all users to the app stores, without needing a website.

Enhanced app campaigns aim to combine the top benefits of standard app campaigns with the flexibility and control of web-to-app, giving you a new way to run paid ads for your mobile app.

Standard app campaigns	Web-to-app
No impact on ASO rankings ✅	No more attribution struggles ✅
No web funnel is needed ✅	Reach new audiences ✅
No tax or legal complications ✅	More control and customization ✅

The results for enhanced app campaigns speak for themselves: looking at a dataset containing data from dozens of subscription apps, we saw an average decrease in cost per subscription of 25%, and an average decrease in cost per start trial of 20%. One fact worth noting is that, in most cases, these numbers were achieved even after increasing daily ad spending.

Enhanced app campaigns are great for apps looking to:

Expand paid reach
Improve profitability
Target B2B or specific niches
Engage older audiences
Improve attribution or seek clarity

We’ve seen great success with EACs, and it’s fast becoming the dominant way to run ads for mobile apps. Let’s break down these reasons why.

1. Superior attribution

If you believe the term ‘superior attribution’ is misleading, you are wrong. EACs genuinely have far superior attribution than standard app campaigns run through ad networks. Let me explain:

Firstly, to run enhanced app campaigns, apps only need to install the Appstack SDK. This enables running ads across multiple ad networks simultaneously with consistent measurement.
Enhanced app campaigns rely on probabilistic matching with an accuracy rate of +95%, allowing app advertisers to pass encrypted PII (Personally Identifiable Information) to improve the quality of the signal (optional), which is as good as it can be. EACs don’t rely on SKAN for iOS attribution, enabling apps to get real-time, high-precision data.
EACs rely on APIs to send in-app event postbacks (signals) to ad networks, creating a more stable and reliable way to keep the signals pipeline in the correct numbers compared to the SDK method.
Since EACs rely on ad links (tracking links), they enable data at the most granular level (ad or keyword, depending on the campaign type). This means apps can see ROAS, profit, rLTV, and many other metrics with greater precision than ever before.

Enhanced app campaigns have unified measurement, enabling apps to get the clearest picture of their app’s success. You can see the entire user history, including all engagements before and after installation — and it works with the most popular ad networks, including Meta, Google, and TikTok. It also lets apps see multiple attribution models, such as last-click, multi-touch or first-click.

2. Fast integration

All apps that use RevenueCat can benefit from a quick, easy implementation to start running enhanced app campaigns with the RevenueCat and Appstack integration.

Using RevenueCat to run EACs will help you to unlock:

A light-speed integration process: no need for developers to map any in-app events or debug to ensure that client-side events (Appstack SDK events) are triggered properly
Avoid untrustworthy data caused by poor implementation or changes to the codebase that could affect in-app events mapped by the Appstack SDK
Easily access server-to-server events like trial_converted or renewals to use them for paid ads

3. Paywall customization

Apps running enhanced app campaigns can show ad-targeted paywalls based on where your users came from, using RevenueCat targeting capabilities and paywalls.

Mobile apps can show a paywall depending on five different paid ads parameters:

Ad network (Meta Ads, TikTok Ads, Google Ads, etc.)
Ad campaign name
Ad set name
Ad name
Keyword

This opens up entirely new testing opportunities, such as:

Keeping organic users with free trials and paid ads users with hard paywalls
Showing a trial-only paywall for campaigns optimizing for trial starts
Customizing design and copy for gender-targeted or interest-targeted campaigns
Presenting higher pricing to users coming from high-intent keywords
Matching the tone and visual language of the ad, the user originally clicked

Follow Appstack’s docs to send user attributes to RevenueCat and start customizing your paywalls.

4. Campaign control

Over the last few years, ad networks have shifted towards automation. This means app advertisers have less control over ad placements during campaign setup, with the algorithm deciding where to allocate the budget.

With EACs, you can take back control and choose where your money is spent. This makes a lot of sense for apps looking to spend money on Google and TikTok Ads.

For example, on Google Ads, an EAC can let you:

Unlock search-to-app campaigns that allow apps to bid on specific keywords or search terms to acquire users. The reporting capabilities enable apps to see revenue and ROAS at the keyword level.
Run YouTube Shorts only, by selecting demand gen as campaign objective and choosing shorts as the only placement on YouTube. This enables apps with traction on Meta or TikTok to deploy the same creatives in a new channel, using the same ad format, to keep growing.

On the other hand, TikTok search-to-app is a new campaign type that allows apps to select a specific set of keywords while using the same ads. Currently, only apps running EACs can run this campaign type.

5. Expanded reach

As Daphne commented in her guide to web-to-app funnels, “Paid optimization looks very different for app campaigns compared to web campaigns. By focusing on the web, you can unlock an entirely new audience you may not have reached before.”

Like Daphne, even after working with dozens of mobile apps, I rarely see an app campaign advertised to me on Meta or TikTok. So I’m definitely in that web audience bucket!

Just like web-to-app campaigns, EACs unlock a new inventory of potential users. This is great for apps of all sizes. Either because their current audience is not performing well, or because apps are saturating an audience and need to look for new users.

6. Retargeting

If you thought that retargeting on iOS was dead in 2026… well, you were right. But EACs are bringing it back. The question is: how is it possible now, given that before everyone said running retargeting campaigns on iOS after the end of IDFA was no longer viable?

The enhanced app campaign protocol allows sending enriched signals to the ad network, which can be used to create custom audiences for retargeting.

For example, these are some of the parameters that the signal includes (data encrypted), which EACs send to Meta for campaign optimization:

Email
Phone number
First name
Last name
Date birth
IP address
User agent
Browser ID
External ID
Zip code
City
State
Click ID

As you can see, there are many parameters that help Meta (and the other ad networks) to identify the right users.

Using these retargeting capabilities, you can leverage EACs to:

Use custom audiences as an exclusion to avoid showing ads to users who already have your app
Reduce the CPM and ad frequency
Launch retargeting campaigns for users who installed the app but didn’t complete the target event, such as a purchase or sign-up (highly recommended for e-commerce or gaming apps!)

7. ASO friendly

Everyone knows that most users only install the app that ranks between the top three results after a search.

So investing money in ads through web-to-app campaigns means you are also investing in minimizing your chances of improving your ranks and getting more app reviews, because fewer users see your product page.

Since EACs redirect users directly to the app store and let everyone install the advertised app, you won’t be hurting your ASO efforts.

This is a strong point for small- to medium-sized apps considering the web-to-app option, given better measurement capabilities.

8. Zero overheads

I know how hard it is to actually make a living out of a mobile app. So imagine adding extra responsibility and problems to it. EACs are built so apps focus on what matters most for your business in 2026: actually reaching customers.

There’s three key benefits to EACs for your UA strategy:

Frictionless: apps remove the need for a website and maintain it; saving money.
Smart economics: incremental revenue without the need to implement third-party services like an onboarding builder or new payment provider. With EACs, apps don’t need to change their existing stacks; they pair easily with what’s already in place.
Operational efficiency: Eliminate the need for web funnels, global tax compliance, and legal structures. Since all users are redirected to the app stores, users use the app stores’ payment systems.

Sounds good, right?

Key takeaways

Enhanced app campaigns equip apps with an infrastructure that runs quickly and helps apps focus on optimizing the two most important things: ad creatives and their actual product (including onboarding and paywall optimization).

The good news is that, technically speaking, every company can build an infrastructure like this, giving them total control over their own data, vendor independence, and a strong moat that few app companies can achieve. (However, it’ll be fairly expensive, so — even if I’m biased — I’d recommend looking at Appstack’s SDK to get started.)

To wrap up, here are the main things to remember:

Standard app campaigns are structurally broken: attribution is unreliable, reach is capped, and automation removed real control from advertisers
Web-to-app has underlying complexities that most apps ignore, and can cause ASO damage
Enhanced app campaigns fix the real problem: they restore device-level insight without adding web funnels, fees, or compliance overhead
EACs give advertisers back what automation took away: control over targeting, placements, keywords, and retargeting
Winning apps will not out-hack SKAN or dodge fees; they will own their data and optimize creatives and products with clarity

The Turkish government now pays 50% of your RevenueCat bill

Thu, 12 Mar 2026 15:07:01 GMT

Every so often, a government does something that makes the entire app industry sit up and take notice. We saw it with the Digital Markets Act in the EU, and we’ve seen it with the ongoing antitrust debates in the US. But it’s rare to see a government step in not to regulate, but to accelerate.

That’s what’s happening in Türkiye right now. And it’s a big deal.

As of January 1, 2026, a new presidential decree (No. 10962) has gone into effect, completely overhauling the country’s support for service-based exports. While some of these supports have been around for a while, this new decree consolidates them, simplifies the rules, and in many cases, massively increases the amount of money developers can get back.

And the big news for RevenueCat users? RevenueCat is now on the official “approved software” list, which means if you’re an eligible Turkish company, you can get 50% of your RevenueCat subscription fees reimbursed by the government.

This isn’t just another tax credit. It’s a direct subsidy on the cost of growth. Let’s break down what’s changed, and why it matters for developers both inside and outside of Türkiye.

Bigger, better, simpler: what’s new in 2026

For years, Türkiye has offered support to its IT sector. But the old system (under Decree 5447) was a complex web of tiered limits and inflation-adjusted caps. The new Decree 10962 sweeps that away in favor of a simpler, more generous framework. The support rate is still 50% for most programs, but the annual limits have been substantially increased across the board.

Here’s a quick comparison of the old vs. new annual limits for a typical app developer:

Support Program	Old Decree 5447 (2024 limits)	New Decree 10962	Change
Software License	50%, ~1.83M TL/yr	50%, 2.5M TL/yr	+37%
Platform Commission	50%, 2.5M TL/app (top 3), 600K TL/app (rest)	50%, 4M TL/app (all 10), 20M TL total	~70% effective increase
Digital Product Promo	50%, 10M TL/app (top 3), 1.2M TL/app (rest)	50%, 15M TL/app (all 10), 50M TL total	~50% per-product increase
Hosting	50%, 1M TL/yr	50%, 5M TL/yr	5x increase
General Marketing	50%, ~11M TL/yr	50%, 25M TL/yr	~2.3x increase

Two changes are particularly massive:

The end of tiered limits: Under the old system, support for platform commissions and marketing dropped off a cliff after your first few apps. Now, every app (up to 10) gets the same high per-product cap. This is a huge win for studios with a portfolio of apps.
Huge cap increases: The total amount you can claim for platform commissions has nearly doubled, and the hosting support has gone up 5x. This is a direct injection of capital into the growth loop of an app business.

RevenueCat is now on the approved software list

The Software License Support program isn’t new, but our inclusion on the approved list is. As of the latest update to the “Desteklenen Yazılım Lisansları Listesi” (Supported Software Licenses List), RevenueCat is now officially included.

What this means is simple: If you are an eligible Turkish company, you can now get 50% of your RevenueCat subscription fees reimbursed by the government.

This fundamentally changes the ROI of using RevenueCat for Turkish developers. The best-in-class infrastructure for managing subscriptions, analyzing data, and running experiments now comes with a 50% government-funded discount. It makes the decision to build, measure, and grow your app with proper tooling a no-brainer.

It’s about more than just a discount

Getting 50% back on your RevenueCat bill is great. But the real power here is how these incentives work together. The Turkish government isn’t just giving you a discount on tools; it’s subsidizing the entire engine of your app’s growth.

Think about it:

You use RevenueCat to manage your subscription infrastructure and get a single source of truth for your revenue data
The government reimburses you for 50% of your RevenueCat subscription under the Software License Support program
You use RevenueCat’s charts and analytics to create the reports you need to claim 50% of your App Store and Play Store commissions back from the government
You use RevenueCat’s Experiments and Paywalls to optimize your pricing and increase conversion, growing your top-line revenue
You take that extra revenue and the money you got back from commissions and reinvest it into user acquisition, knowing the government will reimburse you for 50% of that marketing spend

This is a virtuous cycle. RevenueCat becomes the system of record that not only helps you grow faster but also unlocks the government funding to fuel that growth. The data you need to claim your commission and marketing reimbursements is right there in your RevenueCat dashboard.

How to take advantage of this program

If you’re a developer in Türkiye, you’re probably wondering how to get started. The program is administered through the Ministry of Trade, and requires membership in the Service Exporters’ Association (HİB) and applications via the Destek Yönetim Sistemi (DYS).

Navigating government programs can be complex, but the opportunity is too big to ignore. To make it easier for local developers, we’ve been working closely with our partners in Istanbul, Neon Apps. The Neon Apps team provides free, local-language support to RevenueCat users, and they have deep expertise in helping Turkish companies navigate these incentive programs. If you’re a RevenueCat customer in Türkiye and want hands-on help to make sure you’re getting every lira you’re entitled to, get in touch with us and we’ll connect you with the team at Neon.

The future is bright for Turkish apps

This new decree is a clear signal that the Turkish government understands the power of the app economy and is willing to make serious investments in its growth. For developers in Türkiye, it’s a golden opportunity to scale faster and more profitably than ever before. For the rest of us, it’s a fascinating development to watch – and a reminder that the next great app can come from anywhere.

We’re incredibly excited to be a part of this new chapter for the Turkish app community and to help them build the next generation of globally successful apps.

From spite-driven development to community-powered success

Wed, 11 Mar 2026 18:47:43 GMT

What happens when you get laid off from your dream job at Disney? If you’re Adrian Eves, you take some advice from Paul Hudson, add a dash of spite, and finally launch the indie app you’ve always talked about making.

In the latest episode of Launched, host Charlie Chapman sat down with the developer and community organizer to discuss his journey from working on Apple’s accessibility team to building apps rooted in his own life. His story is a candid look at the messy, non-linear, and deeply rewarding path of an indie creator.

The push you didn’t know you needed

For years, Adrian was the developer who was going to ship an app. “Oh, I’m going to do it this year,” he’d say. But it took an unexpected layoff from Disney to turn the idea into a reality. Feeling “pretty mopey,” he got some crucial advice from a friend. “Paul [Hudson] said, ‘At the very least, you need to make an indie app so that way you always have something you can fall back on.’”

That conversation was the spark. The problem to solve came from his own life: a chaotic jumble of Apple Notes trying to track his child’s health data. “I kept getting lost in all these notes that my partner and I would share,” Adrian recalls. “I was like, ‘My child who’s like three years old, I know she’s not like 11 inches.’ So that’s like an old note.” That frustration became PediaPal, a health hub for kids and his first real foray into indie development.

The bet that built an app in a month

After the emotional rollercoaster of launching PediaPal—and the subsequent letdown of not getting featured by Apple after a massive redesign—Adrian found a new, more potent form of motivation: spite.

“Paul encouraged me to get into something he called spite driven development and I made a second app out of it.”

This time, the problem was even more personal: managing his chronic, debilitating migraines. He needed a tracker that was effortless to use in a moment of intense pain. The idea for Auralog was born. But it was a friendly challenge that got it over the finish line. “One of my friends issued a challenge and they said they bet that I couldn’t release my app in a month,” Adrian laughs. “The stakes were real high. Let me tell you, it was ice cream.”

He won the bet. By focusing on a single, search-driven problem and designing for a moment of extreme user need (the core feature is a giant “Save Now, Log Later” button), Auralog quickly found traction and became his first project to generate meaningful, growing revenue.

Building spaces for others to succeed

Adrian’s story isn’t just about apps; it’s about the community that surrounds them. He’s a natural organizer, driven by a desire to pay forward the support he’s received. “This community has given me so much,” he says. “It would not be right to be like a dragon and hoard a bunch of gold.”

From helping run iOS Dev Happy Hour to co-founding CommunityKit—the unofficial “glue” of WWDC week—he creates spaces for developers to connect and learn. Now, he’s channeling that passion into his own conference, Swift Sonic, a music-festival-inspired event with a unique twist: pairing veteran “headliner” speakers with first-time “opener” speakers.

It’s this commitment to building up others that defines his journey. Adrian Eves’s story is a powerful reminder that indie success isn’t just about shipping features or hitting revenue goals. It’s about solving real problems, learning in public, and building relationships that lift everyone up.

RevenueCat now integrates with Appstack

Wed, 11 Mar 2026 05:23:02 GMT

Running paid acquisition without connecting it to subscription revenue means flying blind. Attribution data lives in one tool, subscription events in another, and the relationship between your ad spend and actual LTV stays murky. RevenueCat’s new Appstack integration closes that gap.

Using RevenueCat’s Appstack integration

With the Appstack integration you can:

Send RevenueCat subscription events directly to your Appstack webhook endpoint (optional).
Attribute subscription revenue to campaigns tracked by Appstack using the Purchases SDK.
Identify users in Appstack using the $appstackId subscriber attribute.

Integrating with Appstack requires that Appstack SDK is installed in your app. Refer to the Appstack developer documentation for the latest installation instructions.

1. SDK attribution mapping

A single call — setAppstackAttributionParams() — pulls attribution data from the Appstack SDK and forwards it to RevenueCat. Under the hood, it sets $appstackId, campaign attribution attributes ($mediaSource, $campaign, $adGroup, $ad, $keyword), click IDs, and device identifiers. No need to call collectDeviceIdentifiers() separately.

The call also syncs attributes to the RevenueCat backend and fetches fresh offerings before returning. That means by the time the callback fires, your paywall is already reflecting the user’s Appstack targeting data.

Set the following attributes after configuring the Purchases SDK and before the first purchase occurs.

This is enough for RevenueCat to start storing attribute subscription revenue information from Appstack.

Keep in mind that AdSupport framework is required to collect the IDFA on iOS.

2. Subscription lifecycle event forwarding

The Appstack integration uses a reserved subscriber attribute to associate RevenueCat events with users in Appstack if the integration is configured to send events. Event forwarding supports following properties:

Includes Revenue	Supports Negative Revenue	Sends Sandbox Events	Includes Customer Attributes	Sends Transfer Events	Optional Event Types
✅	✅	❌	❌	✅	❌

Configure Appstack in the RevenueCat dashboard under Integrations → Attribution → Appstack. You’ll need your webhook URL and an authorization header from Appstack.

Once set up, RevenueCat forwards the full event suite. This lets you measure subscription revenue and LTV from your acquisition campaigns in Appstack, rather than just top-of-funnel installs. Following events are sent to Appstack

Initial Purchase
Renewal
Cancellation
Uncancellation
Non-Renewing Purchase
Subscription Paused
Expiration
Billing Issue
Product Change
Transfer
Subscriber Alias

Get started today

Integrate RevenueCat with Appstack for attribution and targeting to get a clear picture from ad click to paying subscriber to long-term LTV. The integration is live now on iOS and Android SDKs, available for all apps from the Attribution section of your RevenueCat dashboard. Check out the full docs

Inside the product org at RevenueCat

Mon, 09 Mar 2026 12:42:53 GMT

RevenueCat’smission is to help developers make more money. Our CEO, Jacob, reminds us in every biweekly all-hands meeting that we do this by “building a winning team” and “shipping and selling stuff that helps developers make more money”. The latter, shipping stuff, is the remit of Engineering, Product & Design (EPD), and one of the three pillars of the winning team is our team of product engineers.

That product team currently consists of five product engineers, with several roles open and more to be hired over 2026. So I want to share a bit more about what it’s like to be a product engineer (PE) at RevenueCat, what it takes to be a successful PE here, and what challenges we’re facing.

What makes the RevenueCat product special

There are many products you could work on as a product person, from consumer products everybody knows (including your parents!) to niche products that baffle anyone not privy to the specific industry. RevenueCat definitely falls into the second category, but nonetheless, it’s a very special product.

Obscure problems, meaningful impact

One of the defining features of RevenueCat is that we’re solving really complex, somewhat-arcane problems. Understanding what each field in an in-app purchase payload represents, what edge cases exist across Apple, Google, and Stripe, and how to best handle them is complicated and rarely glamorous.

We often say we eat pain for a living — meaning, we solve painful infrastructure problems so developers don’t have to. That alone would make RevenueCat a complex product to work on. But what makes it meaningful is the reason behind all that work: we help app developers monetize their apps, because…

We believe that more software is (when averaged out), a net good for the world
We believe that allowing people to create software and make a living from that is the best way to help humanity create more software

If you buy into these beliefs, then RevenueCat is a great product to work on, because the problems we solve help tens of thousands of developers monetize their apps.

Many of us at RevenueCat come from app backgrounds and/or still have indie apps on the app stores. We relate to the problems we solve and the value we bring to the industry, simply because we’ve been in the shoes of our customers. That makes us unique.

A product loved by its customers

RevenueCat is a product with many fans. Not every customer is a fan, of course — some have legitimate gripes with the product, and for some it’s just a tool for their day-to-day work. But we have many customers who really love the product, because they see us enable them to get paid doing what they love: building apps.

Whether it’s meeting customers at conferences who seek our booth out to talk about the app, or people coming to App Growth Annual, it’s wonderful hearing people love the product you work on. We regularly see customers proudly post on social media about their first RevenueCat invoice — this means they’ve crossed the threshold of our free plan and are now making real money from their app. There aren’t many products customers are so happy to pay for!

The bill we all want to pay — and paying it is an achievement for mobile developers. Our first invoice paid to RevenueCat! pic.twitter.com/pThxeErMcN
— Camilo Peñalver (@camilopenalver) October 28, 2025

This kind of feedback makes working on RevenueCat extremely rewarding, and also provides that motivation to help customers who run into issues.

Aligned business-customer incentives

Speaking of first invoices, one of the best features about RevenueCat and its business model is how it aligns our incentives with those of our customers. We charge customers a percentage of their revenue. This means that when they grow, we grow. When they make money, we make money.

There is almost no purer business model. We want our customers to succeed because we will, too. Our incentives and the incentives of our customers are perfectly aligned. This makes decisions about the business viability of product choices much easier.

A few years ago, we decided to simplify our pricing structure so every customer gets access to all features, regardless of whether they’re on the free tier or an enterprise plan. We can do this because our revenue scales with our customers’ revenue anyway, so naturally, bigger customers will pay us more. We also believe that everyone should be able to benefit from the growth tools we provide. If we limited access to those tools to smaller developers on a cheaper plan, we would be limiting our own growth potential.

Different surface areas and challenges

The last distinct characteristic of the product that I want to highlight is the different surface areas we have; all of which come with their unique (technical) challenges.

Backend: our backend is critical infrastructure for our customers. We need to prioritize reliability to ensure we don’t jeopardize our customers’ revenue streams, and we need the backend to be ultra-scalable. Our backend processes billions of API requests every day. Our most used API endpoints need to be fully cached or our database would be a smoldering wreck in an instant.
SDKs and APIs: these need to be designed in a way that they remain stable for years to come, since developers will build their apps and backends relying on them. For the SDKs in particular, the quality bar is extremely high, because a buggy SDK that gets implemented by a developer could be out in the wild for a very long time if someone installs an app using that SDK and never updates it.
Web dashboard: here we have a much higher degree of freedom to innovate and iterate quickly, and therefore deploy changes extremely rapidly.
Consumer-facing UI: recently, we’ve shipped more and more consumer-facing UI: our paywalls, customer center, web checkout, and web customer portal are all used by our customers’ customers and therefore need a high degree of polish in order to inspire trust.

How we approach product work

Our approach to product work is shaped by our values as well as our talent vision.

Product engineering, not product management

We recently made the decision to change the roles from product managers to product engineers, and folded product engineers into the engineering org. In a world where AI assisted development is making writing code less of a bottleneck, product and engineering need to move even closer together: product people can ship changes to the product without involving a software engineer, and when writing code no longer becomes the main task of software engineers, they need to show greater product sense and judgment in order to be successful. It also means a greater need than ever for product people and software engineers to be aligned and walk in lock step, and this role change is strengthening that alignment.

Deciding what to build

Every year, we decide on a product strategy. The product strategy determines the main focus areas for the coming year. In general, the yearly product strategy is an evolution of the one that came before it, rather than a revolution or radical pivot. The strategy is set at leadership level, and PEs provide critical input as it is being shaped.

In line with the strategy, we also revisit our team setup. We have relatively stable cross-functional teams where a PE works together with a team of engineers, reporting to an engineering manager (EM), as well as a designer.

The roadmap is mostly determined in our quarterly planning process. We’ve gone through a number of iterations of this process over the years. Currently, the process is as follows:

Each team, represented by its PE, EM and designer, proposes a set of priorities for the team These are then reviewed and discussed with leadership (CEO, CTO, Head of Product). There can be some adjustments to the roadmap in these discussions, but by and large, the teams own their roadmap and prioritization. Product engineers play a pivotal role in this process — often, they are the ones who have the most holistic view of their product area and the value that we can deliver to our customers through product improvements.

On a day-to-day and week-to-week basis, product managers work closely with their EM and designer counterparts, with at least weekly meetings and even more frequent interactions via async communication. The discovery and delivery of features in the team is owned by the whole team, and achieved through tight collaboration.

Living our values in the product team

As mentioned, the other aspect that shapes our approach to product are the company values. These aren’t a list of values stuck in a Notion doc and forgotten about, they’re an ethos we actively work toward and measure ourselves against.

Customer obsession

At RevenueCat, we believe in focusing on delivering value to our customers above everything else. This means several things:

PEs are expected to talk and interact with customers frequently: this includes 1:1 conversations and research calls, but also support tickets, social media posts, sales conversations, shared Slack channels with customers, conference booth chats, etc.
- There is no barrier between PEs and customers: if a conversation is going to help you make a better product decision, just set it up
Customer anecdotes are often the most convincing way to argue for product decisions at RevenueCat. Of course, we don’t blindly build everything that customers ask for, but we try to find the underlying needs and problems. Generally, we believe that if a customer cares enough about the product to tell you their issues and unsolved problems, it’s wise to listen.
Teams will be attentive to customer needs, regardless of problem scale — even the small issues that bug our customers. Our strategy is important, our roadmap is important, but if we can show a customer we care by quickly fixing a bug they encountered or removing a limitation they ran into, that will often make their day and turn doubters into fans (or fans into evangelists).

Always be shipping

Always be shipping impacts our approach to product by pushing us to reduce the scope of whatever we are planning to the MVP version. There’s a couple reasons to do so:

It means delivering value to customers more quickly
It allows us to get feedback and validation from customers as early as possible

Shipping goals

One way of forcing us to truly always be shipping and minimize scope is setting internal deadlines.

When we have set such a shipping goal, we’ll do everything we can to ship it by the internal deadline, like adding resources to allow the team to go faster. It often also forces us to make painful scope cuts, where we reduce some aspect from a ‘must-have’ to a ‘nice-to-have’ (which, if you know anything about software development, more often than not means it won’t actually get done).

What frequently happens is that once we launch a feature and get it into customers’ hands, the first requests we get aren’t for the thing we deprioritized, but for something completely different. This proves the value of shipping quickly: neither us nor our customers are good at predicting how they will actually interact with a feature once it’s actually live in the product. The only reliable way to determine that is to ship fast and iterate after.

Bias for action

One other aspect of always be shipping is our bias for action. We’re always acting with imperfect information. If we waited for perfect information, we would never make any decisions. Therefore, as product engineers, we’re responsible for pushing decisions forward, even in the face of uncertainty. It is rare that decisions can’t be corrected later on, so moving forward beats endlessly deliberating. Act, don’t talk.

Own it

Ownership is very important at RevenueCat. For product engineers, it means that nothing is someone else’s problem. We all win together, we all lose together. If you notice a problem, do something about it — even if it’s not your area.

Of course, that doesn’t mean that PEs have to fix all problems. However, since they’re often the ones with the broadest, most end-to-end understanding (from customer problem to solution design to technical approach), they’re often the ones who are best positioned to notice problems (and are expected to do so).

RevenueCat product engineers also have high agency, meaning we believe in their ability to affect change even in adverse conditions. Our PEs will do everything they can to address the problems they see, and sometimes even a bit more than that (i.e. learn something new to better solve problems). They dig through the code base to see if they can find the root cause of a bug, they query our data warehouse to better understand our data, or they get on a call with a customer on short notice to debug their issues.

AI-assisted development also means that product managers are now making contributions to our code base on a somewhat regular basis. In cases where the changes are straightforward, it is often significantly faster for a PE to make a change directly via Cursor or Claude Code and get it reviewed and shipped, versus writing a ticket for an engineer to pick up.

TL;DR: there’s a lot going on, and it’s all hands on-deck.

Balance

Our balance value is perhaps the most misunderstood — it doesn’t mean we’re slacking off (on the contrary, RevenueCat is still a startup and working here is deliberately intense). We only win if we continue to move fast.

However, our balance value reminds us that there is a fine line between moving fast and burning out. Hard work can be extremely rewarding if we are working on interesting problems with teams of highly-motivated people. PEs are often pivotal in upholding the motivation and interest level of the team; it’s their job to connect the problems we’re solving with the customer impact, e.g. sharing customer ‘good feels’ and showcasing contagious excitement.

Our balance value also covers being empathetic and kind toward others, and building a cohesive team environment where there’s mutual trust and appreciation of everyone as a human being. Product engineers, as natural leaders, can play a key role in modeling and facilitating these behaviors.

RevenueCat’s talent vision

RevenueCat’s talent vision is to build a winning team of high-caliber team members. This means that we have a high standard for all team members, which we uphold through our hiring and performance management processes.

There are a few implications of that on our approach to product work. Firstly, our teams consist of relatively senior and product-minded engineers and engineering managers. This means that PEs at RevenueCat generally need to be less in-the-weeds in managing projects, creating super detailed tickets, etc. Instead, they need to be better at communicating the necessary context and understanding of the problem space, in order for engineers to not get bottlenecked by PE decision making.

It also means that our team is rather lean. We believe that smaller teams of high-caliber people can move much faster than bigger teams with a lower talent bar.

The main challenges our product team is facing

Here are some of the main challenges that we face as product engineers at RevenueCat.

Too much to do, too little time

This might be the quintessential startup issue, and it’s definitely true at RevenueCat: we always have more ideas, and more customer problems to solve than we have the capacity to work on. This means that as a company, as individual teams, and as PEs, we have to prioritize well, and be able to communicate that prioritization to the market, to customers, and to internal stakeholders. We solve this through our strategy and planning process to make sure we continuously focus on the highest-impact opportunities.

Balancing customer obsession and strategic priorities

Related to the need for prioritization outlined above, we’re often drawn in different directions by our customer obsession value and our strategic priorities. Strategic projects can take a while before showing impact, and our customer obsession value makes us consider smaller customer requests with urgency. Getting drawn to either extreme is not great: if we deprioritize customer feedback completely to focus on long-term strategic priorities, we will seem unresponsive and risk losing the customer love we’ve built up. On the other hand, if we only prioritize being attentive to customer feedback, we miss out on big swings, following the market, or unlocking the next big opportunities for the product and the company.

Growth means increasing coordination

RevenueCat has shown a great growth trajectory over the past few years. We have grown our team less quickly than our revenue (part of the winning team talent vision), but we still have grown and are planning to continue to do so. A bigger EPD team means more capacity to improve our products, but it also means increased coordination needed. Doubling our engineering team doesn’t mean we can ship twice as many changes, since some of that capacity will need to go toward coordinating work. Plus, adding more teams increases the risk of building experiences that are inconsistent between different corners of the product (which again requires coordination to prevent).

Becoming a multi-product company

The biggest strategic challenge we have in front of us is moving from a single-product company to a multi-product company. RevenueCat has long been the best way of adding in-app purchases to your app. This means that a large proportion of subscription apps on the app stores launch with RevenueCat today. However, the market of new subscription apps is limited.

To keep growing, we need to both be able to provide more value to our existing target market, and sell to customers for which the current RevenueCat product is not a good fit. Both of these require becoming a multi-product company: either adding completely new products or unbundling our existing product into pieces that can be sold separately.

We’re planning both, and that means fundamentally changing the process for how we make product decisions. We need to build experiences that make sense when you are using only part of the platform. We need to set up pricing and billing models. We need to conceive onboarding flows that find the right product and set it up.

We are only at the beginning of this journey, and it will keep us busy for the foreseeable future.

What makes for a good RevenueCat product engineers

Still with me? Okay, let’s jump into what makes a good fit for product engineers at RevenueCat. Maybe you’re the right fit, or perhaps you know someone who is?

Builders, not managers: RevenueCat PEs see themselves as product builders. We don’t manage backlogs or juggle stakeholders — we collaborate, advocate for the best solutions, and help our teams move faster.
Missionaries: Our mission is to help developers make more money, and PEs embrace that fully. We’re customer-obsessed because we believe more software is good for the world, and thriving developers means more software.
Extreme ownership: RevenueCat PEs do everything it takes to solve customer problems and make the product successful. They don’t point fingers, blame others, or accept failure; they find a way forward while contributing as true teammates and carrying shared weight, rather than being a lone wolf.
Decisive with imperfect info: In a fast-paced startup, PEs gather just enough information to make a decision quickly. They act based on current data, commit to the action path, and rally the team, but stay open to changing course if needed when new information arrives.
Deep technical understanding: RevenueCat meets multiple personas, but at its core it’s a developer tool. PEs need to have deep technical knowledge and be able to explain and evaluate decisions about APIs, distributed systems, SDK constraints, and data models.
Strong asynchronous communicator: As a globally remote team, RevenueCat PEs excel at clear async communication — whether through docs, Looms, or FigJams — and they know when to switch to real-time conversations to keep the team aligned.

We’re hiring!

We’re almost constantly growing the product engineering team at RevenueCat. If you’re a builder who loves solving hard problems with meaningful impact — and you want to help tens of thousands of developers make a living doing what they love — we’d love to talk. Check out our open roles on our careers page!

Exit Offers in RevenueCat Paywalls

Fri, 06 Mar 2026 21:07:45 GMT

RevenueCat Paywalls offer a powerful feature for earning the business of more price-sensitive users: exit offers. With exit offers you can present an alternative offering, usually a discounted plan, to users the moment they dismiss a paywall, giving you a second chance to convert a user who might otherwise be lost.

This is a common and effective strategy used in e-commerce to reduce cart abandonment, and it is a valuable capability for mobile app developers. However, the implementation of such offers on the App Store has been a topic of much discussion and some confusion. In this post, we’ll walk you through how to use Exit Offers, discuss the potential for App Review issues with Apple, and provide our recommendation on how to proceed.

What are Exit Offers?

An exit offer is a secondary offer you present to a user when they attempt to close your primary paywall without making a purchase. Instead of simply losing a potential subscriber, you can present them with an alternative, such as a lower price, a longer trial, or a different subscription term.

For example, if your main paywall promotes an annual plan, your exit offer could be a monthly plan. This allows you to capture users who may have been interested but were not ready to commit to a full year.

How to Implement Exit Offers with RevenueCat

We’ve integrated Exit Offers directly into the Paywall Builder in the RevenueCat dashboard, so you can enable them without any code changes. When editing a paywall, you can now designate another one of your offerings to be presented as an exit offer.

This makes it easy to experiment with different win-back strategies and measure their impact on your conversion rates and revenue.

An important implementation note is that exit offers only work when using the presentPaywall or presentPaywallIfNeeded functions that display paywalls in iOS and cross-platform SDKs. On Android, they are automatically enabled when utilizing the PaywallDialog and PaywallActivity classes.

Crucially, exit offers will not work if you manually embed paywall views or components directly into your UI (e.g., PaywallView, Paywall composable, <RevenueCatUI.Paywall> component, etc.). Full details can be found in the paywalls documentation.

A Note on Apple’s App Store Review

While exit offers are a standard practice on the web, their use on the App Store has been inconsistent. Some developers have reported that their apps have been rejected for using them, with Apple’s App Review citing Guideline 5.6 – Developer Code of Conduct. This guideline states that apps should not engage in “manipulative practices” to trick users into making unwanted purchases.

The rejection messages are often similar to this one reported by a developer on Reddit:

“The app attempts to manipulate customers into making unwanted in-app purchases. Specifically, your app still displayed an additional discount offer when we attempted to exit the subscription page.”

Here’s what Apple’s App Review Guidelines explicitly say in Guideline 5.6:

Apps should never prey on users or attempt to rip off customers, trick them into making unwanted purchases, force them to share unnecessary data, raise prices in a tricky manner, charge for features or content that are not delivered, or engage in any other manipulative practices within or outside of the app.

This has created a gray area for developers. The guideline itself does not explicitly forbid exit offers, and the term “manipulative” is subjective. Many popular apps currently use exit offers, yet some App Reviewers do seem to be rejecting apps based on this guideline.

Note that we have not heard any reports of rejections from developers submitting Android apps to the Google Play app store. As of this writing, exit offers seem to be in compliance with Google Play Policies and Guidelines.

Our Recommendation: Try on Android but be careful on iOS

At RevenueCat, we believe that a well-implemented exit offer is a legitimate marketing tool that can provide value to users by giving them more options. However, given the current ambiguity and the risk of rejection from Apple’s App Review, we advise developers to use this feature at their own risk for their iOS apps.

It is worth trying on your Android apps to see how it impacts your conversion before running the risk on iOS. You can use RevenueCat’s Targeting feature to only send paywalls with exit offers to your Android users.

DO NOT try to trick App Review

We want to be very clear on this point: you absolutely should not attempt to circumvent App Review by remotely enabling this feature after your app has been approved. This is a direct violation of the Apple Developer Program License Agreement and could result in the termination of your developer account. The risk is not worth the reward, we promise.

Conclusion

Exit offers are a powerful new tool in your monetization arsenal. They can help you recapture lost subscribers and increase your revenue. However, the current App Review landscape means that you must be cautious when implementing them.

We will continue to monitor the situation and provide updates as we learn more. We encourage you to be prepared for a potential rejection if you use this feature and to have a plan to address it. We look forward to hearing about your experiences with exit offers and App Review.

What Google Play’s new merchandising and optimization page means for Android developers

Thu, 05 Mar 2026 23:35:13 GMT

Most Android developers think about monetization in terms of what happens inside their app: launching a billing flow, presenting a paywall, handling purchase results. But Google Play also merchandises your products outside your app, recommending them to users on store surfaces, in notifications, and during the browsing experience. These out-of-app surfaces drive purchases that many developers never actively manage. Now, Google is consolidating three separate merchandising features into a single ML-driven page, and there is a hard deadline to prepare.

In this article, you’ll explore what the three existing out of app merchandising features are and how they work, what Google Play is changing by unifying them into the new Merchandizing and optimization page, the timeline and March 16 cutoff that affects your existing configurations, special considerations for each feature during the migration, concrete steps you should take before the deadline, and how out of app purchases connect to your billing stack.

Background: How Google Play merchandises your products outside your app

Before diving into what is changing, it is important to understand what Google Play already does to promote your products beyond your app’s own UI. Out-of-app merchandising is significant because it reaches users who are not currently inside your app. A user browsing the Play Store, receiving a notification, or exploring related content may encounter your products without ever opening your app first. This creates an additional acquisition and conversion channel that operates independently of your in-app purchase UI.

There are three distinct features that handle out-of-app merchandising today, each configured separately in the Google Play Console.

Purchase flow recommendations

Purchase flow recommendations allow Google Play to suggest your products to users as they browse the Play Store. When a user is exploring apps, viewing related content, or navigating purchase surfaces, Google Play can display your in-app products or subscriptions as recommendations. These suggestions are based on the user’s purchase history, browsing behavior, and contextual signals.

You configure purchase flow recommendations by selecting which SKUs are eligible for promotion and optionally targeting specific countries. Google Play then decides when and where to show these recommendations to relevant users. The configuration lives on its own dedicated purchase flow recommendations page in the Google Play Console.

Featured products

Featured products give you more direct control over promotion. Rather than letting Google Play choose which products to surface, you explicitly configure which products to highlight on Google Play surfaces. You can set start and end dates for promotions, associate them with specific offers or events, target specific audiences and countries, and limit them to licensed testers during development.

Featured products are useful for time-limited promotions, seasonal campaigns, or highlighting new premium content. They give you granular control over what gets promoted, to whom, and for how long.

Cart abandonment reminders

Cart abandonment reminders address a different part of the purchase funnel. When a user begins a purchase flow but does not complete it, Google Play can send a notification reminding them to finish the transaction. This is a common e-commerce pattern adapted for the app store context.

For cart abandonment reminders, you do not configure individual products. Instead, Google Play automatically tracks abandoned purchase attempts and sends reminders for users who started but did not finish a transaction. You can opt out of this feature entirely using a form in the Google Play Console if you prefer not to have reminders sent for your products. Currently, the opt-out is managed separately for one-time products and subscriptions.

What’s changing: A unified, ML-driven approach

Google is replacing these three separate tools with a single Merchandising and optimization page in the Google Play Console. Instead of managing purchase flow recommendations, featured products, and cart abandonment reminders independently, you will configure everything from one place.

The fundamental shift is from manual configuration to algorithmic optimization. Here is how the new approach works:

You select eligible SKUs: On the new page, you choose which of your products are eligible for out-of-app promotion.
Google’s ML decides the rest: Google Play’s machine learning models determine the optimal surfaces, timing, and audiences for displaying your selected products.
Broader reach, less manual control: The ML system can place your products across all out-of-app purchase flows that Google Play supports, potentially reaching more users than manually configured promotions would.

This means you lose some of the granular control that the featured products provided. You will no longer be able to set audience targeting, country targeting, or associate promotions with specific offers and events at the merchandising level. If you need country-level restrictions, you must configure them at the SKU level instead.

The trade-off is straightforward. You give up manual configuration in exchange for Google’s ML optimizing placement across a broader set of surfaces. For most developers, this should result in better performance because the ML models can test and iterate on placement strategies far faster than any manual configuration can.

For developers who have never configured any of these features, the new page is an opportunity. Previously, managing three separate configuration surfaces was enough friction to discourage many developers from engaging with out-of-app merchandising at all. A single page with a simpler interface lowers the barrier to entry. If you have products that could benefit from being promoted on Google Play surfaces, the new Merchandising and optimization page makes it easier to opt in.

The timeline: What happens and when

The migration follows a phased approach with a clear cutoff date. Here is what happens at each stage:

Date	What happens
Before March 16	Last chance to modify existing purchase flow recommendations and featured products configurations. Last chance to use the cart abandonment reminder opt out form for one time products.
March 16	Existing purchase flow recommendations and featured products pages become frozen. The cart abandonment reminder opt out form is disabled for one time products. No further changes can be made on these pages.
After March 16	Existing selections remain active according to the migration rules described below. Your configurations continue to function but cannot be modified.
New page launches	Google Play automatically migrates your existing selections to the new Merchandizing and optimization page. You can then modify your selections on the new page. The old pages for purchase flow recommendations and featured products are deprecated. The cart abandonment reminders opt out form for one time products is also deprecated.

The key takeaway is that March 16 is the hard deadline for any changes to your current setup. If you need to adjust your merchandising configurations, do it before that date.

Special considerations for featured products

Featured products have the most complex migration path because they support the most configuration options. Here is what happens to each aspect of your featured products configurations:

Configuration aspect	What happens after March 16
No end date set	The featured product remains in place and continues to be merchandized. No action needed.
End date after March 16	You have two options before March 16: make the product available indefinitely by removing the end date, or delete it if you do not want it merchandized past March 16.
Offers and events	Offers and events associated with featured products will no longer be supported. If you rely on these associations, plan accordingly before the cutoff.
Audience and country targeting	Audience and country targeting associated with existing featured products will not be supported. If you need to restrict country selection, you must configure that at the SKU level.
Licensed testers	Products that only target licensed testers will no longer be available for merchandizing. If you have products in a testing only configuration, they will be excluded from out of app promotion.
Performance reporting	Performance reporting and associated metrics remain visible on the featured products page until it is deprecated when the new Merchandizing and optimization page launches.

The most impactful change for developers who actively use featured products is the loss of audience and country targeting. If your merchandising strategy depends on showing different products to different regions, you need to rethink that approach. Moving country restrictions to the SKU level is the only remaining option.

Special considerations for purchase recommendations

Purchase recommendations have a simpler migration path because they offer fewer configuration options than featured products:

Active SKUs remain active: Any SKUs you have configured for purchase flow recommendations will continue to be eligible for out-of-app purchases after March 16.
Country targeting removed: Country targeting associated with your purchase recommendations will no longer be supported. Like featured products, you must handle country restrictions at the SKU level if needed.
Licensed testers excluded: Products that only target licensed testers will no longer be available for merchandising.
Performance reporting visible: Performance reporting and associated metrics remain on the purchase recommendations page until they are deprecated when the new page launches.

For most developers using purchase recommendations, the migration is straightforward. Your products continue to be recommended. You just lose the ability to fine-tune which countries see those recommendations.

Special considerations for cart abandonment reminders

Cart abandonment reminders have the simplest migration considerations, but there is one important detail to understand:

One-time products only in initial launch: The new Merchandising and optimization page will initially only include one-time products for cart abandonment functionality. Subscriptions are not part of the initial launch scope.
Subscription blocklist unchanged: If you have an existing blocklist for subscription cart abandonment reminders, it remains in place and is not affected by this migration.
Opt out mechanics: You can opt out of cart abandonment reminders for one-time products using the existing form until March 16. After that, you will need to wait until the Merchandising and optimization page launches to opt out. If you have already opted out, your opt-out remains in effect. If you want to stay opted in, no action is required.

What you should do before March 16

Here is a concrete checklist of actions to take before the cutoff:

Audit your featured products: Open the featured products page in Google Play Console and review all active configurations. Identify any that have end dates after March 16 and decide whether to make them indefinite or delete them.
Remove reliance on offers and events: If any of your featured products are associated with specific offers or events, note that these associations will stop being supported. Plan alternative promotion strategies for those products.
Move country restrictions to the SKU level: If you currently use country targeting on featured products or purchase recommendations, reconfigure those restrictions at the SKU level before March 16. This ensures your geographic targeting strategy survives the migration.
Review licensed tester configurations: If you have products configured only for licensed testers, understand that they will be excluded from merchandising. If you want these products to be promoted to real users, update the targeting before the cutoff.
Decide on cart abandonment opt out: If you want to opt out of cart abandonment reminders for one-time products, submit the opt-out form before March 16. After that date, you will need to wait for the new page to launch.
Save performance data: Export or screenshot any performance metrics from the featured products and purchase recommendations pages that you want to retain for historical analysis. These metrics will remain visible until the pages are deprecated, but it is good practice to save them now.
Communicate with your team: Make sure anyone on your team who manages Google Play Console configurations is aware of the March 16 deadline and the changes that are coming.

How out-of-app purchases connect to your billing stack

A common question when discussing out-of-app merchandising is how these purchases actually flow through your billing infrastructure. The good news is that out-of-app purchases initiated from Google Play surfaces go through the same Play Billing Library flow as any in-app purchase.

When a user taps on a recommended product, a featured product, or a cart abandonment reminder on a Google Play surface, the resulting purchase is processed through the standard Google Play Billing infrastructure. Your app receives the purchase through the same PurchasesUpdatedListener or queryPurchasesAsync calls that handle in-app purchases. The purchase token, product ID, and acknowledgment requirements are all identical. If your backend processes Real Time Developer Notifications (RTDN), you will receive the same notification types for out-of-app purchases as you do for in-app ones.

This means if you are using RevenueCat to manage your billing infrastructure, out-of-app purchases are processed automatically. RevenueCat’s SDK and backend handle purchase verification, entitlement granting, and acknowledgment for these transactions just like they do for purchases initiated within your app. There is no special SDK integration or code change needed to support purchases originating from out-of-app surfaces.

RevenueCat Charts can also track revenue from out-of-app surfaces alongside your in-app revenue. Since all purchases flow through the same billing pipeline, your existing analytics and reporting infrastructure captures these transactions without additional configuration. This is particularly useful after the migration, when you want to monitor whether the ML-driven approach is producing more or fewer out-of-app conversions compared to your previous manual configurations.

The important point is that the Merchandising and optimization page is a Console-side change. It affects how Google Play promotes your products to users, not how those purchases are processed once they happen. Your billing code, RevenueCat integration, and backend systems continue to work exactly as they do today.

Conclusion

In this article, you’ve explored Google Play’s upcoming consolidation of three separate merchandising features, purchase flow recommendations, featured products, and cart abandonment reminders, into a single ML-driven Merchandising and optimization page. The March 16 cutoff is the deadline for modifying any existing configurations, and understanding the migration rules for each feature ensures your products continue to be promoted effectively.

The shift from manual merchandising configuration to ML-driven optimization reflects a broader trend in how app stores manage product discovery. For most developers, the reduced manual control is offset by the potential for broader, algorithmically optimized reach across Google Play surfaces. The key is to prepare before the deadline by auditing your existing configurations, moving country restrictions to the SKU level, and making deliberate decisions about featured product end dates.

Whether you manage your billing with the Play Billing Library directly or use RevenueCat, the merchandising changes happen entirely on the Console side. Your billing code, purchase processing, and entitlement logic remain unchanged. Focus your effort on the Console configurations before March 16, and let Google’s ML handle the optimization from there.

How to personalize your paywalls with Custom Variables

Tue, 03 Mar 2026 19:55:08 GMT

Paywalls that feel personal convert better. With Custom Variables, you can now pass values from your app directly into your paywall, letting you customize the experience for each customer.

In this tutorial, I’ll walk you through setting up Custom Variables in a React Native app. We’ll take a simple tipping feature and personalize the paywall title with the customer’s name.

Prerequisites

Before getting started, make sure your app is running a compatible version of the RevenueCat SDK. Custom Variables require the following minimum package versions:

SDK	Mimimum version
purchases-ios	5.57.0
purchases-android	9.21.0
react-native-purchases	9.10.0
purchases-flutter	9.12.0

If you’re working with a platform other than React Native, check out the Custom Variables documentation for platform-specific instructions.

The example app

Here’s what we’re working with. I’ve built a simple app with a tipping feature that lets customers tip the developer if they enjoy the app. When the user taps the “Tip the developer” button, it presents a paywall configured in RevenueCat.

Right now, the paywall title is generic, showing only “Hey, You. You should buy me a pizza”. What I want to do is display the customer’s actual name in the paywall title to make it feel more personal.

Creating a Custom Variable in the Paywall Editor

To get started, open the Paywall Editor in your RevenueCat dashboard. In the left sidebar, select the Variables section. You’ll see a new “Create variable” button at the top.

Click it to define a new custom variable. I’ll name mine customerName, since that’s what we’ll be passing from the app.

You’re required to provide a default value. This is important because it ensures the paywall still looks good even if the variable isn’t set for some reason. In this case, I’ll use “You” as the fallback, so the title reads naturally either way.

Using the variable in your paywall

Now that the variable exists, we can reference it in the paywall content. Switch back to the Layers view, select the title text layer, and find the spot where you want to insert the variable. Replace the static word “You” with the new customerName variable using the “Add variable” button.

Once you’re happy with how it looks, publish the changes.

Passing the variable from your app

With the paywall side ready, let’s update the app code. The presentPaywall function now accepts a customVariables key, which takes an array of objects. Each object needs a key that matches the variable name you defined in the Paywall Editor, and a value wrapped in CustomVariableValue.string.

Here’s what the code looks like:

The key here is "customerName", which matches exactly what we defined in the editor. The value can be anything you pull from your app’s user data, authentication state, or wherever you store customer information.

The result

Save the changes and force a refresh so the app fetches the latest version of the paywall. Now when the customer taps “Tip the developer” and the paywall appears, you’ll see their name displayed right in the title.

That’s all it takes. A few lines of code in your app, a quick setup in the Paywall Editor, and your paywalls feel like they were built for each individual customer.

What’s next

Custom Variables open up a lot of possibilities beyond just names. Think about passing subscription status, usage stats, or any other value that might make your paywall more relevant and compelling.

For more details on Custom Variables and other RevenueCat features, check out the full documentation.

Meet the AI agent that creates paywalls, writes code, and tracks revenue in your Android Studio

Fri, 27 Feb 2026 00:13:11 GMT

Managing subscriptions, paywalls, and revenue metrics typically involves constant context switching between your IDE and the RevenueCat dashboard. You write code in Android Studio, switch to a browser tab to check MRR, open another tab to configure offerings, and switch again to design a paywall. Each context switch breaks your flow and fragments your attention. The RevenueCat IntelliJ Plugin eliminates this friction by bringing your entire subscription business directly into your development environment.

But this plugin is more than a dashboard mirror. It includes a full-featured AI agent that understands your RevenueCat project and can take action on your behalf. You can ask it to create offerings, generate paywalls with AI, analyze your revenue charts, debug integration issues, and even edit your source code, all through natural language prompts without leaving your IDE.

In this article, you’ll explore the key features of the RevenueCat IntelliJ Plugin, including how OAuth sign in replaces manual API key configuration, how the dashboard panel surfaces real time metrics without browser context switching, how the AI agent generates paywalls and manages your entire project through conversation, and how AI powered code editing lets the agent modify your project files with full diff preview and undo support.

The plugin uses OAuth 2.0 authorization with PKCE flow, replacing the older API key configuration. When you open the RevenueCat tool window for the first time, you’ll see a welcome screen with a “Sign in with RevenueCat” button.

Clicking the sign-in button opens your browser for authorization. The plugin starts a local callback server, handles the token exchange automatically, and stores your credentials securely. Once authorized, the plugin fetches your projects and lets you select which one to work with.

The OAuth flow requests scoped permissions for project configuration, charts and metrics, and customer information. Tokens refresh automatically when they expire, so you stay authenticated across sessions without manual intervention.

AI Agent code editing: Agent-powered file modifications

Beyond querying data, the AI agent can read, search, and edit your project’s source files directly. This enables workflows like “Add the RevenueCat SDK initialization to my Application class” or “Update my paywall screen to use the new offering ID.”

Staged edit system

When the agent proposes code changes, they appear as staged edits with inline diff preview. You can review each change before applying it:

Accept individual edits: Apply specific changes while rejecting others
Accept all: Apply all proposed changes at once
Reject: Discard proposed changes without modifying your files

AI paywall generation

The most powerful feature of the AI agent is end-to-end paywall generation. You describe what you want, and the agent handles everything: creating the offering, setting up packages, attaching products, and generating a fully designed paywall with AI, complete with copy, images, styling, and template selection.

he agent monitors the generation job in the background. When the paywall is ready, a notification appears with a direct link to the paywall builder where you can review and publish the design. The monitoring works reliably even when OAuth tokens expire, using your API key as an independent fallback.

You can generate multiple paywalls in sequence. The agent tracks each job independently, so you can ask for a “premium” paywall, then a “freemium” paywall, and the monitoring handles both without conflicts.

Managing your project through conversation

The agent supports full create, read, update, and delete operations across your RevenueCat resources. Here are some examples of what you can ask:

Creating resources:

"Create a new offering called Premium with a monthly package at $9.99 and an annual package at $79.99"

The agent creates the offering, creates both packages, and attaches the appropriate products. If any of these resources already exist, the agent detects the duplicates and reuses them instead of failing.

"Set up an entitlement called pro_access and attach it to all my subscription products"

The agent creates the entitlement, lists your existing products, and attaches each one.

Querying your project:

"Show me all my offerings and which ones have paywalls"

The agent fetches your offerings and paywall data, presenting a clear summary of what’s configured and what’s missing.

"What products do I have configured? Which ones aren't attached to any package?"

The agent cross references your products, packages, and offerings to find orphaned resources.

Paywall management:

"Generate an AI paywall for my premium offering. The app is a fitness tracker called FitCat targeting health conscious millennials."

The agent uses your app context to generate a paywall with relevant copy, styling, and design that matches your brand.

"Duplicate my current paywall and name it Holiday Promo"

The agent duplicates the paywall through the API and provides the builder link for customization.

Analyzing your revenue with Charts API

The agent has access to 21 chart types including revenue, MRR, ARR, churn rate, trial conversions, active subscriptions, and retention cohorts. You can ask analytical questions and get data driven answers:

"What's my MRR trend over the last 6 months?"

"Show me my trial to paid conversion rate broken down by weekly"

"Compare my revenue this month vs last month"

"What's my churn rate for annual subscribers?"

The agent queries the Charts API with the appropriate parameters, including date ranges, resolutions, and segment filters, and presents the results in a readable format.

Debugging and integration help

The agent isn’t limited to CRUD operations. It understands RevenueCat’s SDK and can help you debug integration issues:

"I'm getting a 'Configuration not found' error when presenting my paywall. What's wrong?"

The agent checks your project configuration, verifies that your offerings have packages with products attached, and identifies the root cause.

"Walk me through setting up RevenueCat in my Kotlin Multiplatform project"

The agent has access to Codelabs content and can provide step-by-step guidance tailored to your platform.

"What's the difference between offering lookup keys and offering IDs? Which one should I use in my code?"

The agent explains concepts with context from your actual project configuration, not just generic documentation.

Model selection

The AI agent supports multiple models that you can switch between using the gear icon in the input bar. Available models include GPT-4.1, GPT-4.1 Mini, Claude Sonnet 4, and Claude Haiku 4.5, letting you balance capability and response speed based on your needs.

Dashboard panel: Metrics without context switching

The dashboard panel gives you a live view of your RevenueCat project without opening a browser. It organizes your subscription data into collapsible sections that load when you open the tool window.

Revenue overview

The top section shows your key metrics at a glance: active subscribers, active trials, MRR, and revenue. These numbers pull directly from the RevenueCat API, so you’re always looking at current data.

Milestones

Below the metrics, a milestones section tracks your subscription business achievements. These are the same milestones you’d see on the RevenueCat dashboard: first subscriber, revenue thresholds, and trial milestones, all surfaced directly in your IDE.

Configured offerings

The offerings section lists all your offerings with their packages and attached products. You can expand each offering to see its package structure, which products are attached, and whether it has a paywall configured. Offerings with paywalls show a direct link to the paywall builder.

Paywalls section

A dedicated paywalls section shows all your paywalls with colored status badges: Published (green), Draft (yellow), and Has Unpublished Changes (orange). Each paywall has context-aware action buttons based on its status: Edit, Publish, Unpublish, Discard, Duplicate, and Delete. The Edit button opens the paywall builder in your browser. Lifecycle actions call the API directly and auto-refresh the panel.

Conclusion

The RevenueCat IntelliJ Plugin transforms your IDE into a complete subscription management environment. OAuth sign-in eliminates manual API key configuration. The dashboard panel surfaces metrics, milestones, offerings, and paywalls without browser context switching. The AI agent goes far beyond a simple chatbot. It creates offerings, generates paywalls with AI, analyzes your revenue data through the Charts API, debugs integration issues, and edits your source code with safe, reviewable changes.

The AI paywall generation alone saves significant time. Instead of navigating through the dashboard to create an offering, set up packages, attach products, and design a paywall manually, you describe what you want in one sentence, and the agent handles every step. The result is a fully designed paywall ready for review in the builder.

Whether you’re checking your MRR between code reviews, generating a paywall for a new offering, analyzing churn trends, or asking the agent to scaffold your SDK integration, the plugin keeps you in your development flow. The goal is simple: spend less time switching tabs and more time building your subscription business. You can install the RevenueCat IntelliJ Plugin from the JetBrains Marketplace: RevenueCat Dashboard.

Announcing the Shipyard: Creator Contest 2026 winners

Thu, 26 Feb 2026 15:01:09 GMT

What happens when real influencers hand you a brief and say, “Build the app my audience actually needs“? Shipyard: Creator Contest set out to answer that question. In just four weeks, more than 900 builders competed to design, launch, and monetize an MVP for seven creators ready for long-term app partnerships. Now, we’re proud to introduce the seven winners.

Eitan Bernath

In Eitan Bernath’s category, the task was to help people actually cook what they’ve been meaning to make. Think of tools that turn inspiration into action: an app that can generate a grocery list from a recipe video/link, organize what you want to cook, and make it simple to get started.

Winning app: Preplo – turning cooking videos into actionable recipes

Preplo turns cooking inspiration into something you can actually make. Drop in a YouTube, TikTok, or Instagram link and it instantly generates a structured recipe with quantities, step-by-step instructions (with timestamps), estimated costs, and nutrition info. It makes the jump from “I saved this” to “it’s on the table” much easier.

You can also tweak recipes on the fly — make it spicier, vegan, or low-carb, and everything updates accordingly. Built with Expo React Native and a Next.js backend, Preplo also caches processed videos so the same clip is never analyzed twice.

Devpost link

Gabby Beckford

In Gabby Beckford’s brief the goal was to build an upbeat, motivating app that turns goals into daily micro-actions, with challenges, streaks/wins, tracking, and gamified moments that make progress feel fun. Designed for ambitious women who want to embark on dream trips and life upgrades, but often get held back by the mundane day-to-day, or stuck between inspiration and action.

Winning app: Bloom – turning big dreams into daily wins

Bloom is a gamified personal growth app for women who need help taking the steps to turn dreams into daily life. Instead of another to-do list, Bloom connects goals, money confidence, mindset, and travel into one motivating system.

At the center is the Digital Garden: daily habits fuel visible growth, so progress feels real. Users can set ‘Dreams’, play bite-sized financial mini-games, journal with AI guidance, and track travels on an interactive map. Built with Flutter and powered by Supabase and Mapbox, Bloom focuses on making self-development feel encouraging rather than overwhelming.

Devpost link

Quin Gable

Dating and making friends on the road is hard when you’re always moving. Digital nomad Quin Gable wanted a van-life app with nomadic dating, activity-based friend finding, and even a paid ‘builder help’ section for van projects. To keep the community protected, the app needed to be invite-only or verified access to ensure the app remained safe and connection was intentional.

Winning app: WanderBase – dating and community for life on the road

WanderBase is a dating and community app built specifically for van-lifers and nomads. Instead of endless swiping, users explore hand-illustrated, customizable van avatars that reflect your lifestyle and travel vibe; a playful twist that feels true to life on the road.

It’s invite-only, with route-based matching, mutual chat unlocks, and a help-finding forum for van projects. Built with React Native and Firebase, with server-side matching and strict security rules, WanderBase guarantees trust, and prioritizes safety and fun in equal measure.

Devpost link

Sam Beckman

Sam lives by reminders, but switching between Android and iOS means rebuilding his entire system from scratch. His brief was to build a beautiful, fully-functional reminders app on both iOS + Android. It needed custom snoozes from notifications, powerful recurring rules, and true sync, so dismissing once clears everywhere.

Winning app: Remy Reminders – cross-platform reminders, finally in sync

Remy solves a real frustration: switching between iOS and Android without rebuilding your reminder system from scratch. It delivers a polished reminders app regardless of your platform choice, offers simple but effective rule-making, built-in notification pauses, and more.

Behind the scenes is a custom offline-first sync engine and a notification system that talks directly to APNs and FCM to keep everything aligned. Built with React Native (Expo), and Convex, Remy focuses on making reminders reliable, no matter what device you’re using.

Devpost link

Simon from Better Creating

Simon’s audience loves productivity, great design, and building systems for self improvement. Coaching is a key part of this, so Simon wanted to make the growth and self-assurance that comes from coaching accessible. This meant creating a clean, minimal mobile app where users can browse, create, and share AI coaches, add personal context/values, and start chatting immediately.

Winning app: Editor – decide with clarity

Editor flips the typical coaching or AI chat experience on its head. Instead of encouraging endless conversation, it’s designed to help builders and creators reach decisions quickly and deliberately. Going beyond a coaching app, users choose structured thinking modes like prioritizing, reviewing ideas, or weighing trade-offs.

Each session is built to get you to a decision quickly, then end. Outcomes can be turned into decision briefs or roadmaps and exported to Notion. Built as a native SwiftUI app, Editor stays intentionally minimal and focused.

Devpost link

Rebecca Louise

Rebecca hears it constantly: mums are short on time, want financial independence, and need practical help. Her brief was to build an app that offers everyday money-saving guidance (shopping swaps, batch cooking, cost comparisons, home reno savings) plus an approachable path into investing basics, so users can grow what they have without overwhelm.

Winning app: Sunny Money – Financial confidence for busy mums

Sunny Money helps busy mums build financial confidence in just a few minutes a day. It combines everyday money-saving guidance with simple introductions to saving and investing.

Bite-sized lessons, practical calculators, daily challenges, and an AI assistant make financial progress feel manageable. Built with React Native and Expo, Sunny Money respects mums’ time while still delivering real, useful tools.

Devpost link

Josh from VisualFaktory

Investors juggle stocks, gold, funds, fixed income, real estate, and more across multiple platforms. It’s messy to track and hard to understand at a glance. Josh wanted a single app where users can log everything, get real-time price updates where possible, set amortization/reminder alerts for non-listed products, and unlock premium risk + diversification analysis (like country/sector exposure).

Winning app: Folio – see your entire portfolio at a glance

Folio brings scattered investments into one clean iOS dashboard. Stocks, ETFs, crypto, property, savings — everything in one place so you can see your full net worth and understand your exposure on one screen.

It includes live pricing, performance breakdowns, widgets, alerts, and an AI assistant that understands your actual holdings and can help rebalance or adjust positions. Built with React Native and Supabase, Folio keeps portfolio tracking straightforward and actionable.

Devpost link

That’s a wrap

Across seven very different briefs, the winning apps had something in common: focus.

They didn’t try to do everything. They picked a specific audience, a clear problem, and built around it. The van-life app prioritized trust and safety. The reminders app obsessed over cross-platform sync. The finance apps respected their users’ time. The AI coach constrained itself on simplicity. Each team made deliberate trade-offs instead of chasing features.

While this is the end, we hope all of you continue building your apps, and most importantly, work on getting them out for people to download.

How did you find Shipyard? Did you have fun? Were there things you wish we had done differently?

We’d love to hear your thoughts. Let us know on Twitter or LinkedIn, and keep an eye out for a survey we’ll be sending to all participants to gather your feedback.

Cross-platform subscription state: sharing entitlements between Android and iOS

Tue, 24 Feb 2026 02:49:36 GMT

Subscription apps rarely live on a single platform. A user might subscribe on their iPhone during their morning commute, then open your Android tablet app at home expecting full access. This expectation is intuitive from the user’s perspective, they paid for a subscription, so it should work everywhere. But from a developer’s perspective, making this work is one of the hardest problems in subscription infrastructure. Google Play Billing and Apple’s StoreKit are entirely separate systems with different receipt formats, different verification mechanisms, different notification systems, and fundamentally different assumptions about how purchases are represented. There is no built in interoperability between them.

In this article, you’ll explore why cross platform subscription state is so difficult to implement, examine the fundamental incompatibilities between Google Play Billing and StoreKit, walk through what it takes to build cross platform entitlement sync from scratch, and see how RevenueCat’s identity system provides a natural solution that dramatically reduces the engineering effort required, especially for small teams and indie developers.

The fundamental problem: One user, two ecosystems

Consider a fitness app with a “Premium” subscription. A user subscribes through the App Store on their iPhone. A week later, they buy an Android tablet and download your app. They log in with the same account and expect to see their premium features. What actually happens?

Without cross platform infrastructure, the Android app has no idea this user has an active subscription. Google Play Billing only knows about purchases made through Google Play. The App Store receipt sitting on Apple’s servers is invisible to the Android app. The user sees a paywall asking them to subscribe again, even though they are already paying.

This is not a bug. It is the expected behavior. Each billing system operates in isolation, and bridging them requires significant infrastructure that neither platform provides.

Two billing systems, zero interoperability

To understand why cross platform sync is so difficult, you need to understand how differently Google and Apple represent purchases. These are not minor API differences. They are fundamentally different architectures.

Receipt formats and verification

Apple and Google use entirely different mechanisms to prove that a purchase happened.

Aspect	Google Play Billing	Apple StoreKit
Purchase proof	Purchase token (opaque string)	Signed receipt (JWS in StoreKit 2)
Verification endpoint	`purchases.subscriptionsv2.get` REST API	App Store Server API (`/inApps/v1/subscriptions`)
Authentication	Google service account with JSON key	JWT signed with App Store Connect private key
Response format	`SubscriptionPurchaseV2` JSON object	`JWSTransactionDecodedPayload` (signed JSON)
Subscription ID format	`productId:basePlanId`	Simple `productId` string
Renewal tracking	`expiryTime` field on subscription resource	`expiresDate` in transaction info

Google Play uses a purchase token model. When a user subscribes, your app receives a purchase token. You send this token to the Google Play Developer API, which returns the current subscription state. The token is an opaque string with no inherent meaning.

Apple uses a signed transaction model. In StoreKit 2, purchase information is delivered as JSON Web Signatures (JWS) that your server can verify using Apple’s public key. Each transaction is a self contained, cryptographically signed record.

These are not just different APIs wrapping the same concept. They represent different philosophies about where trust lives. Google says “ask our server, we’ll tell you the state.” Apple says “here’s a cryptographically signed proof, verify it yourself.”

Real-time notifications

Both platforms offer server-to-server notifications for subscription events, but the notification systems differ substantially.

Aspect	Google Play RTDN	Apple Server Notifications V2
Delivery mechanism	Google Cloud Pub/Sub	HTTPS POST to your endpoint
Notification format	`DeveloperNotification` with type enum	`signedPayload` (JWS) with `notificationType`
Event types	`SUBSCRIPTION_RENEWED`, `SUBSCRIPTION_CANCELED`, etc.	`DID_RENEW`, `DID_CHANGE_RENEWAL_STATUS`, etc.
User identification	`purchaseToken` in notification	`originalTransactionId` in signed payload
Setup	Configure Pub/Sub topic in Play Console	Register URL in App Store Connect

Google delivers notifications through Cloud Pub/Sub, requiring you to set up a Pub/Sub subscription and a processing service. Apple sends HTTPS POST requests directly to a URL you configure. The event names differ, the payload structures differ, and the information included in each notification type differs.

This means your backend needs two completely separate notification processing pipelines with different authentication, different parsing logic, and different state machine interpretations.

Product configuration

Even the way you define subscription products differs between platforms.

Google Play introduced base plans and offers in 2022, creating a hierarchical product model: a subscription contains one or more base plans, each of which can have multiple offers with different pricing phases. A single subscription product ID can have monthly and annual base plans, introductory offers, and promotional pricing, all configured through the Play Console.

Apple’s product model is flatter. Each product ID in App Store Connect represents a single subscription with a single duration. To offer both monthly and annual options, you create two separate product IDs and group them in a subscription group. Introductory offers and promotional offers are configured per product, not as nested objects.

This structural difference means there is no one to one mapping between a Google Play subscription product and an Apple subscription product. Your backend must maintain a mapping layer that translates platform specific product identifiers into a unified entitlement concept.

Building cross platform sync yourself

If you decide to build cross platform subscription sync without a third party service, here is what the architecture looks like. Understanding this effort is important even if you ultimately choose a managed solution, because it reveals why the problem is genuinely hard.

Step 1: Unified user identity

The first requirement is a user identity system that works across platforms. Each platform has its own notion of a user, but neither knows about the other. You need a server side user account that both platforms can associate purchases with.

For iOS, there will not be much difference from the Android side:

Both clients send purchase data to your backend, tagged with the same userId. Your backend must verify each purchase against the correct platform’s API and record the entitlement against the unified user account.

Step 2: Dual receipt verification

Your backend needs to verify purchases from both platforms, which means integrating with two completely different verification APIs:

Each verification path has its own authentication setup, error handling, and response parsing. Google requires a service account credential. Apple requires a JWT signed with a private key from App Store Connect. The response formats share no common structure.

Step 3: Unified entitlement storage

Your backend needs a data model that maps platform-specific products to platform-agnostic entitlements:

When either client queries for entitlements, your backend checks whether the user has any active entitlement, regardless of which platform it originated from:

Step 4: Dual notification processing

To keep entitlements in sync in real time, your backend must process notifications from both platforms simultaneously:

Each notification handler has different event names, different payload structures, and different state machine semantics. Grace periods work differently. Refund flows work differently. Even the concept of “cancellation” has subtle differences between the two platforms.

The true scope of effort

You need an infrastructure, building a cross-platform subscription sync involves. Even both Google and Apple regularly update their billing systems. Google introduced base plans and offers in 2022, requiring significant backend changes. Apple launched StoreKit 2 with an entirely new transaction model. Each major update requires engineering time to adapt your infrastructure.

For a large team with dedicated backend engineers, this might be manageable. For a small team or an indie developer trying to ship a subscription app on both platforms, this represents months of work that has nothing to do with the core product.

RevenueCat’s identity system: The natural solution

RevenueCat solves the cross platform problem at its foundation through a unified identity and entitlement system. Rather than requiring you to build the infrastructure described above, RevenueCat provides it as a service. The key design decision that makes this work is the app user ID abstraction.

How the identity system works

When you configure the RevenueCat SDK, you can either provide your own user ID or let RevenueCat generate an anonymous one:

For iOS will be like so:

The same appUserID on both platforms creates a single subscriber record in RevenueCat’s backend. When the user subscribes on either platform, RevenueCat verifies the receipt, records the entitlement, and associates it with this user ID. When the other platform’s SDK queries for customer info, it receives the complete entitlement state, including subscriptions from the other platform.

Anonymous to identified user flow

RevenueCat also handles the common scenario where users start anonymously and later create an account. When a user first opens your app, RevenueCat generates an anonymous ID in the format $RCAnonymousID:<uuid>. If the user subscribes before creating an account, the subscription is associated with this anonymous ID.

When the user later creates an account and logs in, RevenueCat’s logIn method transfers all purchases from the anonymous user to the identified user:

The created boolean indicates whether this was a new user or an existing one. If it is an existing user, RevenueCat merges the purchase histories. This is critical for cross platform scenarios: a user who first subscribed on iOS and later installs the Android app gets their entitlements transferred automatically when they log in with the same user ID.

CustomerInfo: One object, all platforms

The CustomerInfo object is RevenueCat’s answer to the cross platform entitlement problem. It aggregates subscription state from every platform into a single, easy to query object:

The store property on each entitlement tells you which platform the subscription originated from. But for granting access, you do not need to check it. The isActive property is the only thing that matters, and it works across all platforms.

This is the key insight: RevenueCat transforms a cross platform infrastructure problem into a single property check. Your Android app does not need to know how to verify Apple receipts. Your iOS app does not need to know about Google Play purchase tokens. RevenueCat’s backend handles all of that and presents a unified view through CustomerInfo.

What happens behind the scenes

When a user subscribes on iOS and later opens the Android app, the following sequence occurs:

The iOS SDK posts the App Store receipt to RevenueCat’s backend.
RevenueCat verifies the receipt with Apple’s servers and records the entitlement against the user’s app user ID.
RevenueCat registers for Apple Server Notifications to track renewals, cancellations, and billing issues.
When the Android app launches and calls getCustomerInfo, the SDK sends the same app user ID to RevenueCat’s backend.
RevenueCat returns the complete entitlement state, including the iOS subscription.
The Android app sees isActive == true on the premium entitlement and grants access.

All renewal events, grace periods, cancellations, and expirations are tracked server side by RevenueCat. Both platforms always see the current subscription state without any platform specific code.

Handling subscription management

One practical detail that cross platform subscriptions introduce is management URL routing. A user who subscribed on iOS needs to manage their subscription through the App Store, not Google Play. RevenueCat handles this through the managementURL property:

This prevents the confusing scenario where a user tries to cancel their subscription through Google Play but cannot find it because the subscription lives on Apple’s side.

The impact on development velocity

The difference in implementation effort between building cross platform sync yourself and using RevenueCat is substantial. Let’s compare the two approaches for a team shipping a subscription app on both Android and iOS.

Without RevenueCat

You need to build and maintain: a backend server with two receipt verification integrations, two notification processing pipelines, a user identity system, an entitlement database, and client side code on both platforms to communicate with your backend. This is 10 to 18 weeks of initial development, plus ongoing maintenance as both platforms evolve.

With RevenueCat

Your implementation reduces to: configure the SDK with an app user ID on each platform, check CustomerInfo for active entitlements, and display paywalls. The backend infrastructure is handled entirely by RevenueCat.

This is the complete code needed to support cross platform subscriptions on Android. The equivalent iOS code is similarly concise. No backend server, no receipt verification, no notification processing, no entitlement database. RevenueCat manages all of it.

For indie developers and small teams, this difference is not just about saving time. It is about feasibility. Building cross platform subscription infrastructure from scratch requires backend engineering expertise, server hosting, monitoring, and ongoing maintenance. Many small teams simply cannot afford this investment, which means they either skip cross platform support entirely or build something fragile that breaks when platform APIs change. RevenueCat makes cross platform subscriptions accessible to teams of any size, letting developers focus their limited time on the features that make their app unique.

Conclusion

In this article, you’ve explored why cross platform subscription state is one of the hardest problems in mobile monetization. Google Play Billing and Apple’s StoreKit are fundamentally different systems with incompatible receipt formats, different verification APIs, different notification mechanisms, and different product structures. Bridging them requires a unified identity system, dual receipt verification, platform agnostic entitlement storage, and two parallel notification processing pipelines.

Building this infrastructure from scratch takes months and requires continuous maintenance as both platforms evolve. For large teams, it is a significant but manageable investment. For small teams and indie developers, it can consume more engineering time than the core product itself.

RevenueCat’s identity and entitlement system provides a natural solution by abstracting away the platform differences behind a single CustomerInfo object. A shared app user ID across platforms, combined with RevenueCat’s server side receipt verification and notification processing, transforms a months long infrastructure project into a few lines of SDK configuration. Whether a subscription originated from the App Store, Google Play, Amazon, or the web, your app simply checks isActive and grants access.

For teams building subscription apps that serve users across platforms, understanding the scope of this problem helps you make informed build versus buy decisions. The time saved by using a managed solution can be redirected toward improving your app, optimizing your paywall, and building the features that actually differentiate your product.

Building a hardware-enabled subscription business

Wed, 18 Feb 2026 13:39:21 GMT

Hardware alone doesn’t build enterprise value. And layering a subscription on top of hardware only works if the product becomes part of daily life.

In this episode of Sub Club, Skylight’s CEO and CPO share how they built a profitable hardware business with strong subscription attach — and the hard lessons they learned about daily usage, emotional pricing, product readiness, and retail distribution.

Here are five takeaways for anyone building a hardware-enabled subscription business.

Hardware-enabled subscriptions need daily usage to work

A hardware device can justify a subscription — but only if it’s used daily.

If a device sits idle, recurring revenue quickly feels optional. Customers start questioning what they’re paying for. But when a product becomes embedded in daily routines — organizing schedules, surfacing tasks, anchoring family communication — the subscription feels like a natural extension of its value.

Daily attention creates subscription leverage.

For Skylight, the turning point came when the Calendar product became the “heartbeat of the home.” Once families relied on it every day, the subscription became less about upselling features and more about unlocking deeper utility.

Without habitual usage, subscriptions struggle. With it, they compound.

Stop optimizing when you should be building

A/B testing and funnel optimization can drive incremental gains. But sometimes the biggest growth lever isn’t conversion — it’s product.

With limited resources, Skylight had to prioritize carefully. Instead of spreading effort across endless micro-experiments, they focused on building genuinely valuable features that strengthened the overall experience.

Optimization matters. But step-function growth often comes from shipping something that makes the product meaningfully better.

When resources are constrained, prioritization becomes strategy.

Price based on customer emotion, not just data

When Skylight revisited its subscription pricing, testing showed $99/year would maximize revenue.

On paper, it was the ARPU winner.

But qualitative research told a different story. While $79 felt fair, $99 approached what the team described as “disgust territory.” That emotional reaction mattered.

For a company focused on long-term brand equity, short-term revenue optimization wasn’t worth risking customer resentment. They chose $79 — prioritizing goodwill and trust over squeezing every dollar.

Pricing isn’t just math. It’s emotional positioning.

The spreadsheet can tell you what maximizes revenue. Only customer conversations tell you what preserves loyalty.

Build a great product before scaling marketing

Marketing can’t fix a weak product.

In 2021–22, Skylight tried to scale its Calendar product aggressively. Paid acquisition ramped up. Growth stalled. The numbers didn’t work.

The problem wasn’t the ads — it was the product.

Until the team pushed the experience to a 40+ Net Promoter Score, marketing dollars produced false negatives and wasted spend. Once the product truly resonated, scaling became viable.

If product-market fit isn’t solid, scaling marketing only amplifies friction.

Get the product right first. Then turn on growth.

Retail partnerships are the ultimate influencer

In hardware, distribution is influence.

Retail partnerships with companies like Costco and Best Buy provide a stamp of quality that paid ads can’t replicate. Being on trusted shelves signals credibility to customers at scale.

While direct-to-consumer channels often drive higher subscription attach rates, multi-channel distribution expands reach and strengthens brand legitimacy.

Hardware can be copied. Distribution is harder to replicate.

For Skylight, retail wasn’t just a sales channel — it was a growth engine and a positioning advantage.

Balancing growth, profit, and long-term trust

Across all five lessons, a deeper theme emerges: growth and profit often pull in different directions.

Making subscriptions frictionless can reduce margin.
Raising prices can increase ARPU but hurt long-term trust.
Cutting hardware prices could accelerate growth but compress profitability.
Over-optimizing can distract from building durable value.

Every decision involves trade-offs.

Skylight’s approach shows that scaling a hardware-enabled subscription business isn’t about maximizing every metric at once. It’s about choosing which levers matter most — and when.

Hardware-enabled subscriptions aren’t about layering recurring revenue onto a device. They’re about earning daily relevance, pricing with emotional intelligence, and building a product strong enough to deserve scale.

🎧 Listen to the full episode of Sub Club to hear the complete conversation and the experiments behind these lessons.

Building Helm: turning App Store pain into a product developers love

Wed, 11 Feb 2026 13:53:22 GMT

If you’ve shipped more than one iOS app, you already know the feeling: App Store Connect works — but only barely. Releases are slow. Metadata updates are clunky. Translations are painful. And every launch feels harder than it needs to be.

That frustration is exactly where Helm came from.

In this episode of Launched, host Charlie Chapman sits down with Hidde van de Ploeg and Pol Piella, the co-founders of Helm, to unpack how a deeply personal pain point turned into a tool indie developers now recommend by name.

This isn’t a story about chasing a market. It’s a story about improving an experience that was lacking.

Build for the pain, not the platform

Helm wasn’t born out of market analysis or trend-chasing. It came from Hidde’s repeated frustration shipping his own apps. App Store Connect wasn’t broken enough to replace — but it was broken enough to slow him down every single time.

Instead of brainstorming abstract opportunities, Hidde and Pol focused on the workflows that consistently caused friction in their own day-to-day work. By starting with problems they personally experienced, they ended up building something instantly useful to the exact audience they belong to: indie app developers.

That closeness to the problem shaped everything — from what Helm does to what it very intentionally does not do.

Focus beats feature parity

Helm doesn’t try to replicate App Store Connect. It rebuilds only the parts developers actively dread — and makes them effortless.

Rather than matching Apple feature-for-feature, Hidde and Pol obsessed over friction points like fast TestFlight access, AI-powered translations, and smoother release workflows. The goal was never completeness. It was relief.

By doing less, but doing it brilliantly, Helm turns a clunky chore into something developers actually enjoy using. The product succeeds not by breadth, but by precision.

Delight is the best growth strategy

Helm didn’t grow through paid ads, SEO funnels, or launch gimmicks. It grew because developers felt seen.

As Helm spread, a pattern emerged on social media: when someone complained about App Store Connect, another developer would often jump in to recommend Helm. That kind of advocacy only happens when a product genuinely removes pain for the right people.

Helm’s growth is a reminder that for indie tools, delight can be a far more powerful growth engine than distribution tactics.

Marketing is about memory, not metrics

Some of Helm’s most talked-about moments weren’t designed to convert at all.

Sponsoring a small amateur football team named Swift wasn’t about customer acquisition. It was about building brand lore. Playful initiatives like Helm Passport followed the same philosophy — they were meant to be fun, human, and memorable.

In a world of perfectly optimized funnels, Helm stands out by embracing personality. That personality sticks with people long after they forget feature lists.

Mobile is a chance to surprise

When Helm expanded to iOS, the team didn’t simply shrink the desktop experience to fit a smaller screen. They leaned into what mobile does best.

Features like Helm Passport, built with App Clips, introduced a playful, real-world interaction that sparked conversation and sharing. Mobile wasn’t treated as a secondary surface, but as an opportunity to rethink how the product could show up in people’s lives.

Great mobile experiences don’t just adapt existing products. They reimagine them.

Shared ownership beats rigid roles

Although Hidde and Pol come from different backgrounds — design and engineering — they don’t operate in silos. Both founders touch the whole product, jump in wherever needed, and stay deeply familiar with the entire codebase.

That shared ownership keeps Helm fast, resilient, and aligned. For small teams, overlapping responsibility often matters more than clearly defined roles.

A product built from real frustration

Helm’s story is a reminder of why Launched exists in the first place.

You don’t need a grand vision to start something meaningful. Sometimes, you just need a problem that won’t leave you alone — and the willingness to fix it properly.

🎧 Listen to the full episode of Launched to hear Hidde van de Ploeg and Pol Piella share how they turned everyday frustration into one of the most loved indie tools in the iOS ecosystem — and where Helm is headed next.

How kotlinx.serialization generates code: a compiler plugin deep dive

Wed, 11 Feb 2026 03:56:08 GMT

Kotlinx.serialization has become the standard serialization library for Kotlin, offering compile time code generation, multiplatform support, and format agnostic design. Most developers know the surface level usage: annotate a class with @Serializable, and the library handles the rest. But the deeper question remains: how does the compiler plugin actually generate serializers? What happens between your @Serializable annotation and the working KSerializer<T> implementation?

In this article, you’ll dive deep into the internal mechanisms of the kotlinx.serialization compiler plugin, exploring how the two pass IR generation pipeline works, how the plugin generates the $serializer nested class with its descriptor, serialize, and deserialize methods, and the clever optimizations like golden mask validation that make deserialization both safe and performant. Also, you’ll explore with the real use cases of kotlinx.serialization from the RevenueCat SDK.

The fundamental problem: Reflection is expensive and platform dependent

Consider a simple data class that you want to serialize to JSON:

Without code generation, serialization libraries must use reflection to discover properties, their types, and their values at runtime. This approach has significant drawbacks:

The problems with this approach are substantial. First, reflection is slow. Discovering properties, checking accessibility, and invoking getters at runtime adds overhead to every serialization operation. Second, reflection is platform dependent. Kotlin/Native and Kotlin/JS have limited or different reflection capabilities than the JVM. Third, there is no compile time safety. Type mismatches and missing properties are only discovered at runtime.

The kotlinx.serialization plugin solves these problems by generating serialization code at compile time. The generated code knows exactly which properties exist, their types, and how to read and write them, with no reflection required.

The compiler plugin architecture

The kotlinx.serialization compiler plugin operates as an extension to the Kotlin compiler, hooking into multiple stages of the compilation pipeline. The plugin is organized into several components that work together:

Frontend (K1 or K2): Detects @Serializable annotations and generates synthetic declarations (the $serializer class, companion methods).
IR Generation: Transforms the intermediate representation in two passes. Pass 1 creates function stubs, Pass 2 generates method bodies.
Backend: Emits platform specific code (JVM bytecode, JavaScript, or Native binaries).

The plugin registers itself through a CompilerPluginRegistrar that hooks into these extension points. The critical registration looks conceptually like this:

The key observation here is that the plugin operates at multiple levels. It first generates synthetic declarations during the resolve phase, making the compiler aware of generated classes and methods. Then it generates the actual implementation bodies during the IR lowering phase.

Two pass IR generation: Stubs before bodies

One of the most interesting aspects of the kotlinx.serialization plugin is its two pass IR generation strategy. Understanding why this is necessary requires understanding how generated code references itself.

Consider what the plugin needs to generate for a serializable class:

The generated serialize() method might call a helper method like write$Self(). The deserialize() method needs to call the class constructor. These methods reference each other and reference other generated elements. If the plugin tried to generate everything in a single pass, it would encounter undefined references.

The solution is a two pass approach:

In the first pass, the plugin creates function declarations with empty bodies. This establishes all the symbols that generated code might reference. In the second pass, the plugin fills in the actual implementation bodies, now able to reference any symbol created in the first pass.

This is elegant. The two pass strategy mirrors how compilers handle forward declarations in languages like C, but applied to code generation within a single compilation unit.

The generated serializer structure

When you annotate a class with @Serializable, the plugin generates a nested class named $serializer that implements GeneratedSerializer<T>. Let’s trace through what gets generated for a simple class:

The plugin generates a structure that conceptually looks like this:

Notice the structure. The $serializer class is an object (singleton) that holds the immutable descriptor and implements the serialization logic. The companion object provides a convenient serializer() accessor.

Descriptor generation: Metadata for format agnostic serialization

The SerialDescriptor is a critical piece of the generated code. It describes the structure of the serializable class in a format independent way, enabling different serialization formats (JSON, Protobuf, CBOR) to use the same serializer implementation.

The plugin generates descriptor initialization code that builds the complete metadata:

The descriptor includes the serial name of the class (which might differ from the class name if @SerialName is used), the number of elements, each element’s name and whether it’s optional, type information for nested serializers, and any @SerialInfo annotations applied to the class or its properties.

This design is clever. By separating the structural metadata from the serialization logic, formats can make intelligent decisions about encoding. A JSON encoder might use the element names directly as keys. A Protobuf encoder might use element indices. The serializer implementation remains the same.

Golden mask optimization: Efficient required field validation

One of the most important optimizations in the generated code is the golden mask pattern for validating required fields during deserialization. When deserializing, the plugin needs to ensure all required (non optional) fields are present in the input.

The naive approach would be to check each field individually:

Instead, the plugin generates bitmask based validation:

This is a gold. A single bitwise AND operation validates all required fields simultaneously. The golden mask is computed at compile time based on which properties have default values (optional) and which don’t (required).

For classes with more than 32 properties, the plugin generates multiple mask integers:

The error reporting is also smart. The throwMissingFieldException function uses the seen mask and golden mask to determine exactly which fields are missing, providing a clear error message without requiring additional bookkeeping.

Serializer resolution: Finding the right serializer for each type

When generating serialization code for a property, the plugin must determine which serializer to use. This resolution follows a priority order:

This resolution happens at compile time, and the result is baked into the generated code. The generated childSerializers() method returns an array of all serializers needed for the class’s properties, enabling format implementations to introspect the complete serialization structure.

Real world application: Custom serializers in production SDKs

Understanding the generated serializer structure helps when building custom serializers. Production SDKs like RevenueCat’s Android SDK leverage this knowledge to build robust serialization for complex API responses.

For example, when dealing with backend responses that might include unknown enum values or polymorphic types, a custom deserializer with defaults becomes necessary:

This pattern mirrors how the plugin generates deserializers but adds fallback behavior for unknown types. It reads the type discriminator, looks up the appropriate serializer, and falls back to a default when the type is unknown. This is essential for backward compatibility when servers add new types that older clients don’t recognize.

Similarly, enum deserialization with defaults handles unknown values gracefully:

These patterns work because they follow the same interface contract that the generated serializers implement. Understanding the generated structure makes building compatible custom serializers straightforward.

K1 vs. K2: Supporting both compiler frontends

The Kotlin compiler is undergoing a major transition from the K1 frontend to the K2 frontend (based on FIR, Frontend Intermediate Representation). The kotlinx.serialization plugin must support both during this transition.

The K1 support uses descriptor based APIs:

The K2 support uses the new FIR based APIs:

The key observation is that both frontends ultimately feed into the same IR generation phase. The IR lowering code that generates method bodies is shared between K1 and K2. This separation of concerns allows the plugin to support both frontends while maintaining a single implementation of the actual code generation logic.

Conclusion

In this article, you’ve explored the internal mechanisms of the kotlinx.serialization compiler plugin, from its two pass IR generation strategy to the golden mask optimization for required field validation. The plugin transforms simple @Serializable annotations into efficient, type safe serializers without requiring reflection or runtime code generation.

Of course, you don’t have any issues without understanding these internals mechanisms, but it will definitely help you make informed decisions when building custom serializers, debugging serialization issues, or evaluating kotlinx.serialization for your projects in any ways. The design choices, like compile time code generation, format agnostic descriptors, and bitmask validation, reflect careful engineering for both performance and flexibility.

Whether you’re building a multiplatform application that needs consistent serialization across JVM, JS, and Native, implementing custom serializers for complex API responses, or simply curious about how your @Serializable classes become working serializers, this knowledge provides the foundation for working effectively with one of Kotlin’s most important libraries.

Running custom built paywalls alongside RevenueCat Paywalls

Tue, 10 Feb 2026 14:24:01 GMT

RevenueCat paywall offers powerful customization of paywalls that render full native views. However, there might be situations where you want to implement your own custom paywall while still leveraging RevenueCat to manage entitlements, offers and packages. This blog post will guide you through how to effectively run your custom paywall alongside a RevenueCat-powered paywall.

Why run multiple paywalls?

You might be wondering why you’d want to manage multiple paywalls simultaneously. Here are a few scenarios where this approach can be highly beneficial:

Transition periods: You might have built a custom paywall before and are interested in progressively moving away from it to RevenueCat paywalls.
A/B testing: You have your existing hard coded paywall, and you’ve now built a new paywall in RevenueCat that you want to test against.
Targeted offers: For specific user segments, you might have unique pricing or promotional offers that require a highly customized presentations,
Advanced logic: For complex onboarding flows or specific user journeys

Your app decides which paywall UI to show, but all purchases still flow through the RevenueCat SDK. This avoids duplicated logic, pricing mismatches, and entitlement bugs while giving you full control over presentation when needed.

Example end-to-end flow with

At a high level, an app with two different paywall types functions like this:

User reaches a paywall decision point
- For example: end of onboarding, feature gate, or promotional entry point
App requests Offerings for a specific Placement
- The Placement represents where the paywall is shown in the user journey
RevenueCat returns the appropriate Offering
- The returned Offering may vary per user based on targeting rules
App inspects Offering metadata
- Metadata determines which paywall should be displayed
App chooses a paywall UI
- RevenueCat paywall UI
- Or a fully custom built paywall UI
User selects a product
- Product and pricing data always come from RevenueCat
Purchase is initiated via the RevenueCat SDK
- Identical purchase flow regardless of paywall UI
RevenueCat updates entitlements
- App unlocks or restricts content based on CustomerInfo

This keeps presentation flexible while keeping the subscription system centralized and consistent. If you make use of RevenueCat’s Experiment feature, you can even test and compare how the different placements and paywalls perform in conversions.

Understanding RevenueCat Paywalls

RevenueCat’s paywalls are designed to simplify the process of displaying your products to users. As outlined in the RevenueCat Paywalls documentation, they allow you to create, manage, and test different paywall designs directly within the RevenueCat dashboard. They handle the fetching of product information and present it in a user-friendly way. All this without having to create new releases of your app when you make changes to your paywall.

For most new apps, implementing your paywall with RevenueCat is the best choice, allowing you to iterate and update your paywall without having to push new releases of your app to stores.

Implementing a custom built paywall

As mentioned earlier, there are cases when RevenueCat paywalls might not be enough. One such case could for example a key design element in your app that you want to also show in your paywalls. In a gamified app this could be for example a broken streak visualisation, that you want to surface in the paywall to communicate to the customer that subscription would allow them to amend the broken streak.

When you decide to implement a custom built paywall, you’re essentially taking control of the UI/UX. However, you’ll still rely on RevenueCat SDK for the backend operations: fetching product information and making purchases.

Step 1: Fetching Product Information

The first step in your custom built paywall implementation is to fetch the product information from RevenueCat. This is crucial for displaying the correct subscription options, prices, and introductory offers to your users. Refer to the Displaying Products documentation for detailed instructions.

In Swift, you’ll typically use the Purchases.shared.getOfferings() method to retrieve your configured offerings. Similarly, on Kotlin, you’ll use Purchases.sharedInstance.getOfferingsWith().

This will provide you with the Offering object, which contains all the necessary product details:

Step 2: making purchases

Once a user selects a product on your custom built paywall, you’ll use RevenueCat’s SDK to initiate the purchase. The Making Purchases documentation provides comprehensive guidance on this.

On iOS, you’ll use Purchases.shared.purchase(package:), and on Android, Purchases.sharedInstance.purchaseWith(). Remember to handle the purchase completion and any potential errors.

Step 3: Entitlement Management

Regardless of whether you use a RevenueCat paywall or a custom one, RevenueCat will handle entitlement management. After a successful purchase, RevenueCat will update the user’s CustomerInfo, which you can then use to grant or restrict access to premium features. In Swift you can do this using the Purchases.shared.customerInfo()

In Kotlin

Conditional display logic for paywalls

You can control the logic for showing different paywalls and offerings using either Placement or Offering metadata. With Placement you can define where each type offering is shown, and with Offering medata you can attach additional information to the offering that is then used in the app to differentiate between showing a custom built paywall or a RevenueCat paywall.

Targeting by Placement

Using Targeting by Placement you can define paywalls locations in your app to serve unique Offerings at each paywall location. This could mean for example displaying a different paywall at the following different locations:

At the end of onboarding (e.g. onboarding_end)
When a customer attempts to use a paywalled feature (e.g. feature_gate)
When a sale is running (e.g. sale_offer)

The basis for deciding Placements is to understand how they would compliment your ideal customer journey. If you’re running a sale, you most likely want to show a different offer and copy to onboarded customers, compared to those using the app for first time. Do this by defining a sale_offer placement.

When your app fetches Offerings by Placement, RevenueCat returns the Offering to be displayed for that customer at that Placement, letting you display unique paywalls based on the customer journey. In Swift you can accomplish this in the following way:

Similarly in Kotlin:

Targeting using Offering metadata

The key to running different types of paywalls and customizing what is shown in your custom built paywall is Offering metadata. In the RevenueCat dashboard you can add valid JSON in to the Metadata field, by navigating to an Offering and clicking Edit or Configure metadata (in case you haven’t configured metadata yet):

Metadata that you configure in the dashboard could look like this for example:

This metadata is attached to the Offering data when you call the SDK to get available Offerings. You can then use it to dynamically make changes to how paywalls are displayed in your app.

Using Offering metadata with the SDK

You can access metadata directly from the Offering object in RevenueCat SDK using the offerings method in Swift

and in Kotlin with the same method:

Metadata values are optional by nature, so all access should be built so that your app and paywalls still work even if the values are not defined in the dashboard.

Example Conditional Logic

Now the last remaining step is to use the logic for showing your custom built paywall or a RevenueCat paywall:

and in Kotlin:

Conclusion

Running your own custom built paywall alongside a RevenueCat paywall provides flexibility for experimentation and targeted offers. By leveraging RevenueCat for product fetching and purchase management, and your engineering skills for custom UI, you can create a highly optimized and engaging subscription experience for your iOS and Android users. This hybrid approach empowers you to maintain control over the front-end presentation while relying on a robust, battle-tested backend for your subscription infrastructure.

R.I.P. toggle paywall: we hardly knew ye

Mon, 09 Feb 2026 15:34:08 GMT

UPDATE: APRIL 23, 2026

As Axel Le Pennec (@alpennec) pointed out on X, it seems subscription giant Flo Health has found an alternative to the toggle paywall, which appears to be compliant with the latest Apple Guidelines.

Flo have replaced their “Enable free trial” toggle with a specific 14-day free trial plan option when showing a multi-plan paywall. Keeping the same “Not sure yet?” copy, this feels like the closest subscription apps can get to matching user intent within this paywall moment, while staying within the guidelines Apple has set.

Credit: Axel Le Pennec

It started with a few whispers, then a handful of tweets. Now, it’s a full-blown trend we can’t ignore. Over the past few weeks, we’ve had several industry figures reach out to us, all asking some version of the same question: “Is Apple killing the toggle paywall?”

Short answer: yes. It sure looks like it

Developer after developer is getting the same rejection notice from App Review, and it’s always about the same thing: a paywall design that includes a toggle to turn a free trial on or off. If you’re using this pattern on iOS, you need to pay attention. This isn’t a drill

What is the toggle paywall?

For the uninitiated: the “toggle paywall” is a paywall design where users are presented with a subscription offer and a toggle switch that lets them add or remove a free trial. In most implementations, the toggle defaults to off – meaning the user sees a plan without a trial. If they flip the switch, they get a different plan (usually weekly instead of annual) that includes a trial period

The mechanic was popularized by Adam Lyttle in mid-2024, when he documented how implementing this exact design doubled his weekly app revenue from ~$2,500 to over $5,300. The numbers were staggering. His introductory offer conversion rate hit 63%, and subscription retention sat at 68%

It was a masterclass in behavioral psychology. The toggle defaulted to “off,” with the cheaper-looking annual plan pre-selected. Users who wanted the free trial had to actively flip the switch, which then moved them to the more expensive weekly plan. Many users, seeing the lower annual price, would just hit “continue” without toggling, skipping the trial entirely and paying upfront. The result? A massive boost in immediate revenue and a higher average revenue per user (ARPU)

It was so effective that it spread like wildfire. Within months, you could see variations of the toggle paywall in apps across the App Store. It became the go-to strategy for developers looking to juice their monetization. We even featured it in our own paywall redesign case studies, where one app saw a 17% boost in ARPU and another saw a 64% uplift in revenue after implementing it

But here’s the thing about patterns that feel a little too effective: eventually, the platforms catch on

The rejection wave

Starting in mid-January 2026, the rejections started rolling in. Axel Le Pennec was one of the first to post about it publicly, sharing a screenshot of Apple’s rejection notice along with a resigned “My app got rejected for that”. Adam Lyttle himself – the man who popularized the pattern – quote-tweeted it the very next day with a simple, three-word eulogy: “RIP paywall toggle”

Since then, the reports have kept coming. Aivars Meijers, Sergey, Ingo, and others have all shared their rejection stories. A Reddit thread about it has dozens of developers confirming the same experience. It’s not an isolated incident – it’s a pattern

The rejection notice from Apple is brutally clear:

Guideline 3.1.2 – Business – Payments – Subscriptions

The purchase screen includes a toggle to add or remove a free trial from the subscription purchase. This design is confusing and may prevent users from understanding that they are committing to an auto-renewing subscription that will begin charging them after the free trial period.

Next Steps: Remove the toggle for adding or removing a free trial from the subscription purchase screen. Users should be presented with a clear subscription offer that explicitly states whether a free trial is included.

No ambiguity there

Why now?

So why is Apple cracking down on this now, after the pattern has been in wide use for over a year?

The honest answer is: we’re not 100% sure. Apple hasn’t published an explicit policy update or blog post about it. But we can connect a few dots

First, Apple has been on a broader mission to clean up subscription practices for a while. Their guidelines on subscriptions (3.1.2) have always emphasized transparency, and their scam-prevention rules (3.1.2(a)) specifically call out apps that “trick users into purchasing a subscription under false pretenses” [10]. The toggle, with its default-off state, arguably falls into that bucket. A free trial that you have to opt into via a hidden toggle is, from Apple’s perspective, a trial that most users will never see – which defeats the purpose of offering one

Second, the pattern became too popular. When a handful of indie apps use a clever design, it flies under the radar. When thousands of apps across the store are using the same mechanic- and when YouTube videos about it are racking up tens of thousands of views – it gets noticed. Apple’s App Review team is clearly aware of the trend, and they’ve decided it crosses the line

Third, and perhaps most importantly: users were getting confused. The whole point of the toggle was that many users wouldn’t toggle it. That’s not transparency – that’s obfuscation. And Apple, whatever you think of their policies, has a legitimate interest in making sure users understand what they’re signing up for

The plot twist: It’s only dead on iOS

Okay, so the toggle paywall is dead. Pour one out. We hardly knew ye

But wait – it’s dead on iOS. And that’s an important distinction

As of today, there is no indication that Google has any issue with this design. The same goes for web-based paywalls. If you’re running a multi-platform app, the toggle might still be a viable, high-performing strategy on Android and the web

This is where having a flexible, remotely configurable paywall setup becomes essential. With a tool like RevenueCat, you can use Targeting to display one paywall on iOS (compliant, toggle-free) and another on Google Play or the web (the classic, high-ARPU toggle design). Don’t throw the baby out with the bathwater – just make sure you’re showing the right paywall on the right platform

What to test instead

So, what’s an iOS developer to do? Get back to the drawing board. The good news is that there are plenty of high-converting, fully compliant paywall designs to test. And some of them might actually convert better than the toggle ever did

Here are the patterns we’d recommend testing first:

1. The “honest” timeline paywall

The famous ‘Blinkist paywall’

This design, popularized by Blinkist, shows a clear, step-by-step timeline of what happens after the user taps “Start Free Trial.” Something like: Today: Full Access → Day 5: Reminder → Day 7: You’re Charged. Blinkist reported a 23% increase in conversion rate and a 55% drop in complaints after implementing this pattern. It builds immense trust, and in many cases, trust converts better than tricks

2. The multi-package selector

Instead of toggling a trial on and off, present multiple subscription packages side by side – say, weekly, monthly, and annual. Badge the one that includes a trial. Users select the package they want; no toggle needed. The trial is inherent to the package, not a separate mechanic. This uses classic price anchoring to make the annual plan (with the trial) the obvious choice

3. The value-first paywall

This approach front-loads the value proposition. Strong visuals, benefit-oriented copy, social proof, App Store ratings – all before the user ever sees a price. When users are genuinely convinced of the value, the friction of payment decreases significantly. Shift the conversation from “how much does it cost?” to “what am I getting?”

4. Personalized paywalls with conditional visibility

This is the more sophisticated play. Use conditional logic to show different paywall content based on user attributes – like whether they’re eligible for an introductory offer. If they are, show trial messaging prominently. If they’re not, show a direct purchase flow. No toggle required, and the experience is tailored to each user. RevenueCat supports this through Targeting and conditional visibility in our paywall builder

5. The exit offer

Duolingo has been experimenting with a ‘web purchase-first’ paywall design

What if you could get a second chance to convert a user who’s about to leave? That’s the idea behind an exit offer. When a user dismisses your paywall, instead of just closing the screen, you can present them with a different, often better, offer. Think a lower price, a longer trial, or a monthly plan after they’ve rejected an annual one

We just shipped this feature in our Paywall Builder. It’s all configured remotely, no code changes needed. It’s a great way to capture intent that would otherwise be lost. But be careful: Apple is also getting stricter on instant paywall abandonment offers, so test this one carefully and make sure it doesn’t feel like you’re trapping the user

6. The web purchase button

Here’s a curveball: route your US-based iOS users to a web checkout entirely. You avoid Apple’s 30% commission, you have full control over the purchase flow, and you can design whatever paywall you want – toggle included – because Apple’s App Store guidelines don’t apply to web purchases. Note that you still have to include in-app purchases in your in-app screen, but you can offer a discount on web (or increase your prices in-app) to nudge people towards the web option. We’ve shipped a Web Checkout Button component that makes this easy to test. The results have been… interesting.

Alternative	Key benefit	Compliance risk
Timeline / “Honest” Paywall	Builds trust, reduces refunds, proven conversion lift	None
Multi-Package Selector	Clear, uses price anchoring, no toggle needed	None
Value-First Paywall	Shifts focus from price to value	None
Personalized / Conditional Paywalls	Tailored experience per user segment	None
Exit Offer	Second chance to convert abandoning users	Low (if not overly aggressive)
Web Purchase Button	Full design freedom, avoids 30% commission	None (web rules apply)

The key is to start experimenting now. Don’t wait for your next app update to get rejected. Proactively test these alternatives and find a new champion for your iOS paywall

One more thing

Here’s an interesting data point that might ease the pain. Ludwig Henne, founder of Fits, ran an A/B test comparing a Adam Lyttle-style toggle paywall against a Blinkist-style honest paywall. The toggle paywall won on ARPU (+19%), but when he isolated the toggle mechanic specifically, he found that the toggle itself wasn’t the main driver. The real conversion lift came from the visual hierarchy: normalized yearly pricing, a “Most Popular” badge, and a larger UI for the annual plan

In other words, you might be able to remove the toggle and keep most of the revenue gains – as long as you maintain the other design elements that made the paywall effective. The toggle was the headline act, but the supporting cast was doing most of the heavy lifting

The end of an era

The death of the toggle paywall on iOS marks the end of an era. It was a wild ride, and it made a lot of developers a lot of money. But the App Store is Apple’s house, and they make the rules

Ultimately, this is probably a good thing for users. And what’s good for users is, in the long run, good for the ecosystem. It forces all of us to be more creative, more transparent, and more focused on communicating the genuine value of our products. The best paywalls have always been the ones that make users want to subscribe, not the ones that trick them into it

So pour one out for the toggle paywall. And then get back to testing

RevenueCat React Native SDK adds React Native Web support

Mon, 09 Feb 2026 11:13:50 GMT

Starting from release 9.7.6 of react-native-purchases, teams building with React Native can manage subscriptions across iOS, Android, and web using the same SDK and the same RevenueCat entitlements system. If your app already runs on mobile and you’re extending it to the web — or you’re starting with a shared codebase from day one — this makes it easier to support subscriptions everywhere without rethinking your architecture.

Add react-native-purchases to your Expo or React Native project, and you have power subscriptions, in-app purchases, entitlement management on three different platforms with a single code-base.

Why we built this

As more React Native apps expand beyond mobile, the web has become part of the product rather than just a marketing surface. Teams want users to sign up, upgrade, or manage subscriptions in a browser, while still unlocking access inside their iOS and Android apps. Until now, that often meant maintaining a separate billing system for web and stitching everything together with custom logic.

React Native Web support removes that split. Web purchases flow into the same RevenueCat backend as native purchases, so you can rely on a single entitlements system instead of reconciling multiple sources of truth.

How billing works on web

On iOS and Android, RevenueCat integrates directly with the App Store and Google Play. On the web, purchases are handled through RevenueCat Web Billing, which uses Stripe or Paddle as the payment processor. Web Billing is separate from native in-app purchases, but it connects to the same entitlements system, making it possible to grant access across platforms using a shared appUserID.

From your app’s perspective, subscription state stays consistent regardless of where a user originally subscribed. A customer who signs up on the web can immediately access premium features on mobile, without you needing to write platform-specific logic.

Getting started with React Native Web

Enabling React Native Web support starts with configuring RevenueCat using the appropriate API key for each platform. When your app runs on the web, you’ll initialize the SDK with a Web Billing public API key, while iOS and Android continue to use their native keys.

Here’s what that looks like in practice:

Once configured, entitlement checks work the same way across platforms. Your app logic doesn’t need to branch based on where a subscription was purchased.

To enable web purchases, you’ll also need to create a Web Billing app in the RevenueCat dashboard and configure your products for web. These live alongside your iOS and Android products, but are billed through Web Billing rather than native stores.

Using Expo

If you’re building with Expo, React Native Web support also improves the development experience. You can preview subscription UI, test entitlement logic, and validate integration flows directly on the web without immediately creating a custom development client. This makes it easier to iterate early and confirm that your setup works end to end.

To fully test real in-app purchases on iOS and Android, you’ll still need an Expo development build. Web support doesn’t replace that requirement, but it does remove a lot of friction during early development.

Current limitations

Because web billing works differently from native app stores, there are a few limitations to be aware of. Web purchases require RevenueCat Web Billing and can’t process native iOS or Android in-app purchases. In addition, some operations that depend on native store APIs aren’t supported on web environments, including getProducts, purchaseProduct, and restorePurchases. Expo Go and similar sandbox enviroments don’t support purchasing either.

Users can manage their web subscriptions through the RevenueCat-hosted customer portal, which provides a consistent way to update or cancel subscriptions outside of native app stores.

What’s next

As subscription apps increasingly span mobile and web, we’re continuing to invest in making cross-platform subscription management simpler and more reliable. React Native Web support is a foundation for that work, and we’ll keep improving the experience as teams push it further in production.

If you’re already using RevenueCat with React Native on mobile, adding web support is now a natural next step.

You can still win Shipyard — multiply your changes by shipping to another brief

Fri, 06 Feb 2026 12:30:16 GMT

There are less than six days left to submit your final entry to Shipyard, and if you’re thinking you’re already too late, I have just one word for you: wrong.

Even if you haven’t started building yet, there’s still enough time to get an app to beta and ship it through TestFlight or Google Play’s testing tracks. Shipyard isn’t about perfection, it’s about shipping — and a focused MVP can absolutely be competitive at this stage. And if you already have one app ready to submit, this is your chance to multiply your odds by building and submitting another app for a different brief.

In this post, we’ll walk through a few of the creator briefs and explore concrete ideas for how you could realistically ship an app for each of them. The goal is to help you move from “maybe” to “shipped,” even if you’re starting late or considering a second (or third) submission.

Make use of the vibecoding tools included in the Shipping Container

Anthropic recently released a new version of their Claude Code Opus 4.6 model, and it’s already supported by the tools included in the Shipping Container. That means you’re not just reading about more powerful AI-assisted coding, you can actually use it right now, as part of Shipyard, without any extra setup.

With these tools, building an app is no longer about writing everything from scratch or spending weeks on boilerplate. You can scaffold features, iterate on UI, and explore ideas at a pace that simply wasn’t possible before. Shipyard is a perfect excuse to take these tools for a real-world test drive and see how far you can get in a single weekend with focused execution.

Briefs that you could target

Shipyard offers seven different creator briefs for you to choose from, and you’re allowed to submit one app for each brief. That gives you a lot of flexibility — but it also comes with a few important constraints. You can’t submit multiple apps to the same brief, and you can’t submit a single app to multiple briefs. Each submission needs to clearly map to one brief, so it’s worth being deliberate about which problems you decide to tackle.

With just about a week left to build, it’s easy to assume that the window has already closed — but that’s not the case. To show what’s still possible, we’ve picked a few very different briefs and explored how you might realistically approach each of them in a short time frame. The goal isn’t to overwhelm you with ideas, but to help you see how a focused MVP can still be competitive.

Whether you’re only now jumping into Shipyard, or you already have one app submitted and are considering building a second — or even a third — these examples should give you a clearer sense of how to scope your work, pick the right brief, and maximize your chances of shipping something meaningful before the deadline.

“Investment tracker for all assets” — Josh from VisualFaktory

Investors juggle stocks, gold, funds, fixed income, real estate, and more across multiple platforms — messy to track and hard to understand at a glance. Josh wants a single app where users can log everything, get real-time price updates where possible, set amortization/reminder alerts for non-listed products, and unlock premium risk + diversification analysis (like country/sector exposure).

This brief can seem intimidating at first. Supporting many different asset types sounds complex, but it’s exactly the kind of problem modern LLMs excel at: turning messy, unstructured information into clean, usable data.

A strong approach is to lean on the APIs from OpenAI, Anthropic, or Google and build an app that accepts almost any input — spreadsheets, screenshots, PDFs, or dictated descriptions — and converts them into structured assets your app can work with. The key is designing prompts that normalize the data and then visualizing it clearly. You can also use AI to analyze the portfolio and generate insights, pulling in real-time finance data when needed.

On the business side, this works naturally with usage based pricing. Using RevenueCat’s virtual currencies, you could offer AI-assisted imports and advanced risk analysis as credit based features, tying monetization directly to value delivered.

“Powerful reminders with cross-device sync.” – Sam Beckman

Sam lives by reminders, but switching between Android and iOS means rebuilding his entire system from scratch. He wants a beautiful, fully functional reminders app on both iOS + Android* with custom snoozes from notifications, powerful recurring rules, and true sync so dismissing once clears everywhere.

*For the purpose of the hackathon, you only need to build an MVP for iOS or Android

This brief is fundamentally about cross-platform thinking. Frameworks like Flutter, Kotlin Multiplatform, and React Native are a natural fit here — and if you’re building with React Native, you’re in especially good shape. Tools like Rork, Blink, Fastshot, Vibecode, and Replit make it surprisingly easy to scaffold and ship polished React Native apps quickly.

The app itself is once again the easy part. The real challenge — and the real opportunity — lies in reminders and notifications. Doing this well requires reliable sync and state management across devices, which usually means running your own backend. Instead of building everything from scratch, you can lean on tools like Firebase or Supabase to get a real-time database, auth, and sync set up quickly, without spending your limited hackathon time on infrastructure. Supabase especially, has a really good MCP, which you can make use by telling your AI agent to set up everything there

With a focused MVP, even a single-platform reminder app with rock-solid notifications and sync can stand out. Especially if it’s beautifully designed and clearly solves a problem Sam’s audience deeply cares about.

Dating and making friends on the road is hard when you’re always moving—and van life is a tight, protective community. Quin wants a van-life app with nomadic dating, activity-based friend finding, and even a paid ‘builder help’ section for van projects, with invite-only or verified access to keep it safe and intentional.

This brief gives you a chance to flex skills you don’t often get to use: building a social network from scratch. The surface level requirements are fairly simple, but making this work will still require a backend for accounts, messaging, and locationaware discovery. For tooling and infrastructure, it’s worth revisiting the previous brief for suggestions on how to get this set up quickly.

Where this brief really stands or falls is differentiation. To stand out, you need a clear hook that immediately resonates with van-lifers. One approach could be building a kind of mobile friendship book, where you collect connections as you travel from place to place. Layer in location based discovery and messaging, and you already have a well scoped app that feels built for this community.

Wrap up

Hopefully this post sparked a few ideas, whether that means submitting your very first app to Shipyard, or doubling down with a second one. If you’re still feeling stuck on what to build, how to scope it, or how to turn your work into a compelling story, I’d recommend checking out another post I wrote for exactly that situation, modestly titled How to win Shipyard.

With only a few days left before Devpost submissions close, it’s also worth revisiting the mechanics of a strong submission. I’ve covered that in a separate post,How to submit your app for Shipyard, where I break down what you actually need: a working app, a clear description, and a short three minute video showcasing what you built. That video matters more than most people expect, so make sure you spend some time getting it right.

Now get hacking.

Why hybrid monetization is the default model for subscription apps in 2026

Thu, 05 Feb 2026 17:38:12 GMT

At the start of the year, we always see a deluge of prediction articles. In January 2022 on this very blog, I mentioned the rise of hybrid monetization for subscription apps. I spoke about this prediction multiple times, for Techcrunch and at in-person events.

At the time, it didn’t take off. The pressure wasn’t strong enough yet. Fast forward a couple of years, and AI has quietly turned usage into a revenue drag. 2025 showed signs that hybrid monetization was on the rise, but in 2026, pretending otherwise will be fatal for subscription apps. 2026 is the year of take off for hybrid monetization!

Incidentally, this 2022 blogpost was also where I discussed non-store payment options — and here we are now in 2026 with new uncertainty following App Store’s term changes…

Before we jump into what moving your growth model towards hybrid monetization means for subscription apps, let’s look at the ‘why now’. (Spoiler alert: it’s AI again.)

Pre-AI: subscriptions won because marginal costs were invisible

For most of the past decade, subscription apps benefited from a hidden advantage: there were virtually no variable costs, whether you served one user or one million users — development and design aside, serving an additional user was effectively free.

That shaped how the entire pricing ecosystem evolved:

Flat pricing felt fair
Power users were an upside, not a risk
Monetization focused on conversion and retention, not cost containment

We couldn’t imagine a time where more users or more active users could be a bad thing. This is why ‘all you can eat’ subscriptions became the norm outside of gaming. The model worked because the economics were forgiving.

AI breaks that forgiveness. 2026 is the year this shift becomes impossible to ignore. Not because AI is new, but because its economics are now colliding with a maturing subscription market.

The growing cracks

Lately, subscription-based apps are ‘winning’ the App Store. We see non-gaming App Store revenue overpassing the flatlined gaming sector and attracting founders, talent, capital, tools and more (many of whom are from the gaming vertical, ironically). But things are getting harder.

The cracks in the all-you-can-eat subscription model have been visible for years, but today they’re becoming an increasing headache for app profitability:

Plateauing ARPU
Converting barely a low single digit of user to premium features
Rising churn
Declining marginal returns from optimization
Growing concerns for subscription fatigue

Why now? Three underlying factors accelerating hybrid

Predicting hybrid monetization’s rise back in 2022 was early. What’s different in 2026 is that multiple pressures are converging at once.

There are several factors that are making the shift to hybrid monetization not a nice-to-have but a necessity:

1. AI has massively increased competitive density

AI-assisted development has seen the amount of new apps explode. Vibe coding has lowered the cost of shipping and iterating apps. More teams are building faster, copying proven monetization patterns, and competing in the same categories.

The result: more apps, similar funnels, and less room for monetization mistakes.

2. Optimization is no longer a lasting edge

Paywall design, pricing tests, and onboarding flows used to be meaningful differentiators. Today, they’re table stakes. Today, paywall optimization is showing declining marginal return: it’s no longer a competitive edge, see it as a base requirement!

Vahe Bagdasaryen once made $1m selling easy-to-apply paywall layouts in his first year of consulting — great, but now everyone is using the same layouts (hence the limits of Blinkist-like paywalls). These tactics are mandatory to master, but they quickly become commoditized; incremental gains shrink while costs keep rising as new apps vie for attention in the same few places.

3. User acquisition keeps getting harder

Attention hasn’t scaled with supply. More apps, same amount of eyeballs on the Tiktok feed or the App Store. User acquisition (UA) costs continue to climb, while conversion rates and ARPU plateau in many non-gaming categories. Ad bids are harder to win, big fish are taking over ASO real estate, and there’s more competition than ever. Increasing ARPU by 20-25% yearly is just the beginning to compensate for UA inflation, it’s only what comes on top that is a win.

Why now? The variable cost of AI is an ignition towards hybrid monetization

For a long time, most subscription-based businesses had variable costs of virtually zero. AI-based features make this obsolete. It’s a structural break: apps using AI as part of their core value are actively spending more money with each user they acquire.

If your most engaged power users cost more than they pay, or free users can generate cost, the model needs to be rewritten.

While primarily thought for SaaS businesses, Anh Tho Chuong’s article So you want to price your AI features is applicable to any AI app:

“The zero marginal cost era of software is over the minute you touch LLM APIs. AI has real COGS and it is something we will have to learn to deal with.” — Anh Tho Chuong, CEO & Co-founder of Lago

High variable cost means a few outliers can literally bankrupt you. But it also threatens the ‘all-you-can-eat’ nature of most subscription-only models:

Power users were your best asset, now they can become a liability!
Free users were generating indirect value for free (ratings, virality, late conversions…) but now carry negative unit economics
Free trials have to be thought very differently
ARPU averages hide catastrophic tail risk

It doesn’t mean subscriptions shouldn’t be the core of monetization for AI-based apps, but there is the need to build on top and adjust to those costs. I’m aligned with Anh Tho’s bet that hybrid pricing will be more common, keeping recurring revenue stable while increasing LTV.

Put together, the variable cost of AI plus the pressures discussed above look like this:

More app competition + similar monetization and acquisition playbooks + higher variable costs = a forced evolution of the subscription monetization model.

But what does that model look like in practice?

Access is predictable: subscriptions still anchor revenue, expectations, and retention
Consumption is bounded: usage-heavy behaviors are capped, metered, or monetized separately
Power users self-select into higher spend: instead of being subsidized by everyone else, they fund the costs they generate.

Here are two inspirations to move you to action:

Learn the fundamentals: my recent article covers how subscription apps can capture more revenue through hybrid monetization, outlining key techniques and models, with real app examples.
Delve into the specifics: Alice Muir Kocourková wrote a detailed explanation of how AI has disrupted app pricing models, with examples of how AI apps are pricing their top features.

Hybrid monetization is the natural evolution

Despite all of the above, I still believe subscriptions are a powerful model — just not in the static, all-you-can-eat form that has dominated monetization, retention, and acquisition for the past decade.

All these factors are pushing for the natural next phase of model maturity: it’s not about abandoning subscriptions at all, but getting smarter and building on top.

AI apps barely have a choice. AI apps need to better reflect the usage-based costs of heavy users. But this isn’t just for AI apps. Even apps without heavy AI features now compete in markets shaped by these dynamics — even without the variable cost issue, growth is business model competition.

What to do if you’re building a subscription app today

This blog isn’t a tactical checklist per se, but there are a few directional implications from my observations which are hard to ignore:

If your app has AI features: you’ll eventually need to separate access from consumption; ignoring this early only makes the correction more painful later, and risks you being swamped by competition
If your app doesn’t use AI (yet): don’t rest on your laurels or think you’re exempt from the pressure — you’re still competing in an ecosystem shaped by AI economics, so expect pricing shifts, faster imitation, and shorter monetization half-lives
If you’re early-stage: defaulting to all-you-can-eat subscriptions is no longer the safe choice it once was — design pricing that can evolve as usage patterns emerge, but consider the added complexity of hybrid models

Ultimately, the wisest thing you can do is keep an eye on your revenue streams. Watch for any outliers or heavy users if you have AI variables, and start thinking how you can protect your pricing model against the coming changes.

The bottom line

Subscriptions aren’t failing. They’re being asked to do a job they were never designed for.

AI makes usage expensive. Hybrid monetization is how subscription apps adapt, by preserving predictable revenue while aligning pricing with real costs and value. 2026 is the year hybrid monetization stops being an experiment and becomes the default shape of modern subscription businesses.

Your Shipyard: Creator Contest questions answered

Wed, 04 Feb 2026 17:19:28 GMT

It was great to see so many of you join our Shipyard LIVE on Tuesday. We didn’t have time to answer every question live, so we’ve pulled together the most commonly-asked ones here. We hope this info helps on your journey to building a monetizable MVP — keep building, and we’ll see you at the finish line!

Building your app

Q: Can I build for both iOS and Android?

A: Yes. Cross-platform frameworks like React Native or Flutter are allowed — your app just needs to be a mobile app (iOS or Android).

Q: How do I get access to the Shipping Container?

A: Once you register for the contest on Devpost, you will receive an email within 48 business hours with information on how to redeem all of the offers. Reach out to our team in Discord if you encounter any issues.

Q: Do I need to use the tools included in the Shipping Container?

A: No. You are free to use any tool you want; it’s not a requirement to use the tools contained in the Shipping Container to build your app, and this does not impact judging.

Q: Do I need a working backend, or is it enough to have demo userflows that explain the function and demonstrate how it should work?

A: Everything in the app should be working. Your backend doesn’t need to scale to a large user base — this is an MVP — but documentation or user flows alone aren’t enough.

Q: Does a TestFlight Expo app that uses WebView for some screens still qualify, or does it need to be fully native to be compliant?

A: An Expo/React Native app distributed via TestFlight still qualifies, even if some screens use a WebView. More information on using RevenueCat with React Native is available in our documentation here.

Monetization

Q: Is a RevenueCat integration required?

A: Yes, your app must have RevenueCat installed and active to be eligible.

Q: Is an integration with RevenueCat’s Test Store sufficient?

A: No, this does not count as an integrated SDK. More info here.

Q: Do I have to charge for my app, or can I just use RevenueCat to introduce a ‘Donate to Developer’ experience?

A: Yes — this is allowed and within the rules. That said, creators are ultimately looking for apps that meaningfully monetize their audience, so you should think carefully about whether this approach aligns with the brief.

Q: How do I decide what features to monetize? How do I price correctly?

A: This is up to you. You should be pitching how and why you’d monetize your app as part of your submission — not just what you’d charge for. Hear more from our Judges on this here.

Submission and testing

Q: Do I need to publish to the App Store?

A: Apps must be accessible via TestFlight (iOS) or Play Internal Testing (Android). Your app does not need to be on the public stores (App Store or Google Play Store). If your app is also live on an app store, this will not affect the judging of your submission (positively or negatively).

Q: Can I submit multiple projects for the same brief?

A: No, you can only submit one submission per brief (seven submissions total). Choose wisely!

Q: Can changes be made after the Feb 12 deadline? How do we know which version of the app will be judged?

A: Yes, you can continue working on your app after the Feb 12 submission deadline. The Intellectual Property remains yours, and we can’t (and don’t want to) restrict ongoing development.

However, you should clearly specify which version of your app is being submitted for judging in your Devpost submission. Judges will evaluate the version you reference there and the one that features in your demo video.

Q: Do I need to upload to GitHub if the app is vibe-coded?

A: No. You don’t need to upload your code to GitHub.

Q: What tester emails should I use for TestFlight or Play Internal Testing?

A: All the information on how to submit, including what tester emails to use, is available here.

Q: Should I ensure the judges can access and test premium features, or will seeing a paywall suffice?

A: You should ensure all the features that you want the judges to evaluate are available.

Q: Since the App Store URL is allowed, can we provide instructions to redeem free credits for judges to test the app?

A: Yes, this is fine.

Judging

Q: For the video submission, should I screen record on my phone to demo the app, and do I need to have a face cam?

A: Up to you! How you record the feature and whether you feature yourself/voice/face in it is entirely your call. The only thing that will affecting judging is the quality of your app and the effort put into submission — better quality videos or more engaging demos might stand out more, but you won’t be penalized for not showing your face.

Q: Will the Creators use my app or just watch the demo video I provide?

A: Due to the expected number of submissions, we can’t guarantee that every app will be fully installed and tested. The only requirement is that judges watch your demo video — this is how all submissions are reviewed before shortlisting. Shortlisted submissions will be fully tested. Make sure your video clearly shows the core experience and value of your app. Hear more about this here.

Q: How long should my demo video be?

A: We recommend keeping your demo video to 2–3 minutes. Shorter videos may hold attention spans more, but judges will watch videos of any length. This isn’t a hard limit — longer videos won’t be rejected.

Q: Should we disable paywalls for testing?

A: No, don’t worry about this. In TestFlight and Play Internal Testing, the transactions won’t be charged.

Q: Are sandbox purchases sufficient, or do the Judges need to see a real transaction flow?

A: TestFlight / Sandbox purchases are sufficient.

Q: What would you say matters more, how the app looks and feels, or the level of functionality?

A: See the response from our judges here.

Q: Will it impact the judging if a Creator specifically mentions a preference for iOS vs. Android?

A: If a creator mentions a platform preference, it’s smart to factor that into what you build. It can help your app better fit their audience.

That said, you won’t be disqualified for building on the other platform. If you do, make sure to explain your choice and include a clear roadmap for supporting the creator’s preferred platform. Judges will focus on overall audience fit, product quality, and long-term potential — not just the initial platform.

Q: Any bonus points if your app is launched with users?

A: No, judging isn’t based on user numbers. The focus is on the quality of your MVP, how well it fits the creator’s audience, and its monetization potential. Having users won’t hurt, but it won’t give you extra points on its own.

Creator-specific questions

Q: Can you share more information on the Creator’s audience demographics

All the information we have is available here.

Q: Gabby, do your followers typically DM you, and what sort of questions do they ask?

See Gabby’s response here.

Q: Gabby, do you think it’d be useful to include a feature that allows users of your app to interact with one another?

See Gabby’s response here.

Q: Eitan, can I use recipes from your website (https://www.eitanbernath.com/recipes/) in my app?

Yes, you can use recipes from Eitan’s website for the purposes of the hackathon. However, once the competition ends and your app is published to an app store, those recipes will need to be removed. This is to ensure content rights are respected beyond the scope of the contest.

How ElevenLabs builds and grows consumer AI apps without losing speed or clarity

Wed, 04 Feb 2026 13:50:55 GMT

ElevenLabs is best known for pushing the boundaries of voice AI — but what’s just as interesting is how the team turns powerful technology into consumer products that actually scale.

In this episode of Sub Club, host David Barnard sits down with Tanmay Jain (Mobile Growth Lead, ElevenLabs) and Jack McDermott (Mobile Growth Lead, ElevenReader) to unpack how ElevenLabs approaches mobile growth, pricing, launches, and team structure in one of the fastest-moving categories in tech.

What emerges isn’t a story about AI models or technical breakthroughs. It’s a story about clarity, speed, and systems — and the decisions that make those possible.

Below are the most relevant lessons from the conversation.

Pricing should match how users think — not how AI works

One of the biggest wins Tanmay and Jack share came from simplifying pricing.

For ElevenReader, the team moved away from tokens and credits — concepts that make sense internally, but confuse consumers — and instead sold listening time. The result was clearer value communication and materially better conversion.

The lesson is simple but often missed: Abstracting away AI complexity isn’t “dumbing things down.” It’s good product sense.

If users have to learn a new mental model just to understand pricing, friction is already too high.

Small, autonomous pods turn speed into a moat

ElevenLabs doesn’t operate as one large, centralized org. Instead, it functions more like 10–12 small startups inside a single company.

These small, autonomous pods have full ownership — from product decisions to experiments, pricing, and paywalls. That structure allows teams to ship quickly, iterate relentlessly, and stay accountable to real outcomes rather than internal process.

In fast-moving AI markets, this isn’t just an org preference — it’s a competitive advantage.

Earned media compounds — and makes paid growth work better

Jack breaks down how ElevenLabs thinks about launches as compounding assets, not one-off moments.

Each successful launch generates earned media, which increases branded search, improves trust, and lowers the cost of paid acquisition. Over time, this creates a flywheel where narrative, brand, and performance marketing reinforce each other.

Growth isn’t paid versus organic.
It’s the interaction between the two that matters.

Start launches with the tweet thread, not the feature

Before building launch assets, landing pages, or ad creative, ElevenLabs starts with a single test:

Can the value of this feature be explained clearly in a tweet thread?

If the answer is no, that’s a red flag. Writing the narrative first forces clarity and keeps teams focused on user value instead of shipping features that look impressive but don’t resonate.

In practice, the tweet thread becomes the first product spec.

Consumer apps are a strategic advantage for platform companies

ElevenLabs doesn’t see its consumer apps as competing with its platform or API business. They’re a force multiplier.

By being their own best customer, the team uncovers UX friction, performance constraints, and emotional use cases that are hard to see from dashboards or API logs alone. Those insights flow back into the core product, making the platform stronger for everyone.

Mobile isn’t just a distribution channel — it’s a learning surface.

Conclusion: Clarity, Speed, and systems matter more than hype

The core lesson from this episode isn’t about AI at all.

It’s about building systems — pricing, teams, launches, and feedback loops — that let great products move fast without breaking trust or usability.

For founders, growth leads, and product teams working in fast-moving categories, ElevenLabs offers a clear example of how to scale thoughtfully without slowing down.

🎧 Listen to the full episode of Sub Club to hear Tanmay Jain and Jack McDermott break down the experiments, decisions, and trade-offs behind ElevenLabs’ consumer growth strategy.

Handling edge cases in Google Play Billing

Mon, 02 Feb 2026 02:06:07 GMT

Google Play Billing provides a comprehensive API surface for handling in-app purchases and subscriptions on Android. Most developers are comfortable with the standard purchase flow: launch the billing flow, receive a result, acknowledge the purchase, and grant entitlements. But production billing systems must handle a wider range of scenarios that are often underrepresented in tutorials and sample code. Pending purchases, multi-quantity consumables, subscription downgrades with proration, and the ITEM_ALREADY_OWNED response are all situations your app will encounter in the real world, and mishandling any of them can result in lost revenue, confused users, or failed purchases.

In this article, we’ll explore the most common edge cases in Google Play Billing, understand why they occur, examine how to handle each one correctly with the Play Billing Library, and see how RevenueCat simplifies these scenarios so you can focus on your product instead of billing infrastructure.

The fundamental problem: the happy path is not enough

Most billing implementations start from the sample code in the Android documentation:

This handles a successful, immediate purchase. But what happens when the payment is delayed by 48 hours because the user is paying at a convenience store? What happens when the user already owns the item because a previous acknowledgment failed silently? What happens when a subscription downgrade takes effect at the next renewal instead of immediately? Each of these scenarios requires specific handling, and ignoring them leads to support tickets, refund requests, and lost subscribers.

Pending purchases: when payment is not immediate

Not all purchases complete instantly. Certain payment methods, including cash payments at convenience stores, bank transfers, and some carrier billing options, require asynchronous processing. When a user initiates a purchase with one of these methods, Google Play returns a purchase in the PENDING state rather than the PURCHASED state.

Why pending purchases happen

Pending purchases are common in markets where credit card penetration is low:

Payment method	Common regions	Typical processing time
Cash payments (convenience stores)	Japan, Mexico, Indonesia	24-48 hours
Bank transfers	Germany, Netherlands, Brazil	1-3 business days
Carrier billing (some carriers)	Various	Minutes to hours

If your app is available globally, you’re bound to encounter pending purchases. Ignoring this state means users in these regions cannot purchase your products at all — or worse, they see confusing behavior where their purchase ‘disappears’.

Detecting and handling the pending state

The PurchasesUpdatedListener receives pending purchases alongside completed ones. The critical distinction is in the purchaseState field:

The key rule is: do not grant entitlements for pending purchases. The user has not paid yet. Instead, record the pending purchase and communicate the status clearly:

Completing a pending purchase

When the payment is eventually confirmed, your app receives an updated purchase via onPurchasesUpdated or through queryPurchasesAsync. The purchaseState will now be PURCHASED, and you can proceed with acknowledgment and entitlement granting.

However, there is a subtlety: the user might not have your app open when the payment completes. Your backend should handle this through Real-Time Developer Notifications (RTDN). When you receive a ONE_TIME_PRODUCT_PURCHASED or SUBSCRIPTION_PURCHASED notification for a previously pending token, your backend should update the entitlement and notify the user:

Enabling pending purchases in your BillingClient

Pending purchase support must be explicitly enabled when building the BillingClient. Without this, purchases from delayed payment methods will fail entirely:

Starting with Play Billing Library 7, calling enablePendingPurchases() is required. Without it, BillingClient initialization will fail.

The `ITEM_ALREADY_OWNED` response: a common source of confusion

One of the most frequently encountered edge cases is BillingResponseCode.ITEM_ALREADY_OWNED. This response occurs when a user attempts to purchase a non-consumable product or subscription they already own. While it sounds straightforward, the scenarios that trigger it are often surprising.

Why `ITEM_ALREADY_OWNED` happens

The most common cause is not the user deliberately trying to buy something twice. It’s a previous purchase that was not properly acknowledged. Google Play’s acknowledgment requirement means that unacknowledged purchases exist in a limbo state: the user has been charged, but the purchase has not been confirmed by your app. If the user tries to buy the same item again, Google Play returns ITEM_ALREADY_OWNED because the unacknowledged purchase still exists.

This happens more often than you might expect:

The app crashed after receiving the purchase but before acknowledging it
A network error prevented the acknowledgment call from completing
The user force-closed the app during the purchase flow
The acknowledgment API call returned an error that was not retried

Handling `ITEM_ALREADY_OWNED` correctly

The correct response to ITEM_ALREADY_OWNED is not to show an error message. Instead, you should query for existing purchases and process any unacknowledged ones:

This pattern turns a frustrating error into a seamless recovery. The user does not need to know that a previous purchase failed to acknowledge. From their perspective, they tap ‘Buy’ and get the item.

Preventing `ITEM_ALREADY_OWNED` proactively

The best approach is to prevent this scenario by processing unacknowledged purchases on app startup:

Call this method when the BillingClient connects successfully. This ensures that any purchases that slipped through the cracks are recovered before the user encounters problems.

Consumable purchases: `acknowledge` vs. `consume`

For consumable products like in-game virtual currency, extra lives, or token packs, the distinction between acknowledgment and consumption is a common source of bugs. Both are required for consumable products, but they serve different purposes and have different timing requirements.

The acknowledgment and consumption flow

Acknowledgment tells Google Play you’ve delivered the purchased content. It must happen within three days of the purchase, or the purchase is automatically refunded.

Consumption resets the purchase so the user can buy the same item again. Without consuming a product, the user cannot repurchase it, and attempting to do so returns ITEM_ALREADY_OWNED.

For consumable products, you should consume the purchase, which implicitly acknowledges it:

The multi-quantity edge case

Google Play supports multi-quantity purchases for consumable products. A user can buy multiple units of a consumable in a single transaction. The quantity is available in the Purchase object:

If you ignore the quantity field and always grant one unit, users who purchase multiple units will receive fewer items than they paid for. This leads to support tickets and refund requests.

To enable multi-quantity purchases, you must configure the product in the Google Play Console with ‘Allow multi-quantity purchases’ enabled. Additionally, your BillingFlowParams can specify a maximum quantity the user is allowed to select:

The consumption retry problem

If the consumeAsync call fails (due to a network error, for example), the user has received their content but the purchase has not been consumed. This means:

The user cannot buy the same consumable again
The purchase may be refunded after three days if not acknowledged (though consumption implicitly acknowledges)

You should implement a retry mechanism for failed consumptions:

Call retryPendingConsumptions() each time the BillingClient connects, alongside your unacknowledged purchase recovery logic.

Subscription downgrades and proration modes

When a user changes their subscription plan, the billing behavior depends on whether they are upgrading or downgrading and which proration mode you specify. Downgrades in particular have behavior that surprises many developers.

The default downgrade behavior

When a user downgrades their subscription (moves to a cheaper plan), the default behavior is DEFERRED: the downgrade takes effect at the next renewal date, not immediately. The user continues to have access to the higher-tier features until their current billing period ends.

Understanding replacement modes

Each replacement mode has different implications for billing, access, and user experience:

Mode	When Change Takes Effect	Billing Impact	Best For
`IMMEDIATE_WITH_TIME_PRORATION`	Immediately	Remaining time credited toward new plan	Upgrades where user gets immediate access
`IMMEDIATE_AND_CHARGE_PRORATED_PRICE`	Immediately	Prorated charge for remainder of period	Upgrades with fair billing
`IMMEDIATE_AND_CHARGE_FULL_PRICE`	Immediately	Full new price charged, new billing period starts	Premium upgrades
`DEFERRED`	Next renewal	No immediate charge	Downgrades
`IMMEDIATE_WITHOUT_PRORATION`	Immediately	No charge until next renewal	Lateral moves or trials of higher tiers

The deferred downgrade pitfall

The most common mistake with deferred downgrades is checking the subscription state immediately after the purchase flow completes and expecting to see the new plan. With DEFERRED mode, the original subscription remains active with the original product ID until the next renewal. The new subscription only appears after renewal.

This means your entitlement check must account for the transition period:

The linked purchase token on plan changes

When a subscription replacement is processed (whether upgrade or downgrade), a new purchase token is generated. The new purchase includes a linkedPurchaseToken field pointing to the old subscription. Your backend must handle this correctly to avoid creating duplicate entitlements:

Failing to invalidate the old purchase token when processing a replacement is a common bug that leads to inflated subscriber counts and incorrect revenue reporting.

Network failures and retry strategies

Billing operations are network dependent, and network failures or low latency are inevitable. The critical operations that can fail are the purchase flow itself, acknowledgment, consumption, and purchase verification.

The acknowledgment window

Google Play gives you three days to acknowledge a purchase. If you fail to acknowledge within this window, the purchase is automatically refunded. This is a safeguard for users, but it means your acknowledgment logic must be resilient to transient failures:

BillingClient disconnection

The BillingClient can disconnect at any time, and operations performed on a disconnected client will fail. You should implement reconnection logic with exponential backoff:

How RevenueCat handles these edge cases

Each of the edge cases described above requires careful implementation, retry logic, and backend infrastructure. This is where RevenueCat provides significant value by abstracting away the complexity and handling these scenarios automatically.

Pending purchases

RevenueCat tracks pending purchase states internally and updates CustomerInfo when payments are confirmed. Your app only needs to check entitlements:

RevenueCat’s backend processes RTDN notifications from Google Play, so when a pending purchase completes, the entitlement is updated RevenueCat’s server-side. The next time your app queries CustomerInfo, the entitlement is active. No custom notification handling or purchase token tracking is needed on your side. If you’re a sole developer, building the overall backend infrastructure is a ton of resources.

Acknowledgment and consumption

RevenueCat handles acknowledgment and consumption automatically. When a purchase is received by the SDK, it is verified with RevenueCat’s backend, and RevenueCat acknowledges the purchase with Google Play on your behalf. For consumable products, RevenueCat handles consumption after verification. You never need to call acknowledgePurchase or consumeAsync yourself.

This eliminates the entire class of bugs related to failed acknowledgments, missed consumption calls, and the ITEM_ALREADY_OWNED problem.

Subscription plan changes

RevenueCat provides a clean API for subscription upgrades and downgrades through purchaseWith:

RevenueCat handles the linked purchase token logic, entitlement transitions, and deferred downgrade tracking on the backend. Your app simply checks CustomerInfo for the current entitlement state.

Network resilience

RevenueCat’s SDK includes built-in retry logic for all network operations, caches CustomerInfo locally for offline access, and synchronizes with the backend when connectivity is restored. This means your app can check entitlements even when the device is offline:

The SDK distinguishes between stale and fresh data, retries failed operations with exponential backoff, and ensures that entitlements are eventually consistent with the server-side state.

Wrapping up

In this article, you’ve explored the edge cases that separate a sample billing integration from a production one.

Each of these scenarios has a well defined solution using the Play Billing Library directly, but the cumulative implementation effort is significant. You need client-side handling, backend RTDN processing, retry mechanisms, and careful state management across all of them. For teams that want to ship subscription features without building and maintaining this infrastructure, RevenueCat handles these edge cases automatically, letting you check a single CustomerInfo object instead of managing the complexity yourself.

Whether you build the billing infrastructure directly or use RevenueCat, understanding these edge cases is essential. They represent the difference between a billing system that works in testing and one that works reliably for millions of users across diverse markets and payment methods.

As always, happy coding!

— Jaewoong

How to submit your app for Shipyard

Fri, 30 Jan 2026 12:17:47 GMT

Submitting your app to Shipyard should be straightforward, as you don’t need to navigate app store reviews or production release requirements to participate. What matters is that judges can install and evaluate your app reliably during the hackathon.

This article explains exactly what is required, what is optional, and how to submit your app correctly.

Shipyard rule recap

Before you submit your app, make sure your app adheres to the rules of Shipyard:

Mobile apps only — iOS, Android, or cross-platform (no web/desktop apps)
All projects must be started and completed within the hackathon timeframe
Participants can only submit one app for one brief — choose wisely!
RevenueCat integration is mandatory — subscriptions or in-app purchases
Apps must be on TestFlight (iOS) or Play Internal Testing (Android) — you can have the app live on app stores, but this isn’t required
Developers retain full ownership of all intellectual property
If you use an influencer’s name or likeness, you must remove it before public launch (unless agreed with the influencer)
Any post-hackathon collaboration with influencers is separate from RevenueCat

Let’s take a closer look at a few key rules next.

What can you build your app with?

The main goal of Shipyard: Creator Contest is to build an MVP of a mobile app for the selected creators’ audience. You can use any technology (Swift, Kotlin, Flutter, React Native, etc.) or tool (Cursor, Xcode, Claude, Vibecode, Rork, etc.), as long as it produces a mobile app that can be uploaded to either Apple App Store or Google Play Store. This means that web apps are out of the scope of this hackathon. Tools such as Capacitor are allowed, in case you’re turning a web app into a native mobile app.

Your app must have RevenueCat integrated

Your app must have a version of the RevenueCat SDK installed on it, and you must have your in-app purchases configured for the platforms your app is targeting, and the in-app purchase products need to be purchasable. Test store configuration is not counted as an integrated SDK.

Full configuration of RevenueCat requires you to have either an Apple Developer account or Google Play developer account.

Your app must have RevenueCat SDK integrated
App must have subscriptions and/or in-app purchases
Test store integration is not enough

Apps must be on TestFlight (iOS) or a Google Play testing track (Android)

Your app must be distributable through either TestFlight in App Store Connect, for iOS apps; or Google Play Public/Closed/Internal testing track, for Android apps. This means that you need to have an account on at least one of those stores for the app you’re submitting. Sadly RevenueCat is unable to cover the cost of the developer account for participants.

For TestFlight distribution, at least one app has to have been submitted to App Store Connect, and made available for distribution on the TestFlight tab. The app you submit to Shipyard should have External testing enabled, with a public link. Attach the public link to your Devpost submission.

For Google Play Console testing tracks, your app has to be uploaded to Google Play Console and made available through an Internal, Closed, or Public testing track so judges can install and evaluate it.

You CAN publish your app (but it’s optional)

Making your app public and publishing for people to download from the App Store and Google Play Store is allowed during and after the hackathon. Doing this will not affect judging, but you’re also not required to wait on publishing your app.

Publishing during Shipyard is allowed
Publishing does not disqualify your app
Publishing does not affect judging

How to submit your app to Shipyard

Your app needs to be testable on either iOS or Android devices, with distribution done either through TestFlight for iOS, or one of Google Play Console testing tracks for Android.

App testing and RevenueCat verification

Due to the number of submissions, we do not guarantee that every app will be fully installed and tested by judges. The required demo video is the primary way judges will be viewing all apps, before shortlisted apps will be viewed in more detail.

However, all winning apps will be installed and tested to verify correct integration of the RevenueCat SDK and confirm that subscriptions and/or in-app purchases are implemented as described. If a winning app cannot be installed or does not have a working RevenueCat integration, it may be disqualified and the award reassigned.

To avoid issues, make sure your submitted build is installable, stable, and matches what is shown in your demo video.

How to submit your iOS app

First, upload at least one build of your app to App Store Connect using Xcode. Once the build is processed, go to the TestFlight tab and enable External Testing. Create a public TestFlight link so anyone with the link can install the app without being added manually.

Make sure the build you share is stable, launches correctly, and allows judges to reach the core functionality of your app. If your app includes subscriptions or in-app purchases, they must be purchasable, meaning that you’ve integrated RevenueCat with App Store connect.

Finally, copy the public TestFlight link and include it in your Shipyard (Devpost) submission. Judges will use this link to install and evaluate your app.

How to submit your Android app

To submit an Android app to Shipyard, your app must be installable by judges through one of Google Play’s testing tracks.

Internal testing

Upload your app to the Google Play Console and create an Internal testing track. Add shipyard-android@revenuecat.com as a tester email so judges can access the app. Once the build is approved for internal testing, verify that the app installs correctly and that all core functionality is accessible.

If your app includes subscriptions or in-app purchases, they must be purchasable, meaning that you’ve integrated RevenueCat with Google Play Console.

Closed testing

Alternatively, you can use a Closed testing track. Upload your build to the closed track and add shipyard-android@revenuecat.com to the tester list (either directly by email or via a Google Group that includes this address). Make sure access is granted before submitting.

Confirm that the app installs cleanly and that judges can reach the main features without additional setup.

Public testing

You may also use Public testing. Upload your app to a public testing track and ensure the app is available for anyone to install without requiring approval. Share a link to your public testing version in the Devpost submission.

Summary

Shipyard does not require you to launch your app publicly, but it does require that judges can reliably install and test it. As long as your app is available through TestFlight (iOS) or a Google Play testing track (Android) and includes a working RevenueCat integration, you’re good to submit.

Publishing your app to the App Store or Google Play during or after the hackathon is optional and does not affect judging. Focus on shipping a solid, testable MVP. If judges can install your app and experience its core functionality, you’ve met the submission requirements.

If anything is unclear, ask in Discord. We’re happy to help you get unstuck quickly. Happy shipping!

RevenueCat Paywalls changelog

Thu, 29 Jan 2026 15:33:17 GMT

RevenueCat Paywalls is our native paywall builder that lets you build and optimize paywalls in real-time through RevenueCat’s dashboard, no app updates or code changes needed. In summer 2025 we rebuilt RevenueCat Paywalls from the ground up. What was once a simple, template-first tool is now a fully flexible, component-based editor where you can design fully custom layouts, localize every string, and tailor the experience to every segment.

But we’re not stopping there, we’ve been on a particularly rampant shipping spree as of November 2025. We’re shipping the most-requested and most impactful updates to Paywalls with a clear goal to make it the best paywall builder for every app.

This blog will serve as a living changelog for all-things RevenueCat Paywalls, so bookmark it to follow along and keep up with everything new.

A new Paywalls editor layout

We’ve refreshed the Paywalls editor with a sidebar-based layout that replaces the old dual-panel interface. Core areas like components, layers, branding, media, and localization now live in clearly labeled tabs, making the editor easier to navigate and simpler to learn.

The new layout keeps the canvas front and center while giving us room to keep expanding Paywalls over time. As features grow, the editor stays organized instead of crowded, even when you’re working on more complex paywalls.

Explore the new editor ↗

Keyboard shortcuts for faster editing

When you’re iterating quickly, small interactions add up. The Paywalls editor now supports Figma-style keyboard shortcuts for common actions like moving, duplicating, selecting, and deleting components.

To make shortcuts easy to discover, we added a help icon inside the editor that shows the full list of supported commands. You can open it at any time, pick up shortcuts as you go, and keep your focus on the layout instead of the UI.

View all shortcuts ↗

Copy and paste components between paywalls

You can now copy and paste components across different paywalls, not just within a single one. This makes it much easier to reuse layouts that already work, like hero sections, benefit lists, or pricing blocks.

When you paste a component into another paywall, its structure, styling, and bindings come with it. For teams running multiple campaigns or experiments, this cuts down on repetitive work and helps keep designs consistent across variations.

A dedicated Branding tab

We’ve added a new Branding tab to the Paywalls editor to centralize your visual system. You can now manage saved colors, gradients, and custom fonts in one place and reuse them across all paywalls in your project.

Branding assets appear directly in color and typography pickers while you edit, which makes it easier to stay on brand and avoid one-off values. This also simplifies collaboration, since teams can standardize styles once and confidently build on top of them.

A new Media gallery

Managing images across paywalls is now smoother with the new Media gallery. You can see all uploaded assets in one place, preview them at a glance, and clean up files you no longer need.

Uploading images is as simple as dragging and dropping them into the gallery. When editing a paywall, you can reuse existing assets instead of uploading the same file again. This is especially helpful for teams running many paywalls that share artwork or campaign visuals.

Safer localization with out-of-date alerts

Localization is now more transparent. When you update text in the default language, the editor automatically detects which translations are out of date.

A warning badge appears in the sidebar, along with a clear list of affected locales and fields. From there, you can update translations with one click or dismiss the warning if the change is intentional. This helps prevent silent copy drift and keeps global paywalls aligned as content evolves.

Learn more about localization ↗

Exit offers on paywall dismissal

You can now configure an exit offer that appears when a user closes a paywall without purchasing. Instead of ending the flow immediately, you can present a second paywall with an alternative offer.

This is useful for scenarios like offering a different billing option, a lower price, or a final reminder before the user leaves. Exit offers work across iOS, Android, and hybrid SDKs, and integrate cleanly with existing paywalls and experiments.

Configure an exit offer ↗

Auto-save for paywall drafts

The Paywalls editor now auto-saves drafts as you work. Changes are saved continuously in the background, which reduces the risk of losing progress if you navigate away or refresh the page.

Auto-save also surfaces validation issues earlier, since drafts are saved more frequently. Publishing behavior stays the same. Nothing goes live until you choose to publish, but editing feels safer and smoother, especially during longer design sessions.

Export Figma designs straight into Paywalls

Design handoff shouldn’t mean starting over. And now, it doesn’t.

You can export Figma mockups directly into the Paywall editor. Your layout comes in as native Paywalls components, so you can immediately:

Edit copy without touching the structure
Swap products and packages
Localize text
Add experiments
Target specific audiences

The practical win is speed. Designers stay in Figma, and the team shipping paywall tests can go from final mock to live variant, without recreating the layout by hand.

Import a Figma design ↗

Keyboard shortcuts in the Paywalls editor

When you’re iterating quickly, little clicks add up.

The Paywalls editor now supports keyboard shortcuts for the actions you use most, including adding components, duplicating sections, undoing and redoing changes, and deleting blocks. It keeps you in flow and makes fast iteration feel genuinely lightning quick.

View all shortcuts ↗

Preview your paywall on more devices

A paywall can look perfect on one screen and awkward on another. That used to be something you discovered after publishing, but now you can preview paywalls across a wider set of iOS and Android phones and tablets. The canvas updates to real screen sizes, so you can flip through devices in seconds to:

Catch spacing issues early
Confirm font sizes
Check crops and media positioning
Sanity-check scroll behavior
Make sure your CTA lands where you want it

It’s a simple change that prevents a lot of last-minute fixes.

Filter paywall templates

Templates are only helpful if you can find the right one quickly.

The template gallery now includes filters by purchase method, tier, or package. It’s especially useful when you know the pattern you want up front, like a trial-first layout, a pricing grid, or a promo-ready design. You spend less time searching and more time shipping.

Start with a template ↗

Countdown component for your paywall

Promos can be a great paywall technique, but they only work best when urgency is clear and real. To help, you can now add a countdown timer to any paywall. Set an end date once and the timer updates automatically. No extra code, no manual updates.

This is built for campaigns like Black Friday, launch promos, limited-time discounts, or any offer where timing helps people decide.

Add a Countdown ↗

Project level brand color settings

Setup brand colors now in project settings that are available in the Paywalls editor (and soon more places).

Real prices displayed in the Paywalls Editor

Previously, placeholder values displayed for product prices while being viewed in the dashboard editor. This latest update makes it so that you now see the real prices in the editor. This makes it much easier to get a more realistic version of the paywall while you’re working on it. (The one caveat is we will need to have seen at least one test purchase with this product for it to display).

Use AI to create a paywall

You can now use artificial intelligence to create a paywall based on data from an app store page. A great way to get inspiration or a solid starting point to adjust from and test.

Videos in Paywalls

Paywalls now support videos being added as their own component, just like images.

Video backgrounds

Videos can now be set as backgrounds on the root paywall, footer, or any parent component (stacks, packages, etc).

Intercept purchase intent

Native iOS & Android SDKs now offer a method to intercept purchase intent (tapping on the purchase CTA) to display custom UIs before choosing to proceed with the purchase flow. Use cases that apps find for this include: Age gate/parental consent: display a UI that acts as an age gate before letting someone proceed to purchase, Disclosures: If there’s additional info you want/need to present to a customer and have them confirm before proceeding (country specific terms, legal language, etc.)

View all plans (sheets)

You can now choose to have your button navigate to a sheet that can be used to display additional content. When you select a sheet as the destination to navigate to, you’ll see a new Sheet component inside of your button in the Components panel. When the sheet or any component within it is selected, you’ll see the sheet displayed in the paywall preview. You can add components to the sheet just as you would to any other stack.

Sheet’s can have their own packages & purchase buttons so that customers can directly make a purchase from the options displayed within the sheet.

Learn more in our Documentation ↗

How Sebastian Röhl built HabitKit by sticking with what worked (and starting over when it didn’t)

Wed, 28 Jan 2026 13:50:47 GMT

Sebastian Röhl didn’t stumble into success as an indie app developer. He shipped an app that went nowhere, burned out, started again, and only then saw momentum compound.

In the latest Sub Club episode, Sebastian—the indie developer behind HabitKit and FocusKit—walks through the slow, uncertain middle of app building: stalled growth, unclear signals, and the decision to keep going even when nothing looks like it’s working yet.

This isn’t a story about overnight success. It’s a story about persistence, timing, and doing enough of the basics well that growth eventually has somewhere to land.

From a safe job to a self-imposed deadline

After studying computer science and software engineering in Germany, Sebastian took a stable enterprise software job working with C#, .NET, and Angular. The work wasn’t exciting, but it gave him strong fundamentals and exposure to experienced engineers.

At the same time, he was quietly drawn to the idea of building his own business. After three years, he quit without a concrete plan and gave himself a clear constraint: 12 months to make something work.

As Sebastian explains in the episode, he didn’t leave with a polished business idea. He left knowing only that he wanted to build something for himself—and that mobile apps felt like the right medium.

The first app didn’t fail—but it didn’t work either

That first attempt was LiftBear, a workout tracker Sebastian built for his own use. He shipped quickly, skipped beta testing, and marketed it only by sharing progress publicly on Twitter.

The result was discouraging but instructive.

LiftBear attracted a small number of users and eventually settled at around $150 in monthly recurring revenue. It wasn’t dead—but it wasn’t growing, either. After six months of updates and incremental improvements, progress had stalled.

Sebastian describes this period as deeply demotivating. The app wasn’t clearly failing, but it wasn’t giving him any signal that doubling down would change the outcome.

HabitKit started with one visual that resonated immediately

HabitKit came from a much simpler idea: Sebastian wanted a habit tracker that visualized consistency using a GitHub-style contribution grid.

When he shared the first screenshot publicly, the response was immediate. Engagement spiked, new followers arrived, and for the first time, there was clear interest before launch.

That signal changed his energy entirely. He focused fully on HabitKit and released the first version after about two months of development.

The launch was modest by startup standards, but meaningful for an indie developer: roughly $150 in revenue on day one. More importantly, it showed that people understood the product instantly.

Building in public helped early—but wasn’t the long-term growth engine

Early on, building in public played a critical role. It helped HabitKit get its first users, early ratings, and initial momentum. It also gave Sebastian accountability and motivation during the quiet early months.

But the biggest growth moment didn’t come from social media.

Months after launch—after Sebastian had already returned to a four-day-a-week job—HabitKit suddenly began ranking for “habit tracker” in multiple App Store regions, including Germany and the UK. Shortly after, Google Play followed.

There was no viral post, no major metadata change, and no obvious trigger. Sebastian still isn’t sure why it happened. What was clear is that once HabitKit crossed a certain threshold, downloads and revenue accelerated quickly.

This was the moment when earlier work—product quality, reviews, consistency—finally paid off.

Going back to a job wasn’t the end of the story

When the original 12-month deadline expired, HabitKit still couldn’t support Sebastian full time. He returned to his previous company, working four days a week and reserving Fridays for his apps.

That fallback plan gave him stability—and time.

Six to seven months later, HabitKit’s growth was no longer ambiguous. With organic discovery compounding and revenue climbing steadily, Sebastian felt confident quitting again. This time, the decision was grounded in traction, not hope.

FocusKit was about motivation, not diversification

After years focused almost exclusively on HabitKit, Sebastian noticed something else stalling: his own motivation.

Updates became incremental. Public writing felt repetitive. To reintroduce novelty, he started FocusKit, a minimalist Pomodoro timer built natively with SwiftUI.

FocusKit wasn’t created to replace HabitKit or immediately match its revenue. It was a way to learn new technologies, lean into native iOS design, and regain creative momentum.

The launch was intentionally low-pressure. Early revenue has been modest, but the project serves a different purpose: keeping Sebastian engaged, curious, and shipping.

What Sebastian’s journey shows about indie app growth

Sebastian’s story isn’t built around clever hacks or aggressive growth tactics. It’s built around fundamentals:

Shipping products he personally wants to use
Sharing progress honestly, especially early on
Iterating longer than feels comfortable
Letting distribution compound after the product earns it

Growth felt sudden only in hindsight. In reality, it arrived after months of quiet, compounding work.

🎧 Listen to the full Sub Club episode to hear Sebastian unpack the slow parts, the setbacks, and the decisions that didn’t make sense at the time—but mattered in the end.

Why most activation metrics don’t predict who will stay (and what to use instead)

Wed, 28 Jan 2026 12:13:55 GMT

If you start researching activation metrics, you’ll find no shortage of suggestions:

Signups
Trials completed
Session length
Onboarding completion

On the surface, these all sound like reasonable things you should probably keep an eye on.

The problem? Most of these metrics focus on volume, not quality. They tell you how many people moved through a step, not whether those people became meaningful users, paying users, or users who actually stuck around.

In short, they don’t show whether someone truly activated in a way that drives retention or monetization.

Activation isn’t the same as signing up, and it’s not the same as completing onboarding — which means many ‘activation metrics’ will lead you astray.

What happens when you focus on the wrong metrics

Case 1: onboarding is performing, but activation isn’t happening

I see this all the time in growth audits and client work. In one example, onboarding completion rates were stellar — over 90% on both iOS and Android. The team felt confident that activation was in a good place.

But when we dug deeper, most of those users were gone by day two.

The onboarding flow was easy, short, and clear, but users weren’t engaging with the parts of the product that actually mattered or experiencing real value. Onboarding completion looked good, but the activation issue persisted.

Case 2: feature usage looks good, but only for a segment

In another example, activation metrics looked strong at first glance:

Good engagement
Healthy feature usage

But once we segmented free versus paid users, the picture changed entirely. Free users were inflating almost every metric; they were active, engaged, and numerous, but weren’t converting, renewing, or contributing to revenue.

After we isolated paid cohorts, it became clear that activation quality for the users who actually mattered was much poorer than topline numbers suggested.

These two cases highlight the risks of misinterpreting activation metrics, either by focusing on the wrong metric or by failing to segment your data meaningfully.

How to get to the right metrics

We’re going to look at:

Which activation metrics actually matter for subscription apps
How to avoid metrics that sound useful but don’t predict retention or revenue
How to define your own activation metric instead of copying someone else’s
How to test whether your chosen metric is real or just a vanity signal

I wish I could give you a magical activation metric and call it a day, but every app and use case requires a slightly different approach. The best I can offer is a framework to distinguish metrics that truly matter from those that merely look good.

Because here’s the truth: retention doesn’t happen without activation.

Many apps think they have a retention or monetization problem, but zooming out often reveals that users drop off before they experience meaningful value or form a habit.

Credit: Diagram created together with Thorsten Strauss, Hello Growth

The metrics you need to focus on depend on whether the problem is activation or retention.

The real question is: are people not sticking around because your product isn’t useful, or because they never truly activated in the first place?

That’s exactly what the right activation metrics help you figure out.

What activation really means for a subscription app

Before defining the right activation metric, we need to be clear on what activation actually is, because this is where things often get muddled.

I frequently see teams conflate activation with acquisition, label generic engagement metrics as activation, or treat it as simply ‘the steps a user completes’ rather than whether those steps actually move them toward becoming a long-term subscriber.

But we’re not here to get lost in terminology debates. Let’s keep it simple.

Activation happens when a user reaches meaningful value early enough in their journey that it becomes likely they will:

Convert (if they’re on a trial or freemium path)
Stay through their first renewal
Retain beyond that initial period

It’s not about completing an onboarding flow or ticking off a checklist. It’s about whether early behavior predicts survival and long-term value.

Or put another way:

Activation isn’t “Did they do the steps?”
Activation is “Did the steps they took meaningfully increase their odds of getting value and, as a result, staying and paying?”

You can test this by comparing retention curves for users who performed a particular action versus those who didn’t.

But here’s the catch: almost any action will look better than doing nothing, so you need to focus on actions that truly predict long-term retention and monetization.

Hypothetical retention curves for two different in-app behaviors

The real question is whether that specific action is truly predictive of retention and high-value users. The goal isn’t just to track activity; it’s to identify behaviors that correlate with long-term subscribers, versus actions (or inaction) that signal faster churn or low-value usage.

Two layers of activation: first value and core value

When thinking about activation in subscription apps, it helps not to treat it as a single moment. Your first session matters of course, but according to the State of Subscription App Report 2025, the largest share of trials occurs on Day 0 across both freemium and hard-paywall apps.

SOSA 2025: Day at which trials are started for freemium vs. hard paywall apps

That said, activation is just one moment in building a habit. In subscription apps, it’s rarely a single step.

I like how Product-Led Growth by Wes Bush breaks it up into three moments:

Moment of value perception: users understand the value, e.g. by seeing an example or visual
Moment of value experience: users experience the value themselves, e.g. using the app’s main feature for the first time
Moment of value adoption: users begin using the app in a meaningful way, e.g. building a habit

What we often talk about for apps is this idea of ‘Time to First Value’ and that usually covers the first two moments. The core value only emerges once behavior starts to repeat.

Credit: Slightly adjusted diagram based on original diagram from Product-Led Growth by Wes Bush

Let’s dive deeper into those two parts.

1. Time to first value (TTFV): moment of value perception and experience

TTFV is the user’s perceived and experienced value. It’s often small, but it matters because:

The steepest drop-off happens right at the beginning
Many users decide whether to continue or disengage very early

If users don’t see value early, they may never reach meaningful activation, no matter how strong the product becomes later.

This first-value moment should feel like progress, not just effort or friction for its own sake. Long onboarding flows might be trendy, but don’t use them just to fill time; they rarely help activation.

2. Time to core value (habit or sustained usage): moment of value adoption

Core value usually takes longer to reach. This is where users move from trying the product to using it in ways that predict retention.

It’s especially important for:

Habit-forming products
Wellness or tracking apps
Financial or budgeting tools
Apps with more complex workflows (e.g. B2B apps)

For example, for a language-learning app, completing a single lesson might signal the first value. But core value emerges once someone completes several lessons over multiple days and starts to build a routine. It may be measured by the moment they know 30 words in the new language or can form five complete sentences.

Many teams get stuck optimising only for the first session, without checking whether users reach the behaviors that matter later. For one app I worked on, we used day-7 retention as a success metric by ensuring experiments extended beyond session one, including push notifications and sessions two and three, to identify what would get users back enough in the first week to stick around.

When defining activation, don’t just ask: “What happens on day one?”

Also ask: “What must occur before a user behaves like a retained user?”

The key is that both layers matter, but in different ways.

First value helps prevent early drop-off
Core value predicts whether users will sustain and ultimately retain

Metrics that actually matter for activation

Now we’ve defined activation, the next question is: which metrics really matter?

It depends on your app (I know, such an annoying answer!), but if you’ve done the thinking above and run the numbers, you should already have a sense of:

Which behaviors predict retention
Which features deliver meaningful value
What your first value and core value moments look like

From there, the most important metrics are the ones that show whether users are reaching those value moments in ways that drive retention and conversion, not just ticking off steps or generating volume.

To help you better distinguish between noise and signal for your subscription app, here are examples of metrics that matter, metrics that inform, and ones that just distract.

Metrics that matter

These metrics are most likely to reflect real activation quality.

1. Percentage of users reaching the first value

This metric shows how many users reach the initial mini aha! moment, aka the first value.

Measuring this early step (perceived value) can be tricky in apps, but you can get a good sense by tracking whether users:

Complete a meaningful setup step
View a personalized insight
Return within 24 hours after their first session

Why it matters: It shows whether drop-offs are happening before users ever reach the value.

You’re not trying to force everyone to reach it instantly. The goal is to ensure enough users experience value early enough to avoid churning before activation.

If not enough of your users are reaching the first value moment, you have an activation problem, not a retention problem.

2. Percentage of users reaching the core value

This is the deeper signal, the next step in the journey. It shows whether users are forming patterns or habits that support retention.

This metric is often far more predictive of long-term success than anything that happens in the first session. The core value usually doesn’t happen immediately; it often emerges later, once users engage repeatedly with the product.

3. Time to first value (used thoughtfully)

Time to first value can be useful, but only as a diagnostic metric, not a goal in itself.

For first value, faster is generally better, but only if the experience still delivers genuine value. It’s better to provide meaningful value slightly slower than superficial value quickly.

For core value, timing matters relative to behavior. If reaching core value in week one versus week two predicts very different retention outcomes, then timing becomes a meaningful signal.

How timing of behavior can impact activation and in turn retention

The insight here isn’t ‘shorter is always better’. It’s that timing tells you something about activation quality.

4. How activation shows up in your funnel

Once you know how many users reach first and core value, these standard subscription metrics tell you whether that activation is turning into revenue:

Trial start rate (if you offer a trial)
Trial-to-paid conversion rate (if you offer a trial)
Download-to-paid conversion rate

The key: never look at these metrics in isolation.

For example, you might see a high trial start rate but a low trial-to-paid conversion rate. That doesn’t necessarily mean the trial itself is the problem. Often, users are starting a trial before they’ve actually experienced value, then canceling quickly ‘just in case’.

The right move might be to:

Slow down the path to trial
Improve value delivery first
Accept lower trial volume in exchange for higher-quality users

Again, when it comes to activation metrics, quality over volume is what drives retention.

Metrics that inform (but shouldn’t be success KPIs)

Some metrics are useful for understanding activation, but they shouldn’t be treated as proof of success.

1. Onboarding completion rate

Onboarding completion is one of the most overused activation metrics. A high completion rate does not guarantee activation is working.

In some cases, adding positive friction actually improves activation quality by helping you understand users, tailor experiences, and build trust before asking for commitment.

Instead of asking “How do we increase onboarding completion?”, ask:

Do users who complete onboarding retain better?
Are we helping the right users progress?
Are we losing good users too early, or filtering out low-intent users later than we should?

Completion is a signal, not a goal.

2. Feature adoption (with the right segmentation)

Feature adoption can be insightful, but only if you look at it through the right lens.

Average adoption rates often hide the story. A feature may appear lightly used overall, but be heavily used by high-LTV or paying users. Meanwhile, some features add complexity without contributing to retention.

Feature adoption is most useful for understanding:

Which features support retention
Whether free users understand the value of premium features
Which features are adding noise rather than helping users activate

I had an app where very few free users tried the main premium feature (it was available with limited usage to free users). As a result, they weren’t activating properly and were unlikely to pay — they didn’t see the value.

Feature adoption is also useful for spotting noise. If only 2% of users use a feature, and they aren’t your most valuable users, so ask whether it’s adding complexity rather than contributing to activation.

On that note, check out this great podcast on the adoption thresholds used at Netflix.

Metrics that distract

These metrics are easy to over-optimize and often pull growth teams in the wrong direction.

1. Total signups

More signups don’t automatically mean better growth. While signups are necessary to feed volume into the funnel, optimizing for quantity alone can:

Attract lower-quality users
Mask activation problems
Give acquisition teams the wrong incentives

Sometimes the right move is fewer signups, but higher-quality traffic that is more likely to activate and retain.

2. Trials started

A high trial start rate doesn’t automatically create more paying customers. In some cases, users start a trial before truly experiencing value, which can lead to:

Low trial-to-paid conversion
Poor first renewal
Weaker retention overall

3. Session length

Longer sessions can indicate engagement, especially for apps like video platforms or games, but they can also signal confusion or difficulty finding content.

For many subscription apps, efficient value delivery is more important than raw time spent. Context matters far more than total minutes.

4. Raw daily active users (DAU) or monthly active users (MAU) without a quality lens

DAU and MAU are only meaningful if ‘active’ reflects meaningful usage, and the frequency matches your product’s natural cadence.

A common recommendation is to look at the stickiness ratio that measures app stickiness:

However, there are two issues with this standard app stickiness metric:

Your app’s ideal usage frequency might not be daily
Active users’ often means ‘opened the app’, which isn’t the same as ‘experienced value’

Once you adjust for these factors, stickiness can still be useful, but it’s better to define your ideal usage frequency and compare it over a longer period to identify what drives retention.

For example, for a wellness app I worked with that offered workshops and meditations, consuming at least two pieces of content in 14 days was a stronger predictor of retention than using the app once a week.

How to test whether your activation metric is real or vanity

Defining an activation metric is just the first step. Next, you need to demonstrate that it reflects real activation, not just a vanity signal.

A metric only counts as true activation if it passes these tests:

1. Activated users retain significantly better than non-activated users

Compare retention curves for users who reached the activation milestone versus those who didn’t.

Think back to the diagram I showed earlier:

Hypothetical retention curves for two different behaviors in-app

You’re looking for a sustained difference, not a short-term bump that fades after a few weeks. If the curves reconverge later, the metric is likely just an engagement step, not true activation.

Put simply: if users who ‘activated’ don’t retain or pay significantly more, your metric isn’t real activation, it’s just noise.

2. The relationship holds across (most) cohorts and channels

Check whether the activation metric predicts retention consistently across:

Cohorts over time
Acquisition channels
Web vs. iOS vs. Android
Device types
Geography (if relevant)

You don’t need perfection, as some variation is normal. You might see:

A channel where the relationship is weaker
Users on one platform are activating differently

What matters is that the pattern holds broadly, and you understand where and why it breaks. In some cases, you may need different activation metrics for web, iOS, Android, or different regions.

3. Improving the metric improves downstream outcomes

Some activation effects take time to appear in retention curves, especially if you’ve only recently started tracking them. Another key check is whether improving the activation metric drives the outcomes it should influence.

For example:

If it’s an early value milestone → does it improve trial-to-paid conversion?
If it’s a deeper habit milestone → does it improve first renewal?
If it sits later in the journey → does it reduce early churn?

If the metric moves but nothing downstream improves, it may look meaningful, but it isn’t actually creating better, more durable users.

Practical checks to strengthen confidence in your metrics

If you have enough data, stress-test your activation metrics with a few deeper cuts:

Compare activated vs. non-activated users within the same cohort
Split by paid vs. free users (if you have a freemium path)
Break down by channel or device quality
Check whether high-LTV users follow the same activation pattern

This helps you avoid building your activation model around users who were never likely to pay or retain in the first place.

Work out your activation window

Activation is not just about what happens; it’s also about when it happens.

Look at your retention curve and identify where the steep early drop-off stabilizes. That point often marks the transition from activation to retention and helps define the window where your metric truly matters.

The activation window

If the activation window is very long, it may indicate that users aren’t deriving value quickly enough, or that your product simply requires a longer window to activate. This could mean:

Users aren’t reaching value fast enough
They need more guidance or support to progress meaningfully early on

Back to a language-learning app, a single lesson isn’t enough to signal commitment. Users may need to complete several lessons over a week or two before they meaningfully engage as long-term learners (or start fearing the owl enough to keep going). The window isn’t just about capturing that first lesson; it’s also about the time required to significantly increase the user’s likelihood of staying.

The goal isn’t to force activation sooner than makes sense. It’s to understand when it happens today and whether that timing supports retention.

How to use this in practice

After all that, you might have a long list of metrics you could track, but you don’t need dozens. Stay focused by categorizing metrics into three clear buckets.

Metrics that matter should directly predict conversion, retention, or renewal: optimize these
Metrics that inform help you understand why activation is or isn’t happening: investigate these
Metrics that distract are easy to improve, but often optimize volume over quality — keep an eye on them, but resist chasing them

If there’s one takeaway, it’s this: activation is not about getting users through steps. It’s about helping the right users reach value in a way that makes them likely to stay.

When teams think they have a retention or monetization problem, it’s often because activation never truly happened. The earlier you define what real activation looks like for your product, the easier everything downstream becomes.

How to win Shipyard

Tue, 27 Jan 2026 14:14:03 GMT

RevenueCat has a new hackathon, Shipyard: Creator Contest. Similarly to our previous hackathons, this one is also about building a real, monetized mobile app (MVP is enough, check the rules here). This time, however, your target audience are the community of real influencers — who will also be judging your submission!

This hackathon is a lot shorter than Shipaton, so it’s more important than ever that you focus on building the right thing, quickly. RevenueCat wants to support you in doing that, so we’ve written this hackers’ guide to building a winning app, based on four core lessons:

Coming up with a great app idea
Building your app fast
Growing your user count
Telling your story in the final submission

On top of these lessons, we’ve curated a bundle of tools, credits, and resources to help you build, launch, and monetize your app in the four weeks of Shipyard. Once registered, check your email (including your junk!) to receive your Shipping Container.

Without wasting any more time, here’s how you win Shipyard.

Step 1: Come up with a great app idea

The first step into winning a hackathon is coming up with an idea for your app. Preferably this idea should be a really good one, as it will make building a great app significantly easier, but that is rarely that easy to do. So how do you come up with a great app idea?

First, start by watching the creator briefs, there’s seven of them, and they are all quite different. Be open, and don’t use come to this hackathon with an existing idea that you’ll then try to make fit one of the briefs. That rarely works, and to be frank, what you think is a great idea for an, usually isn’t. So take your time with the briefs, and pick the one that resonates the most. At this point your idea can be very simple, and it certainly does not have to be a groundbreaking one, we will distill it into a one next.

Talk to people

A common misconception is that people come up with great app ideas on their own. In reality people come up with average ideas on their own, and once they start talking with customers about the problem they have, it gets turned into a great idea. So take your preliminary idea, and go to the potential users with it. Watch the creator brief again, this time focusing on who is the target audience, and figure out where you could find someone that represents the target customer, then simply go talk to them.

Don’t just pitch your idea to the target customer, instead start with open ended questions. Build empathy to understand what the problem is that your customers are having, and how they feel it could be solved. Your goal is to understand your customers in such a way that you can instantly know what the real problem they are struggling with is, and what kind of solution they would fall in love with.

With all of this you should aim to get to a state where you feel that you have to build this specific app, because you’re the only one who really understands your customer, and therefore the only one who can get it right. For more pointers about getting to this state and coming up with a great app idea, take a look at our How to win Shipaton: coming up with an idea blog post.

Step 2: Build your app fast

Once you have your problem and idea nailed, it’s time to start building. The first lesson in building quickly is setting a timeline for yourself and sticking to it. Don’t wait for inspiration to start coding your app, that stuff is for amateurs. Winners just get to work and build.

You can approach your build timeline in multiple ways, but we have one that tends to work very well, and it only has three parts that all have a specific purpose:

1. Build your concept in 4 hours

In these four hours your focus is on proving that your concept works. The only person you need to convince that your app is great is you yourself. This is the part where you make something that barely works, but works nonetheless. There’s a bit of UI there already, but no polish, and there certainly shouldn’t be big infrastructure in your app at this point.

2. Build your MVP in 8 hours

Now take what you built in the first 4 hours, and start polishing it so that you could show it to a potential customer. Things don’t have to work at this point, they just have to feel like they work. Use mock data, make fake requests to services, be like the Wizard of Oz: it’s not magic but for users it feels like it is.

If you feel embarrassed to show your app, good. That means you’re going to your customer early enough with your idea and getting feedback that will set you on the right track.

3. Build your app in 24 hours

After you’ve shown your 8-hour making to customers, take what they have to say and incorporate it into your app. Drop things that users didn’t care about, add the things that enough people asked for. At this point your app will most likely still be embarrassing. You just need to get it to a stage where you could leave the customer alone with it and check back later how it worked. So launch the app if you can.

And keep launching and relaunching your app. Multiple times. Every day if it requires it. Add features, fix bugs, but never take more than day or two from getting those improvements in the hands of your customers.

This process should highlight to you that great apps are built iteratively honing the product, not building it once and leaving it at that. So ship as often as you humanly can. We’ve collected more guidance on building quickly using this same method in this How to win Shipaton: building your app fast blog post.

Step 3: Grow your user count

After you’ve built your idea, comes the actual hard part: getting users. Shipyard does not require you to launch your app to app stores, but doing so doesn’t hurt either. After all, customers can only pay you if your app is available to them, and more customers means more revenue.

However there are other reasons for growing your user count than just converting them to customers. In the beginning especially, the more users you have the more feedback you get, and you might have already learned from the previous two lessons that gathering feedback and acting on it is the best way to build something that wins.

For a more extensive lesson on growing your app, take a look at this blog post on Winning Shipaton by growing your app, but here’s a few key points to growing.

First make use of the Shipyard discord to recruit users to test your app. Get as many as you can, people will churn, meaning that they’ll stop using your app when it stops being useful to them. With your first version of the app, this will most likely happen with all of the users, that’s why it’s important to continue improving your app and launch it again and again. The most valuable learning you can get is talking to the users who stopped using your app, they know best what features your app is lacking, so try to get a hold of them.

Step 4: Tell your story

Last lesson to winning Shipyard has actually quite little to do with your app itself, and all to do with how you talk about your app. When you take a look at the submission guidelines for Shipyard, you’ll notice that two of the requirements besides the app are a short video and a written proposal. These are the two things the judges will be scrutinizing the hardest, so it’s important to communicate clearly what your app is about.

Clear messaging is however only half of the story. If you actually want to win, you need to tell a compelling story. This means framing the problem so that it elicits feelings from the people looking at the video, and in such a way that paints you and your app as the heroes of the story.

Now this all sounds rather complicated, but fear not, RevenueCat is here to help you with this as well. In our fourth guide How to win Shipaton: pitching your app guide, we go through a simple storytelling mechanic called the “Story circle”. Check out that article, apply it to your video and written submissions (and don’t do it on the last night before submissions close), and making both of them should not take you more than a few hours.

Make use of the Shipping Container

Last but certainly not least, we have partnered up with a group of companies to give you the best tools for building your app, a curated bundle called the Shipping Container. You can of course use any tools you want for building your app, but these freebies will help you a lot if you decide to make use of them.

Get inspired and brainstorm with AI

The Shipping Container includes tools for ideation and brainstorming. Study real-world UI and UX patterns in Mobbin, and jump over those design hurdles with ease. You can even outright steal the best onboarding and paywall patterns from popular apps, and use them in your app to improve your monetization and app experience.

Put Manus to work to do analysis in the ideation phase and growth phases, by brainstorming with it and using it to build beautiful looking landing pages. You can essentially use Manus as your team member in this hackathon, and you don’t even have to share the price money with them.

Build fast with vibecoding tools

The Shipping Container comes bundled with multiple different AI-assisted tools for building apps as well. You can build your app with Fastshot, Anything, Replit, and Rork, either using the mobile apps or the web based editors they have. All of these tools give you the power to build your idea into a real app, and most importantly all of them make it very fast to do that.

All these tools also support RevenueCat, it’s enough to authenticate with your RevenueCat account and after that you can start telling the AI to add subscriptions, lifetime upgrades, entitlements, RevenueCat powered paywalls and more into your app with just prompts. If you’re feeling lost, take a look out for an in-depth video guide to doing all of this with Vibecode below.

Once your in-app purchases are working, you can explore other payment options. The Shipping Container comes bundled with Paddle as well, so you can add web-based payments alongside your in-app purchases, and experiment with additional monetization paths.

Time to set sail

Now get cracking and go build that winning app. Take a look at the linked and articles and most importantly: build something that people love, but something you love to work on. Don’t lose track of the end goal, building an app, not a concept. Get your app out to people, as soon as you get feedback I guarantee that your productivity will soar higher than in any other way.

The 15% App Store fee you’re probably not paying (but should be)

Tue, 27 Jan 2026 14:10:39 GMT

As a developer, you’ve probably complained about the 30% App Store fee. It feels like a mandatory slice of your revenue that goes straight to the platform holders, just for the privilege of your app existing

But here’s the thing nobody talks about enough: for the vast majority of developers, the 30% fee is a myth

For years now, both Apple and Google have had programs that cut that commission in half, to just 15%. Yet every day I talk to developers who have no idea these programs exist, or they think it’s some complicated process they don’t have time for. They’re leaving tens of thousands of dollars on the table. Money that could be used to hire another engineer, run a marketing campaign, or just, you know, pay the bills

This isn’t some secret loophole. It’s a public program. And if you’re making less than $1 million a year from your apps, you qualify. Today, we’re going to fix this. No more excuses. Here’s your step-by-step guide to claiming the 15% you’ve earned:

The program you need to join right now

Both Apple and Google call it something different, but the core idea is the same: if your annual earnings are below $1 million, you get a reduced commission rate of 15%. It’s that simple

Apple: the App Store Small Business Program

Apple’s program is a lifesaver for indie devs and small studios. It drops the commission from 30% to 15% on everything: paid app downloads, in-app purchases, and subscriptions

The rules:

You must have earned no more than $1 million in total proceeds (after Apple’s cut) in the previous calendar year
All of your ‘Associated Developer Accounts’ count toward that $1 million threshold
If you’re a new developer, you automatically qualify

How to enroll in Apple’s program (it takes 10 minutes):

Go to the enrollment page: first, make sure you are the Account Holder for your Apple Developer account. Then, head straight to the enrollment page
Review your accounts: Apple will ask you to confirm your developer accounts. If you have multiple, you’ll need to list them
Accept the terms: you’ll need to review and accept the latest Paid Applications agreement in App Store Connect if you haven’t already. Then, accept the terms of the Small Business Program

That’s it. Once you’re approved, the 15% rate kicks in. You just gave yourself a massive raise

Google: the 15% Service Fee Tier

Google’s program is just as crucial. They charge 15% on the first $1 million of your earnings each year. If you cross that threshold, the rate goes to 30% for the rest of the year. For most of us, that means a permanent 15% rate

The rules:

The 15% rate applies to the first $1 million in revenue you earn each calendar year
Like Apple, you need to declare your Associated Developer Accounts and create an ‘Account Group’

How to enroll in Google’s Program (also takes 10 minutes):

Go to your Play Console: log in and navigate to the Associated developer accounts page
Create an Account Group: follow the on-screen prompts to create a group. This is where you’ll link any other developer accounts you own
Enroll: once the group is set up, a banner will appear prompting you to enroll for the 15% service fee. Click ‘Review and enroll’
Accept the Terms: read and accept the Terms of Service

Done. You’re now enrolled. It’s a few clicks that will fundamentally change your app’s financial trajectory

The other secret: subscription commission discounts

Okay, so the Small Business Programs are the main event. But there’s another layer to this that a surprising number of developers miss, especially when it comes to subscriptions

Apple: the year-two reward

For auto-renewing subscriptions, Apple has a built-in discount. For any given subscriber, you pay 30% for their first year. But if you can keep them subscribed for a full 12 months, Apple rewards you by dropping the commission to 15% for that subscriber’s second year and beyond

Of course, if you’re in the Small Business Program, you’re already paying 15% from day one. But if your app grows and you graduate out of the Small Business Program, this year-two discount becomes incredibly important. It’s a direct incentive to focus on long-term retention

Google: 15% from day one

Google simplifies things. For all auto-renewing subscriptions on Google Play, the service fee is 15% from day one. It doesn’t matter if you’re in the reduced fee program or not. It doesn’t matter if it’s the subscriber’s first month or their third year. For subscriptions, the rate is 15%

This is a huge advantage for subscription apps on Android, making the unit economics much more favorable right from the start

Here’s how that breaks down:

Platform & program	Subscription commission (year 1)	Subscription commission (year 2+)
Apple (standard)	30%	15%
Apple (Small Business Program)	15%	15%
Google Play (all developers)	15%	15%

Telling RevenueCat about your enrollment

If you’re using RevenueCat, there’s one more step you’ll want to take: letting RevenueCat know you’re enrolled in these programs. This ensures your charts, metrics, and integration data all reflect the correct commission rates

For Apple

Since a developer could have multiple apps from different companies in their RevenueCat account, the Small Business Program status is set on a per-app basis. Here’s how to set it up:

Go to your RevenueCat Dashboard: select ‘Apps & providers’ at the bottom of the left navigation sidebar
Select your App Store app: scroll down and expand the Apple Small Business Program dropdown
Enter your entry date: this is the effective date your membership began. If you enrolled before December 18, 2020 and were notified by December 30, 2020, then enter January 1, 2021
Add an exit date (if applicable): if you’ve left or been removed from the program, enter that date here

Once you save, RevenueCat will correctly calculate your proceeds in charts and send accurate pricing data to your integrations. If you set the entry date in the past, charts will recalculate within 24 hours.

For Google

Good news: RevenueCat automatically assumes you’re enrolled in Google’s reduced service fee tier. For subscription transactions, RevenueCat uses the 15% rate by default

If you cross the $1 million threshold during a calendar year, RevenueCat will automatically switch to the 30% rate for the rest of the year. If you have multiple apps or have transferred apps and the calculation seems off, just reach out to RevenueCat support and they can manually adjust your project’s service fee rate

Stop leaving money on the table

That’s it. No complex legal battles, no risky side-loading schemes. Just two official, easy-to-join programs and a clear set of rules for subscriptions that can save you half of your commission fees

If you take one thing away from this post, let it be this: check your enrollment status right now.

For Apple: go to your App Store Connect agreements
For Google: visit the Associated developer accounts page in your Play Console
For RevenueCat: head to your app settings and confirm your Small Business Program status is set correctly

If you’re not enrolled, take the ten minutes to do it. It will be the highest ROI you get all year. You’ve built a great app; you deserve to keep the revenue you’ve earned

Ship early, learn faster: speed as a strategy for early-stage app growth

Wed, 21 Jan 2026 16:45:08 GMT

We’ve all been in a meeting and had this question asked over and over again:

“When will the experiment go live?” The dream answer: “It already did.”

The reality? A familiar list of reasons and delays that you awkwardly have to explain to a Zoom-ful of people:

We’re waiting on development
We still need someone else’s sign-off
Brand isn’t happy with the design yet

When this happens once, it’s not the end of the world. But when moving slowly becomes the default, it compounds. Especially for startups, where every delay means less learning and a shorter runway.

There’s the ‘ideal world’ we’re often taught: all stakeholders aligned, experiments neatly queued, and decisions made only after lifetime value has fully played out.

And then there’s reality… every month costs money, most early ideas won’t work, and waiting for perfect data often means waiting too long.

At some point, you have to let go of rigid rules and choose fast feedback over perfect planning. That’s uncomfortable, but it doesn’t mean being reckless; it means being intentional about where you move fast, where you slow down, and how quickly you decide what to learn from.

Here’s what you’re about to learn (and hopefully actually use):

The hidden risks of waiting for certainty
Why fast feedback beats false confidence
When to kill experiments early
How to ship faster without breaking trust
And when slowing down is actually the right move

Certainty is what you get after shipping

I once worked with a client testing a landing page as part of a pre-launch experiment. The founder was a designer with an incredible eye for detail, and I joined her in double- and triple-checking every element. We’d done the work: months of research, competitor analysis, and even a painted-door test to validate interest before committing to a full build.

Then the page finally went live. Celebration time!

We waited for the pre-launch commitments to roll in. The painted door test (which gauges interest by showing a feature or offer before it exists) had signaled demand, so expectations were high. But almost nothing happened. No meaningful subscription sign-ups.

What we did learn, quickly, was far more valuable:

Meta ads were extremely expensive at that time of year, and we needed more video content to build trust and lower costs
People hesitated at the subscription price, so we introduced an intermediate step first, and found that it converted better

We’d done everything ‘right’ to build confidence before launch. But certainty about what worked and what didn’t only came after shipping, once real people interacted with the page.

This is where many growth teams get stuck. Early on, most bets are wrong. You’re operating with limited data, few returning subscribers, and barely any meaningful lifetime value (LTV) signal. Monetization metrics at this stage are directional at best, and not something you can wait on with confidence.

Early monetization decisions aren’t about precision; they’re about momentum. You’re not trying to predict lifetime value; you’re trying to understand whether an offer is viable at all. Signals like trial-to-paid conversion, early churn, or price sensitivity tell you where to look next, not where you’ll end up. Waiting for perfect LTV before acting assumes a level of certainty that simply doesn’t exist yet.

Your simple rule for moving faster

Reid Hoffman describes blitzscaling as prioritizing speed over efficiency in the face of uncertainty. That’s exactly what early growth requires — not recklessness, but a willingness to accept that clarity comes from exposure, not preparation.

We don’t gain certainty by thinking harder or planning longer. We learn by putting things into the world and observing how they behave. I’d love to build a campaign or feature that’s guaranteed to work. I can’t. No one can.

So what’s the strategy?

Your simple rule for moving faster should be as follows:

If the cost of being wrong is reversible and contained, move fast.
If it’s irreversible or erodes trust, slow down.

Growth isn’t about building confidence before you ship, but about earning confidence after you do, which is why fast feedback is critical.

Fast feedback is a competitive advantage

You’ll hear all kinds of stats about early-stage growth: ‘only 20% of what you do drives impact’, ‘only 10% really works’, simply that ‘most experiments fail’… I don’t know the exact number that’s accurate. What I do know, from leading growth at an early-stage startup and working with many others, is how frustrating it is just how much doesn’t work.

The teams that win aren’t the ones with a higher success rate. They’re the ones who find out faster.

Fast feedback isn’t about shipping more features or running more experiments. It’s about constantly asking: what’s the smallest possible way we can test this and learn something meaningful? That might mean testing a value proposition through Meta ads before touching the app, or experimenting with App Store messaging to see which feature focus actually drives conversion.

That might mean questions like:

Which engagement behaviors reliably predict retention?
What early revenue signals indicate higher-value users?
Where do users hesitate before committing?

Most subscription apps know that annual plans typically produce higher LTV than monthly ones. The default response is to push annual as hard as possible, or remove monthly entirely. That may optimize monetization in the short term, but it slows learning.

Streema deliberately did the opposite. As Martin Siniawski has shared, they kept monthly subscriptions prominent so they could see churn sooner, understand what drove real, repeatable value, and actually talk to users who left.

Rules for fast feedback in practice

That’s what fast feedback looks like in practice: prioritizing learning speed over delayed certainty. It means doing the following:

Design tests to fail quickly, not to be statistically significant
Use proxy metrics intentionally, knowing they’re directional, not definitive (but good enough)
Prefer reversible changes over big, one-way launches
Optimize for insight velocity, not just conversion rate and monetization
Create earlier moments of truth, even if they temporarily hurt top-line metrics
Speak to your users rather than just relying solely on quantitative data
Acting on what you learned, even if it isn’t the result you hoped for

Fast feedback isn’t just a product problem. It breaks down when teams can’t make decisions without multiple sign-offs, or when learning has to be approved before it’s acted on. Too many cooks spoil the broth and all that.

So the final rule is simple: build an organization designed for speed, creating autonomy and trust instead of relying on complex sign-offs.

I promise you: fast feedback compounds over time and helps you grow faster.

Kill your darlings… fast, but confidently

The hardest part of moving fast isn’t shipping. It’s the moment after, when you’ve moved quickly, intentionally built a real alternative, and it simply doesn’t work. Like the pre-launch landing page that just wasn’t performing. It’s heartbreaking, and that’s usually when the temptation to ‘wait it out creeps in.

Back to the pre-launch experiment I mentioned earlier. We were about a week post-launch. Long enough for people to convert, long enough to have some data, but not nearly enough to feel officially certain. Still, when I ran the numbers, it was hard to ignore what they were telling us. Even if we improved the creatives and lowered the cost-per-click (CPC), we would still land far above our target cost-per-acquisition (CPA) for driving subscriptions.

At that point, waiting stops being patience and starts just being hope. When early data is that far off, you can be confident it won’t pivot into winner. It might improve a bit, but not enough to justify the time, budget, and attention it would continue to absorb.

That’s why — thanks to a great suggestion from the founder — we didn’t try to patch it up. We killed it, and moved on to a two-step page instead, a fundamentally different setup.

But this is where it gets tricky.

With another client, where I was running an A/B test, I did the thing we’re not supposed to do: I peeked early. The results weren’t great. The new variant was tracking slightly worse than the original. I didn’t like what I saw, but I also didn’t kill it. With only a handful of conversions per variant, there simply wasn’t enough signal yet. In that case, giving it time proved to be the right call, and the variant ultimately won.

There are instances when you need to give experiments time. This is especially true for pricing experiments: the initial conversion rate may suggest a new pricing strategy or package offering is underperforming, but after one–two renewal cycles, you’ll see that overall revenue is up.

So I’m not saying kill all your darlings, but I’m also not saying give everything endless time. Fast shipping and fast learning don’t mean a blanket kill-it-all approach. There are times when you should stop quickly, and times when you should deliberately wait.

Rules for killing your darlings

What helps is being explicit about why you’re continuing or stopping. In practice, this is how we kill our darlings:

Peek strategically, but don’t broadcast early results in a way that invites emotion-driven reactions
Ensure there’s enough data to see direction, even if you’re far from statistical certainty
Run the maths on how far off you are from the target, not just whether something is ‘up’ or ‘down’
See experiments as part of a bigger system, not one-off tests: you can still believe in the hypothesis, even if this execution isn’t it
Decide in advance which darlings deserve more time, such as pricing experiments that need renewal cycles to show their impact

Killing something early isn’t pessimistic. It’s often the most direct way to protect focus and create space for the next, better bet. There’s a real opportunity cost to not killing: every experiment you keep alive is one you’re choosing instead of something else that might actually move the needle.

Think of it like pruning a plant. It feels awful to cut off healthy leaves, but you do it knowing the plant will be stronger and grow better because of it.

Speed doesn’t have to come at the cost of quality or user trust

One of the biggest fears teams have when they talk about moving faster is that quality will inevitably go down. And while that can happen, it’s not what moving fast actually has to mean. Speed doesn’t mean:

Sloppy work
Broken experiences
Shipping things users weren’t ready for

I was advising a client with a community-based app who wanted to improve moderation to ensure the community remained a genuinely good place to be. It was a strong idea, but also a big one. There were multiple concepts on the table, each requiring coordination across backend (to build a scoring system), frontend, design, and product. Because of that complexity, the initiative kept getting pushed out, not because it wasn’t important, but because it felt too big to start.

When we zoomed out, one thing became very clear. The entire moderation system they wanted to build depended on a single assumption: that users would actually provide the input needed to make it work — likes, reactions, or signals about positive and negative interactions. If users weren’t willing to do that, or didn’t behave in the way the system expected, the whole model would either fail or require a fundamental rethink.

So instead of building the entire moderation system, we focused on testing that assumption first.

The first step wasn’t a scoring model or a full moderation flow. It was simply introducing — and observing — whether users would actively use like/reaction buttons when interacting with others. That single behavior would tell us whether the broader idea had a foundation to build on.

If usage was low, the priority wouldn’t be better moderation logic, but understanding how to encourage or redesign that input. If it worked, the team could move forward with much greater confidence.

What does Minimum Viable Product actually mean?

What’s important here is that this didn’t feel half-baked to users. They weren’t exposed to an unfinished system or asked to tolerate a worse experience. From their perspective, they simply had more ways to react and express how interactions felt. In fact, it already gave them a greater sense of control over what good and bad interactions looked like, without needing to know anything about the system being tested behind the scenes.

This is what speed looks like when it’s done well: not rushing to build everything, but narrowing down what you actually need to learn first. What is the smallest test that meaningfully de-risks the idea? Which assumption, if wrong, would make everything else irrelevant?

This is why I like how Ethan Gar reframes the idea of a Minimum Viable Product (MVP):

“People get the minimum viable product idea wrong. They focus on the minimum, but not the viable. If I give you an app whose core functionality is broken, you won’t get value, and it won’t perform. When we are focusing on speed, we are focusing on the simplest viable version that delivers value.”

That distinction matters. The moderation example wasn’t about speed for its own sake or cutting corners. It was about delivering value early while learning which assumptions actually mattered — without overcommitting to complexity too soon.

Of course, as you move faster, things will break more often. That’s part of the trade-off. But most of the time, users won’t even notice. And when you get this right, the value gained from faster learning usually outweighs the cost of the occasional misstep.

Which brings us to the harder question: when is speed no longer the right choice, and when does slowing down actually protect quality and trust?

When should perfection take priority over speed?

Speed isn’t universally correct. There are moments where slowing down isn’t cautious, it’s responsible. Moments when perfection is the right way to ship. These are often situations where a generalist mindset no longer helps, and moving too fast creates more risk than value.

The mistake teams often make is treating perfection as the standard mode of operation, when in reality it should be reserved for specific moments. To move past that tension, it helps to be explicit about which situations actually deserve slowness.

Not all of these will apply to every app or brand, but walking through them helps clarify where slowing down is intentional rather than accidental.

1. Core functionality of your app

When it comes to the core value your app provides, there’s a minimum bar that needs to be met. Not ‘perfect’ in the abstract sense, but good enough that users clearly experience the value early in their journey.

This aligns closely with Ethan Gar’s idea of minimum viable value. The goal isn’t to ship everything, but to make sure what you do ship genuinely works. If users are paying for the app, performance and reliability matter. You can still move fast in how you validate and iterate, but the underlying experience needs to meet a clear standard from the start.

2. Large, one-way technical decisions

Some technical choices are hard to undo. For example, when advising an app considering a transition to Flutter, it became clear just how much was at stake. Migrations like this touch almost everything and create long-term consequences.

This is where slowing down is justified. You want clarity on why you’re doing it, what problem it actually solves, and how success will be measured. A common trap is using a technical rewrite as an excuse to ‘fix everything’, which often leads to long delays.

Perfection here doesn’t mean dramatically improving everything. It often means ensuring the new version performs at least as well as the old one, without introducing instability. That bar is usually lower than teams expect, but still worth protecting.

3. Data privacy and security

Whenever you’re handling user data, speed takes a back seat. This includes privacy, consent, tracking, and compliance. Carelessness here erodes trust quickly, and it’s difficult to recover from.

This is not an area for rough experiments or shortcuts. It’s one of the few places where being overly-cautious is usually the right call.

4. Vulnerable user groups

If your app serves vulnerable audiences, extra care is required. I once spoke to someone working on a mental health app for children (a double dimension sensitive topic).

In cases like this, teams often invest heavily in research and exploration before shipping anything meaningful. That doesn’t mean nothing ever gets released, but it does mean the bar for thoughtfulness and validation is higher, and the cost of getting it wrong is taken very seriously.

5. Brand-defining moments

Some releases don’t just add functionality; they reshape how users perceive the brand. These moments deserve extra care.

A good example is Ladder, a fitness app that expanded into nutrition, repositioning itself from purely fitness-focused to a broader health platform. That’s a significant shift in both competitive space and user expectations.

The first version wasn’t perfect, but it felt deliberately more complete than it strictly needed to be. Features like nutrition input via voice, image, and text were available from the start, rather than offering just one method. That choice wasn’t about speed or scope; it was about ensuring users felt the new positioning immediately.

6. Irreversible decisions (one-way doors)

Jeff Bezos describes decisions as either one-way or two-way doors. Two-way doors can be reversed; one-way doors cannot.

Changing your target audience, fundamentally shifting your app’s purpose, or making promises you can’t easily walk back are all one-way doors. These are moments to slow down, pressure-test assumptions, and be honest about the long-term implications.

7. Proven functionality being rebuilt or scaled

Finally, when something has already been validated, rushing the implementation can be counterproductive. That’s how teams end up with fragile systems, spaghetti code, and a growing backlog of bugs.

I’m painfully aware of this one, partly because my husband works as a developer at an edtech startup and spends a large part of his time untangling exactly these kinds of rushed implementations. The time saved upfront is almost always paid back with interest later.

Speed is the default. Perfection is selective.

Most subscription teams don’t fail because they move too fast. They fail because they wait too long to learn. Certainty doesn’t come from better planning, more sign-offs, or cleaner spreadsheets; it comes from shipping, observing, and deciding.

It’s a balancing act between certainty and risk:

Fast feedback is a competitive advantage, not because it guarantees success, but because it helps you stop wasting time on the wrong things sooner. Speed doesn’t have to mean sloppy work or broken trust. When done well, it’s about narrowing the learning question, testing the smallest meaningful assumption, and moving on quickly when something isn’t working.

There are moments where slowing down is not only justified but necessary. When trust, safety, irreversibility, or core values are on the line. But these moments are the exception, not the rule. For most early-stage teams, speed should remain the default. Perfection is something you apply selectively, when the cost of getting it wrong outweighs the cost of waiting.

How Cem Kansu helped Duolingo scale monetization without breaking freemium

Wed, 21 Jan 2026 13:46:55 GMT

Duolingo is one of the clearest examples of freemium done right. Tens of millions of daily users. A massive free experience. And a subscription business that generates the vast majority of its revenue—without gutting what made the product valuable in the first place.

In this episode of Sub Club, Cem Kansu—former VP of Product at Duolingo—walks through the decisions, trade-offs, and hard calls behind that balance. What stands out isn’t a clever pricing trick or a perfectly tuned paywall. It’s a philosophy: protect the free experience, even when short-term revenue is tempting.

Here are the core lessons every subscription app builder can take from Duolingo’s journey.

Protect the free moat—always

One of the biggest traps in freemium is also the easiest win: take something free, make it paid, and watch revenue spike.

Cem has seen this play out repeatedly—and warns it rarely works long-term.

At Duolingo, the free experience wasn’t just a funnel. It was the product’s moat. Locking too much behind a paywall might boost metrics for six months, maybe a year. But it weakens the growth engine and creates space for competitors to offer what you just took away.

Free value isn’t charity. It’s strategy.

Duolingo’s early success came from doing something incumbents wouldn’t: offering high-quality language learning completely free. Undoing that advantage would have meant undoing the company’s differentiation. So instead of extracting more from free users, the team focused on preserving—and often expanding—the free experience, even when it meant saying no to revenue-positive ideas.

Freemium isn’t a trade-off—it’s the growth engine

At Duolingo, free users were never treated as freeloaders. They were the primary distribution channel.

Word of mouth fueled growth, and word of mouth only worked if the free product delighted people. When free users learned more, progressed faster, and felt respected, they told their friends. That loop compounded.

This is why Duolingo was willing to do something that feels counterintuitive to many subscription teams: move features from paid back to free.

When features like Practice Hub or “Explain my answer” didn’t justify their revenue impact—or became cheaper to run thanks to AI efficiency—the team intentionally took a revenue hit to strengthen the free experience. The short-term numbers dipped. The long-term growth engine got stronger.

That trade-off only makes sense if you believe free users are part of your business, not a cost center.

Monetize with empathy, not extraction

Introducing monetization to a previously free product is as much a cultural shift as a product one.

When Duolingo added ads, the team expected backlash—and they got some. But instead of reacting emotionally to negative reviews, they zoomed out. They measured everything: retention, app closes, review volume per million DAUs, complaint rates across different issues.

What they found was grounding. Ads created noise, but they didn’t meaningfully damage the core experience when done carefully.

The rule was simple: optimize for trust, not ARPU.

Ads only appeared after a lesson—never before, never during. Categories that felt off-brand or unsafe were blocked, even if it cost revenue. Over time, Duolingo went further, partnering directly with advertisers to create custom ad formats that fit the product’s tone and even extended its character-driven world.

The goal wasn’t to squeeze users harder. It was to monetize in ways that felt fair, predictable, and respectful.

A/B test relentlessly—but know when to ignore the data

Duolingo runs hundreds of experiments at any given time. Testing is foundational to how the product evolves.

But Cem is clear: experimentation isn’t the same as outsourcing judgment to dashboards.

Many tests surface uncomfortable trade-offs—revenue up, learning quality down; engagement up, trust eroding slowly. In those moments, the job of product leadership isn’t to follow the green line. It’s to decide whether the result aligns with the company’s long-term goals.

Some of Duolingo’s most important decisions required taking a measurable loss: lower revenue, lower short-term engagement, worse-looking graphs. Those calls often needed senior buy-in because the upside—stronger learning, deeper trust, long-term growth—couldn’t be fully captured by a single metric.

Data informs decisions. It doesn’t make them.

Ads can be strategic—and even creative

Duolingo didn’t just “add ads.” It treated ads as part of the product experience.

Placement mattered. Timing mattered. Quality mattered.

Ads only appeared at natural breaks, never interrupting learning. Programmatic categories were aggressively filtered. And increasingly, Duolingo shifted toward direct brand partnerships, embedding its own characters into ads to make them feel less jarring and more native.

Internally, ads weren’t just monetization. They were another surface to reinforce brand, tone, and user expectations—while still funding free education at scale.

Build for everyone, not a persona

One of Cem’s most contrarian takes: personas are often a liability at scale.

Language learners don’t fit clean buckets. People learn for work, for travel, for family, for identity, for fun. Optimizing for a single “core persona” risks alienating the long tail that actually drives growth.

Instead of narrowing the audience, Duolingo built systems flexible enough to serve wildly different motivations—without forcing users into rigid paths. That inclusivity is part of how the product scaled from millions to tens of millions of users without fragmenting.

The throughline: take the long view

Across monetization, experimentation, ads, subscriptions, and AI, Duolingo followed a consistent principle: build the company you want to exist in 100 years, not the one that looks best this quarter.

That mindset made some decisions harder. It meant leaving money on the table. It meant resisting obvious optimizations. But it also built trust, sustained growth, and a freemium model that didn’t collapse under its own incentives.

For subscription app builders, the lesson is clear:
If you burn your free moat, you burn your future.

🎧 Listen to the full Sub Club episode with Cem Kansu to hear the stories, experiments, and trade-offs behind Duolingo’s monetization journey—straight from the person who led it.

Understanding Google Play’s subscription price changes: a complete guide

Wed, 21 Jan 2026 01:49:31 GMT

Subscription pricing is rarely static. Market conditions change, costs fluctuate, and business strategies evolve. At some point, you will likely need to adjust your subscription prices, whether increasing them to reflect added value or decreasing them to attract more users. However, changing subscription prices on Google Play is not as simple as updating a number in a dashboard.

Price changes affect existing subscribers differently than new customers, require specific notification flows, and must be handled carefully to maintain user trust and comply with Google Play’s policies. Luckily, this article will explain how subscription price changes work on Google Play in-depth. We’ll cover:

Mechanics of changing prices for both new and existing subscribers
Differences between opt-in and opt-out price increases
Notification requirements and timelines
Implementation details (with a walk through example)
How RevenueCat can help manage price changes gracefully across your subscriber base

How price changes affect different subscriber groups

When you modify a subscription price in the Google Play Console or via the API, the change doesn’t affect all users in the same way. Here’s how Google Play handles new subscribers and existing subscribers differently:

New subscribers

For new purchases, price changes take effect relatively quickly, typically within a few hours of making the change. Once the new price is active, anyone who initiates a new subscription purchase will see and pay the updated price. No special handling is required for this group; they simply see the current price when they reach the purchase screen.

Existing subscribers: the legacy price cohort

Existing subscribers are a different matter entirely. By default, when you change a subscription price, current subscribers are placed into what Google calls a legacy price cohort. These users continue paying their original price at each renewal, completely unaffected by the price change. This default behavior protects users from unexpected billing changes and gives you control over when and how to migrate them to new pricing.

This legacy cohort mechanism means changing a price in the Play Console does not automatically change what existing subscribers pay. You must explicitly choose to migrate subscribers to the new price.

Ending a legacy price cohort

When you decide to move existing subscribers from their legacy price to a new price, you use the price migration API. This initiates either a price increase or price decrease flow, depending on whether the new price is higher or lower than what users currently pay.

Using the migration API

To migrate subscribers to a new price, you call the monetization.subscriptions.basePlans.migratePrices endpoint on your backend side:

The migration is specific to each region, allowing you to roll out price changes gradually across different markets or handle regional pricing differences independently.

Price decrease flow

When the new price is lower than what users currently pay, the migration process is straightforward and easy for users. Price decreases are automatically applied without requiring explicit user acceptance.

How price decreases work

When you migrate subscribers to a lower price, Google Play sends email notifications informing users of the price decrease. Users then begin paying the lower price at their next renewal, and no user action is required since the decrease happens automatically.

There is one timing nuance to be aware of: Google Play may authorize payment up to 48 hours before renewal (or up to five days in India and Brazil). If a user’s payment was already authorized at the higher price before the decrease was applied, they will pay the higher price for that renewal but will receive the lower price on subsequent renewals.

Handling price decreases in your app

From an implementation perspective, price decreases require minimal handling. You may want to communicate the good news to users:

Price decreases are generally positive events for users, so your primary concern is ensuring they are aware of the change rather than managing any acceptance flow.

Price increase flow: opt-in increases

Price increases are more complex because they require user awareness and, in most cases, explicit acceptance. The default method for price increases is the opt-in flow, where users must explicitly agree to the new price before being charged.

The opt-in timeline

The opt-in price increase flow follows a specific timeline with distinct phases:

Phase	Duration	What Happens
Freeze period	Days 1 to 7	Google Play sends no notifications; developer can notify users
Notification period	Days 8 to 37	Google Play sends email and push notifications
Effective date	Day 37 onwards	Price increase takes effect; charged at next renewal

The seven day freeze period at the beginning is intentional. It gives you the opportunity to notify users through your own channels before Google Play’s automated notifications begin. This allows you to control the messaging and potentially explain the value users receive for the increased price.

User acceptance requirement

For opt-in price increases, users must explicitly accept the new price. They do this through the Play Store subscription management screen, where they see a dialog explaining the price change and can either accept or decline.

If a user doesn’t accept the price increase before their first renewal at the new price, their subscription is automatically canceled. They retain access until the end of their current billing period, but the subscription will not renew.

Handling opt-in increases in your app

Your app should detect pending price increases and guide users through the acceptance process:

Communicating value during price increases

The freeze period is your opportunity to communicate directly with users about why the price is increasing. Effective communication can significantly improve acceptance rates:

Price increase flow: opt-out increases

In certain regions and under specific conditions, Google Play allows opt-out price increases. With opt-out increases, users are notified of the price change but are automatically charged the new price unless they explicitly cancel or change their plan.

Eligibility requirements

Opt-out price increases are not universally available. Eligibility depends on several factors including regional availability (only certain countries support opt-out increases), frequency limits on how often you can use them, maximum percentage or absolute amount restrictions per country, and additional developer eligibility requirements. Because of these restrictions, opt-out increases should be considered a supplementary option rather than your primary approach to price changes.

Opt-out timeline

The opt-out timeline differs from opt-in increases:

Aspect	Opt In	opt-out
Freeze period	7 days	None
Notification period	30 days	30 or 60 days (varies by country)
User action required	Must accept	Can cancel to avoid
Default behavior	Subscription cancels	New price charged

The notification period for opt-out varies by country. Some require 30 days notice, while others require 60 days. Google Play handles these regional requirements automatically when you initiate an opt-out migration.

Handling opt-out increases

From an implementation perspective, opt-out increases are simpler because users do not need to take action to continue their subscription:

However, you should still communicate clearly with users about the upcoming change, even though their action is not required.

In-app notification requirements

Regardless of whether you use opt-in or opt-out price increases, Google Play requires you to display in-app notices about price changes. This requirement applies across all device types where your app runs.

Mandatory notification surfaces

You must show price change notifications on mobile devices (phones and tablets), Android TV, and other streaming devices. The only exception is watches, where in-app notification is recommended but not strictly required due to the limited screen real estate.

Notification timing

For opt-in increases, the recommended approach is to show your own custom messaging explaining the value proposition during the freeze period (days one to seven), then continue showing reminders and use Google’s In App Messaging API after the freeze period ends (days eight onwards).

Handling overlapping price changes

What happens if you initiate a new price change while a previous one is still pending? Google Play handles this by canceling the previous price change and applying the new one.

The cancellation and replacement flow

When overlapping price changes occur, the old price migration is marked as CANCELED and you receive a SUBSCRIPTION_PRICE_CHANGE_UPDATED Real-Time Developer Notification (RTDN). The new price migration then takes effect, and users only need to respond to the latest price change. This behavior prevents users from being forced to accept multiple sequential price increases, which would create a poor user experience.

Tracking price change status

Your backend should process RTDN notifications to track price change status:

Recovering from accidental price changes

Mistakes happen. If you accidentally change a price or initiate a migration you did not intend, the recovery process depends on the type of change and how much time has passed.

Reverting opt-in increases

For opt-in price increases, the timing of your revert matters significantly. If you revert within seven days (the freeze period), users will not have received any notifications from Google Play, so the change is essentially invisible to them. After seven days, reverting will cancel the price change for users who have not yet been charged at the new price, but some users may have already received notifications, which could cause confusion.

Reverting opt-out increases

For opt-out price increases, reverting to the original price cancels the increase for users who have not yet been charged. Keep in mind the authorization timing. Users whose payment was already authorized (up to five days before renewal in some regions) may still be charged.

Reverting price decreases

If you need to cancel a price decrease and return to the original higher price, start by reverting to the original price in the Play Console and choosing whether the increase should be opt-in or opt-out. The timing relative to user renewals determines the outcome: if the time between revert and user renewal is greater than the notification window (30 to 60 days depending on country), users will pay the original price at their next renewal. If the time is less than the notification window, users will be charged the lower price once, then go through the standard price increase notification flow.

Installment subscriptions and price changes

If your subscription uses installment plans (where users commit to a certain number of payments), price changes behave differently.

For installment subscriptions, price changes only apply at the end of the active commitment period. You cannot change the price for users in the middle of an installment, and the new price takes effect at the first renewal after the commitment ends. For example, if a user is on a 12 month installment plan followed by monthly auto renewal, any price change you make will only take effect after their 12 month commitment completes and they move to the monthly renewal phase.

Testing price changes

Before rolling out price changes to your production subscriber base, you should thoroughly test the flows using Google Play’s testing tools.

Using license testers

License testers can receive price change notifications without affecting real subscribers. Configure license testers in the Play Console and use them to verify notification delivery and timing, in app messaging display, acceptance and decline flows, and state transitions in your backend.

Play Billing Lab

Google provides the Play Billing Lab app for testing billing scenarios. Use it to simulate price change scenarios and verify your app handles each state correctly.

Audit trail

The Play Console maintains a change log of all price modifications. Use this to review when prices were updated, who initiated the changes, and which regions were affected. This audit trail is invaluable for investigating issues or reviewing the history of accidental changes.

How RevenueCat simplifies price change management

Managing price changes across a large subscriber base involves significant complexity. This includes tracking migration status for each user, processing RTDN notifications, displaying appropriate in-app messaging, and handling edge cases. RevenueCat abstracts away much of this complexity while providing additional tools for managing price changes effectively.

Automatic state tracking

RevenueCat processes Google Play’s RTDN notifications on your behalf, maintaining up to date subscription state including pending price changes. Instead of building infrastructure to receive and process notifications, you simply query RevenueCat for the current customer state:

RevenueCat’s CustomerInfo includes a managementURL property that provides a direct link to Google Play’s subscription management screen. This is where users can accept or decline price changes:

Cross-platform consistency

For apps that span multiple platforms, RevenueCat ensures consistent subscription state across Android, iOS, and other platforms. If a user accepts a price change on one device, the updated status is reflected across all their devices without additional implementation.

Webhooks for server side handling

RevenueCat provides webhooks that notify your server of subscription events in a normalized format. This is simpler than processing raw RTDN notifications and includes events related to price changes:

Analytics for price change impact

RevenueCat’s Chart provides analytics that help you understand the impact of price changes, including churn rates correlated with price change timing, conversion rates for subscribers who received price increase notifications, and revenue impact analysis before and after price changes. These insights help you make informed decisions about pricing strategy and identify the optimal timing and communication approach for future price changes.

Best practices with RevenueCat

When using RevenueCat for price change management, focus on proactive communication by using customer attributes to identify users with pending price changes and send targeted communications during the freeze period. Monitor key metrics such as the conversion rate from price increase notification to acceptance and the churn rate among affected users. Always provide users with an easy path to the Play Store subscription settings via the management URL. Finally, leverage RevenueCat’s normalized data to handle edge cases gracefully, such as users who change plans during a pending price increase.

Best practices for subscription price changes

Based on the mechanics we have covered, here are key practices to implement for successful price changes:

Plan your communication strategy

Before initiating a price change, plan how you will communicate with affected users. Prepare messaging that explains the value users receive, decide whether to use the freeze period for custom outreach, and consider offering alternatives such as annual plans or grandfathered pricing for users sensitive to price changes.

Use regional rollouts

If you are increasing prices globally, consider rolling out changes region by region. Test in smaller markets first to gauge response, adjust messaging based on early feedback, and allow time to address issues before they affect your largest markets.

Monitor acceptance rates

Track how many users accept opt-in price increases versus letting their subscriptions cancel:

If acceptance rates are lower than expected, you may need to adjust your communication strategy or reconsider the price increase amount.

Provide alternatives

Users who are unwilling to pay the higher price may be willing to continue at a different tier. Consider offering a downgrade path to a plan with lower pricing, providing an annual option at a discounted effective monthly rate, or creating a ‘lite’ tier that retains users who would otherwise churn.

Handle the transition gracefully in your app

Ensure your app gracefully handles all states during a price change. Users with pending price increases should see clear messaging, users who decline should not lose access immediately, and the transition between prices should be seamless for users who accept.

Conclusion

Subscription price changes on Google Play involve a carefully orchestrated process designed to protect users while giving developers flexibility. The key concepts to understand are the legacy price cohort that shields existing subscribers from automatic price changes, the distinction between opt-in and opt-out price increases and their respective timelines, the notification requirements that apply across device types, and the regional variations that affect timing and eligibility.

For price decreases, the process is straightforward. Users automatically receive the lower price at their next renewal. For price increases, the default opt-in flow requires explicit user acceptance, with a seven day freeze period followed by 30 days of Google Play notifications before the effective date.

Implementing price changes directly requires processing RTDN notifications, maintaining subscription state on your backend, and building UI to guide users through the acceptance process. RevenueCat simplifies this by handling notification processing automatically and providing normalized data, analytics, and the management URL for user actions, so you can focus on your business and more important work.

Whatever approach you take, successful price changes require clear communication with users about the value they receive. The freeze period is your opportunity to control the narrative before automated notifications begin. Use it wisely, and you can maintain user trust while adjusting your pricing to reflect the value your app delivers.For complete documentation on subscription price changes, refer to the official Android Developer documentation and RevenueCat’s subscription management guide.

How subscription apps can use hybrid monetization to capture more revenue

Mon, 19 Jan 2026 12:10:22 GMT

Hybrid monetization means combining subscriptions and additional ways to earn money from users — think in-app purchase (IAP), consumables, ads, or partnerships.

But before we go much further, I want to emphasize something: the goal isn’t to replace subscriptions. It’s about complementing them. As different users discover, use, and leave your app, hybrid monetization captures as many of them as possible.

Why hybrid monetization? The limits of subscription-only models

I’ve been advocating for hybrid monetization for a long time because acquisition is essentially a business model competition: more ARPU = a better position in the paid auctions, faster payback, and more margin to invest in retention, onboarding etc. So while subscriptions are great, they come with a fundamental flaw: a high floor, low ceiling nature (more on this in a moment).

Subscriptions are binary: pay, or don’t.

But real demand is not binary — it’s distributed across willingness to pay.

Based on the graph above (from the State of Subscription Apps 2025), it’s expected that 90% of users won’t convert, and for a number of verticals, regions, and non-iOS platforms, it gets even worse. Last year, I saw an app attract over a million users in one country, only to get less than 1,000 paying subscribers!

The problem is that a single recurring price assumes that most users have roughly the same willingness to pay. But in reality, some users are happy to pay a premium, others get occasional value but can’t justify a recurring commitment, many will never subscribe at all.

This creates two common blockers:

The high-ceiling problem

A single offer presents too much friction for low-intent users. You can try to discount it or shorten the subscription length, but some users (such as Android users in developing countries) still won’t engage.

Many will never subscribe. They still generate value (attention, data, virality), and some may be willing to be something — if offered differently (enter in-app purchases, for example) or at a lower price point.

Problem: you’re leaving revenue on the table from low-intent users. Users who value the app, but won’t cross the psychological or financial barrier of a subscription.

The low floor problem

Maybe even worse than a high ceiling… The majority of subscription models have no ‘whales’ (aka, mega spenders). Gaming apps, who pioneered hybrid monetization (typically IAP + ads), can see a handful of users accounting for a large share of revenue, even if other users contribute less. For example, I once saw numbers from a large ‘match three’ game showing that <2% of its 2% payers (i.e. 0.04%) actually generated more than half of revenue. Subscription-only apps lose this possibility.

Problem: you under-monetize high-intent users, as your subscription price can’t move higher without hurting conversion of other users.

At its core, hybrid monetization is about matching price granularity to demand granularity.

Adapting to the demand curve

Most apps serve users with very different levels of intent, frequency, and urgency. A single subscription price flattens those differences.

Visually, you can think of your audience as a demand curve:

On the left: users willing to pay more for power, speed, or convenience
On the right: users who won’t pay anything
In the middle: users who want value occasionally, but resist subscriptions=

Hybrid monetization places the correct monetization lever at the ideal point on that curve, for every user, and avoids forcing everyone into the same choice.

The demand curve of app monetization is extreme, and could be represented this way:

By choosing a single point on the line, binary subscriptions models are leaving a lot of money on the table:

There are a variety of options to improve the offer and increase ARPU by adapting to your demand curve. Here are some of those levers:

Techniques for hybrid monetization (with app examples)

All the instances of hybrid monetization that I’ve worked on and observed keep subscriptions as the core center of gravity, then add layers on top. Let’s go through some examples.

1. Pricing and packaging

I won’t go into this in much depth, but the most obvious and first step towards more sophisticated monetization is adjusting pricing and packaging. This is already happening a lot, thanks to increasingly-easier ways to A/B test paywalls.

In this step, developers can (and should) experiment with different pricepoints, combinations of plans (e.g. how many plans do you offer? Are they weekly/monthly/yearly?), segmentation (which I predict will finally become a thing thanks to AI after years of lag), price localizations etc.

A fairly extreme example is the discount flow from Headway, which moves offers all the way from €89.99 to €21.99 in my personal case:

2. Subscriptions tiers

While offering multiple tiers of subscription isn’t strictly ‘hybrid’ (as it’s still only subscriptions), it moves towards hybrid monetization by adjusting to the demand curve.

Software-as-a-service (SaaS) businesses have done this successfully for some time by offering tiered-features to different user profiles. One example is Photoroom, which offers Photoroom Pro, Max and Ultra to different segments of users , based on usage patterns.

Subscription behemoths Noom and Tinder both user tiers as well:

While not strictly a subscription tier per se, many developers with a portfolio of different apps choose to bundle as a way to upsell a higher pricepoint. Examples include Monkey Taps (in-app and in the app stores) or Reflectly (on web).

3. Subscriptions + ads

Ads are maybe the most obvious ways to monetize the 90% of users who show zero willingness to pay for anything (regardless of pricepoint). I remember trying a 99% off discount only to have little incremental uplift on conversion rate. If you have users like this, supplementing with ads can be a good technique.

A well-known example of this use case is subscription role model Duolingo, who combine their core freemium offer with ads, plus premium plans to remove ads, and IAP. Some case studies suggest developers can expect revenue uplift of 10-30% with subs + ads, depending on their user base and execution.

However, it’s worth bearing in mind that revenue here is limited for hard paywall apps. Spotify, for example, makes less than 5% of its revenue from its majority users: free users who put up with ads. In another case I worked on it was as low as 1%.

Considerations when implementing subs + ads

Privacy laws, apps with ad SDKs, effect on churn and many more things should be considered when including ads in your app. Some good resources to look at are:

Techniques for subscription + ads

Some apps think of ads not as a way to add revenue, but a way to create friction and promote the ad-free offering: a subscription. For instance, Impulse prompts users to remove ads in different strategic places:

In this flow (from GrowthGems), you can see how closing the ad triggers a subscription paywall with weekly and lifetime plans. When closed, there’s then a non-renewable IAP to remove ads for $4.99!

Gaming experts Matej Lancaric and Felix Braberg have agood video analyzing Impulse’s hybrid model. You can also use ad placements to promote your own subscription: this video shows Duolingo’s ad break — two ads show, one for NYT Games, then one for Duolingo MAX. It’s a bit meta, but it can work!

Finally, a simple banner can go a long way, like in this example from park4night (which interestingly drives to an off-store, even outside the US).

4. Subscriptions + partnerships

By ‘partnership’, I mean an alternative to the common ads model sold via SDK with partners such as Applovin, Unity or Admob. In specific verticals, partnering up with a relevant brand can yield significant impact — and potentially revenue — depending on the vertical, as they may add value, including for premium customers.

See for instance Strava’s Sponsored Challenges:

Such partnerships can be implemented at very different trigger points of the journey, as illustrated below with Prematch:

5. Subscriptions + ecommerce/affiliates

As mentioned earlier, one of the limits of the subscription-only model is that it doesn’t offer your bigger power users and ambassadors any opportunity to engage further with the brand. So one way to supplement subscriptions is by adding ecommerce or affiliate strategies.

For example, a few mega fans might be willing to buy brand swag or physical goods, like Lingokids:

Sometimes, the ecommerce opportunity lives within the product, such as the anglers’ social network app, Fishbrain, having a marketplace:

As a more indirect tactic, you can partner with other businesses to offer deals or discounts to your users, like Revolut does:

6. Subscriptions + consumables/one-off in-app purchases (IAPs)

Finally, here is the biggest potential uplift (for most apps): offering consumables and one-off IAPs alongside your subscriptions. These have great rewards for app businesses, yet are still vastly underutilized.

RevenueCat’s State of Subscription Apps 2025 report shows limited use of consumables — except in gaming (~40%) — with only 5–15% of apps using these monetization models.

While few apps are taking this route, the few that do monetize much better: a recent stat showed that hybrid buyers make up only 7% of buyers, but generate 25% of total revenue.

Non-renewable/consumable items fit many use cases that subscriptions don’t cover, either substituting for a subscription (which wouldn’t be purchased) or slotting on top as an additional spend. Depending on the app, those consumables may be very different things — one example is ‘boosts’ which are pretty common in dating apps or marketplaces, such as Tinder or Wallapop:

In-app purchases can also be used to enable price-sensitive users to unlock premium features individually, or for a limited time. For instance, one learning app I worked with added a one-time IAP which granted access to all content for a couple of days (a ‘weekend pass’). We also added IAPs to gain access to very specific lessons without having to unlock the rest of that content tier.

Consumables can also be upsells, which have proven particularly effective in the health and fitness space; for example, guides to train specific body parts, certain individual coaches, dedicated workout or meal programs… These are sometimes even sold as a direct upsell right at onboarding, though this is a tactic I’ve seen work better on web (once the payment is recorded) than in-app.

The possibilities for IAP are endless: Nebula sells one-off tarot readings and 1:1 chats with psychics, Duolingo offers individual tests and certifications. Many apps offer tipping, stickers, customization, and more.

One caveat for consumables, and probably the elephant in the room here, is AI.

Because AI comes with significant costs, the cost of use can vary massively between users who are charged the same. Maybe the first hybrid AI model I’ve seen was Lensa AI, which was selling 200 AI avatars for $9.99, but entering the subscription allowed you to get 50% off the credit price. (I thought it was interesting that they specify why it’s a paid feature.)

Alongside tiered subscriptions like ChatGPT, these single-payment purchases for extra use are becoming more common among AI apps.

7. Pile them up: combine hybrid monetization options

Hybrid options are additive, not mutually exclusive, so why not stack them? The most advanced subscriptions apps don’t just pick up one way to upsell — they combine several.

This diagram from Phil Carter, creator of the Subversive podcast and the famous Subscription Value Loop, shows how Tinder adapted to the demand curve. Ravi Mehta, Former Chief Product Officer at Tinder, spoke about their strategy in depth on the Sub Club podcast — I highly recommend giving it a listen for examples of hybrid monetization in action.

Here are some ways you can combine multiple non-subscription revenue streams.

Offer everything!

For instance, weightloss app Simple offer users an upsell to skip the trial period, then offer different subscription tiers, and then also offer one-off purchases for in-app guides. It’s a lot.

Me app also has a similar pattern, with coaching, goodies, and upsells in addition to the core subscription:

Bundle physical and digital goods

Another innovative example, albeit less common, is to bundle digital and physical goods. This feels suited to luxury brands or designers, but it could work for any app. Arya does this in its initial offering and later through store upsells:

While the specifics of those examples differ, the logic is the same: it’s hard enough to convert users into paid subscribers, so if there’s an opportunity to monetize subscribers in extra ways, take it. Demolish that low floor and find your big spenders, even if they’re few and far between. If there’s an opportunity for a big ARPU increase, whether on the spot (e.g. onboarding) or later (e.g. merch), it’s worth pursuing.

Offer them even more

More and more subscription businesses operate beyond pure B2C models, often with a mix of end consumer, ‘prosumer’, small businesses, and even larger businesses. This is particularly common in graphics, photo, and video tools. One example is Photoroom: on top of its several subscription tiers, Photoroom offers B2B plans for clients that go beyond heavy user requirements:

Caveats and considerations before implementing hybrid monetization

Hybrid monetization isn’t a free win, it takes planning and practice. And like anything in app monetization, there are risks. But the most common blockers are predictable:

For users, choice overload can hinder conversion

Every new monetization path should earn its place, especially at decision points. Otherwise you risk too many options leading to no decisions. How and when the options are offered is critical. For example, Netflix has found when it shows more than seven titles per row, user engagement drops. This is also a good blog detailing examples of Hick’s Law and other choice overload instances, featuring the likes of Duolingo, Zapier, Airbnb and Trello.

For developers, complexity creeps up quickly

More SKUs = more logic and more edge cases.

This might be the biggest caveat: hybrid monetization is definitely not for everyone. Hybrid models fail more from organizational structure than product design: various teams will see their current KPIs affected, so new alignment needs to happen between monetization, UA, and product teams.

Offering multiple options requires stronger product, data, and ops discipline, and can add up on data and tech debt quickly — especially if many rounds of experimentations are required to find what clicks with your audience from the get-go.

For many earlier-stage or smaller teams, this is actually a very good reason to stick with a pure subscription model initially.

Hidden signals and risk of cannibalization

Measuring the actual uplift of hybrid monetization might look straightforward, but it isn’t! Discounts can be detrimental. Poorly designed IAPs can undermine subscriptions. Aggressively-priced consumables can just be shifting revenue to earlier (which arguably, is still great for cash flow even under similar LTV), but hurt renewal revenue later and eventually decrease LTV. Ads could inflate short-term ARPU while depressing long term retention and late conversions.

Even simple pricepoints changes can have multiple, long-lasting impact on renewals, retention, upsell potential.

In short: be conscious of the analytics required before jumping in — hybrid monetization creates some of the most convincing false positives.

Country and culture dependencies

There’s a massive monetization gap in subscriptions between platforms (this is the reason the Google Play team was an early advocate for mixed models). For example, low-amount IAPs are often more impactful on Android than iOS, due to different user profiles and intent.

Payment habits, ad tolerance, and price sensitivity also vary massively by location. Spotify didn’t scale meaningfully globally for some time, while Tencent music (which offers pay-per-song, one-off purchases, and tipping) is a global success. Some cultures are currently just more reluctant to engage with long-term subscriptions (e.g. China), while others are skeptical of silent auto-renewals (e.g. Germany), so mixed models can benefit hugely in these contexts.

On top of local habits, you have specific regulations, from Japan and Korea’s 2025 changes plummeting renewal rates, and California’s ‘click to cancel’ law being proposed.

Wrapping up: is your app ready for hybrid monetization?

We’ve covered a lot. You have many potential frameworks for hybrid monetization, and many pros/cons to consider before getting started. So to finish up, here’s the questions to ask yourself before introducing a new revenue stream:

Do we clearly understand who our high-, mid-, and low-intent users are?
Do we have reliable cohort-based retention and revenue data?
Can we run clean experiments without stacking changes?
Do we know which metric we’re willing to trade off — and which we aren’t?

If you can’t answer these yet, fix that first. Hybrid monetization only works if you introduce it deliberately. Otherwise, it’s messy, chaotic, and reactive. Don’t get caught out misreading misread short-term gains while harming long-term retention.

Hybrid monetization works when:	Hybrid monetization is *not*:
You have a large group of users who get value but won’t commit to a recurring price Your users’ willingness to pay varies widely You want to increase ARPU without relying solely on higher subscription prices	Throwing every possible paywall and ad format at users A shortcut to growth without proper measurement A substitute for a strong core subscription offering

Remember there is no hack: Hybrid monetization is not a shortcut to fixing poor ARPU. If subscriptions aren’t delivering clear, repeatable value, adding more monetization layers will only make things worse. Bad products monetize badly, and they will only do so in more ways with more sophisticated models.

NaadSadhana — the app that teaches classical music like a guru

Wed, 14 Jan 2026 13:51:40 GMT

When a long-time student still couldn’t distinguish close intervals, Sandeep Ranade didn’t write another lesson plan — he wrote code. NaadSadhana blends Indian classical music with real-time, AI-assisted feedback so vocalists can train like professionals. This is how passion, patience, and purpose shaped the product.

From Microsoft to music mastery

“I’m from Pune… I did my master’s in computer science from Johns Hopkins University in America in Baltimore. I’ve worked at Microsoft… then at Google,” Sandeep says. After more than a decade in Silicon Valley, he and his wife — then at Apple — moved back to India “to do something that we were interested in, that we wanted to do.”

He had been teaching Hindustani classical music since 2005. “There was a student … she said, please help me. I’m frustrated with my journey. I’m not making any progress.” That single conversation revealed the problem that would define his next decade.

Solving a real problem, one note at a time

“In the first 10 minutes, it became painfully clear that she had major problems in note recognition itself,” Sandeep recalls. “She couldn’t recognize half of them. She would just know the big ones and then all the minor notes she would sort of miss out on.”

A doctor ruled out tone deafness, leaving Sandeep to diagnose the issue himself. “She had gotten into some bad habits … when she was learning and practicing, she didn’t get enough guidance to course-correct as she was making the mistakes. So those mistakes became the habit.”

He wanted a tool that could give her feedback whenever she practiced — something a human teacher couldn’t provide around the clock. “I thought, hey, it’s 2017. There must be an app that does this by now.” But, he found, “sadly, there was no single app that did this for human vocals. There were thousands of guitar tuners on the App Store, but not a single app that did human vocal tuning and guidance.”

To fix that, he dove deep into digital-signal processing and psychoacoustics. “It took my iPhone 7 Plus battery from about two days to 20 minutes. I could have probably made an omelet on my phone,” he laughs. After nine iterations, he finally had “an algorithm that was correct, accurate, fast, and battery efficient.”

When he tested it with his student, the results astonished him. “She was able to go from a score of 5 percent to 80 percent. It took her two weeks. I was not expecting this.”

Tech meets tradition

“There was an ancient system of learning in India called the guru-kul. Guru is the teacher, kul is the home. So the student would go live with the guru traditionally and learn the craft for years and would be instructed and guided for eight, ten hours a day or more.”

That continuity, he says, produced extraordinary precision. “Today, students are learning an hour a week, practicing by themselves many times a week without any guidance. And the danger is that if you practice something multiple times without knowing whether you have gotten it right or not, that is where things start to become kind of dangerous.”

NaadSadhana became a digital re-creation of that traditional mentorship — a tireless teacher able to correct singers in real time.

Building slowly, scaling sustainably

“I never realized that an app needs to be promoted and there’s marketing involved,” Sandeep says. “I just put it up on the App Store … I probably broke even on my developer fees.”

Early users spread the word organically. “Some people said to other people that, ‘Hey, I’ve been using this app, my notes are improving.’ I told it to a few people that I know and that was it.”

In 2021, that quiet persistence led to worldwide recognition. “I attended the Apple Design Award ceremony [as an audience member], looking at all of these beautifully designed apps … and in 2021 NaadSadhana won for innovation. I’m only the second Indian to ever win this award.”

Evolving the sound of the future

“I’ve had offers to buy out the app, and the only question I ask them every time is: What feature would you add next? … It now truly seems that I’m the only person who’s passionate enough to evolve this app in the way that I care about.”

For Sandeep, NaadSadhana is an artistic calling, not just a product. “There are things that people don’t know that I’ve done that will not matter to the vast majority of people, but it’ll matter to me. From a business point of view it’s not truly necessary, but from an artistic point of view it makes the world of a difference.”

What app builders can learn from NaadSadhana

“I typically tend to solve problems for me or people who are close to me,” he says. “Because I am the first customer of my solution … there are no compromises.”

That builder-first mindset shaped every decision. “It has to behave a certain way … nothing less than that will be acceptable.”

And rather than chase growth, he focused on depth. “I was focused more on the feature set and capability of the app … I thought that the more capable I make the app, the more attractive it’ll be to people … and that has been happening.”

Final takeaway

Sandeep calls NaadSadhana’s underlying technology “artistic intelligence.” “What my app is doing is enhancing humans. I’m giving them a flight simulator, not a self-driving car.”

That philosophy extends to accessibility. “Music without any barriers, without any boundaries,” he says. “Just because a person doesn’t have eyesight shouldn’t make it a barrier to be a musician or to create content.”

NaadSadhana shows how technology can deepen — not dilute — tradition. Design for mastery, not virality, and you’ll earn trust that lasts.

Introducing one-tap purchases for paywalls on the web

Tue, 13 Jan 2026 17:01:11 GMT

Your customers already decided to buy.

Checkout is where too many of them slow down, hesitate, or drop off.

Express Checkout adds a native wallet purchase button directly to your paywall when it’s shown in the browser, so customers can complete a purchase in one tap without being sent to a separate checkout page.

Checkout slows customers after they’ve already decided

By the time someone reaches your paywall, the work is mostly done. They understand the value, they’ve accepted the price, and they’re ready to move forward.

Then the flow asks them to leave.

They wait for a checkout page to load, choose a payment method, re-enter information their device already knows, and confirm a decision they already made. None of those steps build confidence or clarify value. They only introduce delay.

Checkout doesn’t persuade. It drains momentum at the exact moment it matters most.

Moving the purchase onto the paywall removes a full step

In a typical web flow, the paywall creates intent and hands customers off to another page to finish the purchase.

With Express Checkout, the purchase completes where the decision happens.

Customers tap a native wallet button on the paywall and the transaction is done. There’s no redirect, no form entry, and no extra decision between “yes” and “paid.”

That change removes an entire page from the funnel and several chances to abandon. It isn’t a visual tweak or a copy experiment. It’s a structural improvement to how purchases work in the browser.

What Express Checkout does

Express Checkout adds a native digital wallet button directly to your paywall when it’s shown on the web.

The component automatically renders the right option for each user, such as Apple Pay on iOS or Google Pay on supported Android devices and browsers. When a customer taps it, the device’s native payment prompt appears immediately and the purchase completes without going through the standard checkout flow.

On mobile, this feels closer to an in-app purchase than a traditional browser-based flow. The most failure-prone step in the journey disappears.

See the docs for configuration steps and wallet requirements.

It works for web, app-to-web, and web-to-app flows

Express Checkout improves conversion anywhere a paywall is the moment of decision.

Pure web entry

A customer taps an ad, a social post, or a link in your newsletter and lands on a paywall in the browser. They read the offer, decide it’s worth it, and complete the purchase immediately using their device’s native wallet. There’s no detour into checkout and no quiet moment where a new page loads and the impulse fades.

App-to-web completion

A customer starts in your app, hits a paywall, and finishes the purchase on the web. Instead of landing on a checkout page that feels disconnected from the decision they just made, they arrive at a paywall in the browser that mirrors the offer and lets them complete the purchase in one tap. The transition feels continuous rather than transactional.

Web-to-app journeys

A customer discovers your product on the web, purchases through a paywall in the browser, and then continues into the app. Even though the journey spans platforms, the purchase step stays fast and familiar. The paywall acts as a clean entry point, not a temporary stop.

In every case, the benefit is the same. When customers reach your paywall in the browser, Express Checkout removes unnecessary steps at the exact moment they’re ready to buy.

Standard checkout stays available automatically

When a native wallet is available and supported on the user’s device and browser, Express Checkout appears on the paywall and completes the purchase directly.

When a native wallet isn’t available, customers see a standard purchase button and continue through the full checkout flow as usual. Both options can coexist, guiding users to the fastest path while always preserving a reliable fallback.

Taxes, compliance requirements, and edge cases are handled behind the scenes. You reduce friction when you can, without ever blocking a purchase when one-tap payment isn’t available.

Full setup details, supported wallets, and fallback behavior are covered in the Express Checkout docs.

Get started

If you’re already using RevenueCat Paywalls on the web, you can add the Express Checkout in the Paywall Builder.

If you’re new to selling on the web, this is the fastest way to offer a one-tap purchase experience in the browser. It works with your existing products, trials, and offers, you’re changing the last step of the funnel, not your pricing model. We’ll share conversion results once teams start running experiments, and this same button also lays the groundwork for more advanced app-to-web paywall flows coming next.

5 web-to-app funnel examples that actually convert

Mon, 12 Jan 2026 15:11:46 GMT

We all say you shouldn’t copy your competitors, but the truth is, a handful of great examples can save you a lot of time. When it comes to web-to-app, some subscription apps have been doing this long before it was trendy, tirelessly testing and optimizing their funnels along the way. Besides, didn’t our parents always say imitation is the sincerest form of flattery?

To help you on your own web-to-app journey, here are a few of my favourite examples — plus what you can learn from them. Because there’s no point copying a funnel if you don’t understand why it works, or how to adapt it to your own brand. And don’t worry, this isn’t just a list of quiz funnels. There are plenty of ways to approach web-to-app, so we’ll cover a variety of funnel types.

That said, let me start with one of my favourite quizzes, and then I promise we’ll move on to some alternative approaches.

1: Calm’s web-to-app quiz funnel

Web funnel type: web quiz → trial offer → app install

Let’s start with what Gen Z would call the GOAT of quiz funnels (Greatest Of All Time, according to my little sister). Calm, the meditation app has long been a standout example of a web-to-app quiz funnel: simple, elegant, and remarkably effective.

I reviewed every quiz variant to understand why this flow has remained largely unchanged for years. Here’s what the full funnel looks like, but don’t panic at the sheer detail. I’ll walk you through it step by step. If you want to explore this flow (or any of the other examples) at your own pace, you can see them all in their full flowchart glory here.

The first thing to note is that Calm only truly personalizes the sleep flow; the other four options all lead to a standardized journey. This is a great example of intent-based segmentation, dividing up users according to their goals. Sleep is a high-urgency, emotionally-charged problem, so it makes sense to invest in deeper personalization. The other goals are more exploratory, so a lighter-touch flow is a pragmatic choice.

This is a tactic I often recommend to app testing teams: don’t try to personalize everything at once. Start with your highest-priority audience, then measure, learn, and iterate from there.

The sleep quiz flow

Let’s walk through the sleep flow first. It starts by asking how frequently you face this challenge.

It does something simple but effective: it gives immediate feedback on your answer.

This isn’t a separate screen; it’s a quick reassurance: “You’re in good hands.” From there, the quiz delves deeper, distinguishing whether you struggle to fall asleep or stay asleep, before exploring potential causes of your sleep challenges.

As a struggling insomniac, this felt great. There’s no judgment or irrelevant questioning, just a respectful interest in my challenges. I also like that you can select multiple options for both questions, rather than being forced to choose just one.

Next, a relevant review appears from someone I can relate to. The imagery and name make it feel personal, though not knowing the source slightly undermines its credibility. That said, Calm’s brand is already well known in the space, so the funnel doesn’t need to lean heavily on social proof beyond a simple, relatable review.

I also appreciate that Calm asks for context: Am I trying to sleep right now? Too often, we assume someone is using an app the moment they open it, when for many fitness and wellness apps, that may not be the case.

Interestingly, selecting either option doesn’t change the immediate next steps. But I can imagine it influences what comes later in the flow; for example, what Calm sends or shows you after signing up, like a general meditation versus a sleep story tailored to the moment.

Next, they ask you to set your preferences for the type of content you’re interested in. My only issue is that you may not yet know what you want; you may simply be seeking recommendations or open to exploring. Calm could do a better job of highlighting their suggestions and explaining why they recommend these.

Before we move on to the final screens (which are the same for all flows), let’s take a look at what happens when you select one of the other options:

Reduce stress or anxiety
Improve focus
Self-improvement
Something else

Calm’s alternative quiz flow

I tested all four options and ended up with the same flow each time. It starts with a clarification question about how I’m feeling, accompanied by the same kind of reassuring feedback used in the sleep flow.

Here, the flow first explores the cause — interestingly — and then loops back to dig deeper into understanding the problem.

We see a similar review slide again; this one is quite generic and doesn’t change across different responses. Given what I’ve shared so far, I would have expected a bit more personalization.

I do like that Calm asks about my level of experience and provides reassurance based on that. As someone who has endlessly tried to meditate, having the basics repeated over and over isn’t helpful; it’s frustrating. This step also signals to the user that the app works for them, whether they’ve meditated before or not.

The final part gives the user a sense of control:

Meditating can feel like just another task, so the app aims to strike a balance: not asking the user to do too much, nor too little, when they’re in a mindset of full dedication. It then attempts to understand the user’s current emotional state and when they plan to meditate, so the app can tailor push notifications and emails.

While I appreciate the continued focus on emotional state and problem-solving, the order of the questions sometimes feels random.

Post quiz steps (all flows)

The final steps are the same for all flows. There’s an additional review that, while identical for everyone, focuses more on sleep before prompting the user to sign up for an account.

This pattern isn’t uncommon in web funnels, especially quizzes: by this point, the user has already provided substantial input, and Calm subtly leverages loss aversion by encouraging them to save their preferences.

I find it interesting that Calm doesn’t provide any content feedback at the end of the quiz. While the quiz clearly aims to personalize the experience, that personalization only becomes visible after account sign-up. Users can access recommended content for free, but at this stage, they don’t yet know that.

This suggests the quiz is designed less for immediate conversion gratification and more for downstream personalization. Rather than rewarding the user right away, Calm seems to optimize for what happens later inside the app, through recommendations, notifications, and lifecycle messaging. This approach also makes sense given the sensitivities around mental health, but it does leave the ‘look what you could get!’ factor on the table.

By this point, the user has invested time, emotion, and data, making the trial feel like a natural next step rather than a hard sell.

The payment page is deliberately simple: a single 7-day trial tied to an annual subscription, without overwhelming the user with choices. If you don’t sign up right away, Calm often follows up with an additional discount to encourage conversion.

What can other apps learn from Calm’s web-to-app funnel?

Here are the lessons to learn from Calm:

1. Personalize where intent is highest
Calm doesn’t try to personalize everything. Sleep gets a dedicated flow; other goals don’t. That’s a good reminder that effective personalization is about focus, not coverage.

2. Emotional reassurance builds commitment
The quiz works because it validates the user before requesting any information, such as an account or trial sign-up. By the time pricing appears, the user already feels understood.

3. The real value of the quiz shows up later
Calm collects a lot of input without immediately providing feedback. This suggests the quiz is designed more for later personalization and retention than for immediate conversion payoff.

4. Simplicity still wins at the paywall
After a long quiz (though not unusually long compared to other apps), Calm deliberately removes choice: one plan, one trial — no extra decisions.

5. Brand trust can replace heavy social proof
Some elements — such as generic reviews and limited sourcing — would disadvantage smaller apps. Calm can rely on its brand within the funnel, but other apps would need more social proof to build trust.

6. Even strong funnels aren’t perfect
The order sometimes feels random, and some personalization is underused. But this is actually reassuring. You don’t need perfection for your first (or even your hundredth) web-to-app funnel to work well.

2. Blinkist Content Led Funnel

Web funnel type: landing page → app install

The value of Blinkist, the learning and personal development app, is rooted in content, so it makes sense that content sits at the very front of their acquisition funnel. Rather than leading with app features or promises, Blinkist leads with ideas: you learn something first, then discover the product that enables you to experience more of it.

Over time, Blinkist has built a strong content growth engine around short, insight-driven articles that summarize ideas. These articles are distributed both organically and through paid channels, helping build trust before asking users to download or subscribe. The same content formats are reused across paid ads, partnerships, and owned media, making this approach highly scalable.

Marcus Burke noted that, at one point, approximately 70% of Blinkist’s acquisitions came through web-to-app flows, proving just how central this content-led approach has been to their growth.

What does the typical Blinkist web-to-app journey look like?

A typical Blinkist journey starts with an ad promoting a piece of content, rather than the app. The ad leads to an in-depth article exploring a concept, principle, or idea. Within that content, Blinkist positions itself as the tool that helps you go deeper or learn more efficiently.

This is just one of many variations on the same pattern, but the overall structure remains consistent.

Here are several other articles Blinkist is currently driving paid traffic to:

Across their content, Blinkist relies heavily on social proof. Sometimes this appears as Apple features or App Store recognition. Other times, it comes from the authority of the author, thinker, or public figure behind the idea being explained. This approach transfers credibility from the content to the product, without feeling overly salesy.

The calls to action are usually either “Start your free trial” or “Create an account”. Trial CTAs often lead into a web onboarding quiz similar to Calm, while account CTAs keep users on the web, letting them continue exploring content.

Where does monetization happen?

Once users create an account, they can browse a range of book summaries. Clicking any summary triggers a paywall prompting a web subscription. On mobile, Blinkist also nudges users to download the app, creating a true hybrid of web discovery and app-based consumption.

What’s powerful about this approach is that Blinkist brings its aha! moment forward. Users experience “I learned something useful” before ever creating an account or starting a trial. While the sign-up rate may be lower than on a direct, conversion-focused landing page, this strategy allows Blinkist to reach a much broader audience and build trust upfront. That trust likely translates into stronger intent and higher-quality conversions once users do decide to sign up.

Trade-offs and risks to be aware of

There are trade-offs to this strategy. Organic traffic to Blinkist’s website appears to have dropped significantly over the past two years, likely influenced by shifts in search behavior and AI-driven content discovery.

Source: SemRush — Worldwide Organic Traffic for Blinkist.com

Meanwhile, what Semrush measures as paid traffic is more stable, but still smaller.

While this can be a powerful way to build trust online, especially with larger audiences, it’s important to be strategic about ensuring the content is seen and stays relevant.

What can other apps learn from Blinkist’s web-to-app funnel?

1. Bring the aha! moment forward
Blinkist shows that demonstrating value before asking for a sign-up can drive stronger intent later. Users convert because they’ve already learned something, not because they were sold on features.

2. Content can be the product preview
For content-driven apps, the web funnel doesn’t need to explain the app. It can demonstrate value directly and make the app the natural next step.

3. Web doesn’t need to convert immediately to be effective
Many Blinkist flows use web to educate, qualify, and build trust. Conversion happens later, either through account creation, a quiz flow, or an in-app paywall.

4. Social proof can come from ideas, not just reviews
Blinkist relies less on generic testimonials and more on the authority of thinkers and concepts. This is especially effective for educational apps.

5. Distribution matters as much as content quality
A content-led funnel only works if the content continues to reach new audiences. Changes in search behavior or platform dynamics can quickly impact performance, so it’s crucial to consider how people search today and ensure your content ranks effectively for AI-driven search.

3. PlantIn landing page funnel

Web funnel type: landing page → web purchase or app install

PlantIn, an AI plant care app, uses a fairly classic web-to-app setup, but what stands out is how intentional it feels without being overly fancy. It blends content, app promotion, and a web-based subscription flow in a way that gives users plenty of opportunities to buy in before being asked to actually buy.

See the full flow here

The journey usually starts with content. Ads lead to a dynamic in-between page that introduces the app and its purpose. From there, the experience changes depending on the device: on mobile, users are nudged to download the app (even if they try to click away), while on desktop, they’re directed to the website instead. It’s a small detail, but a smart one, and shows PlantIn doesn’t force an app-first experience where it doesn’t make sense.

PlantIn’s landing page

For some web-to-app landing pages, it isn’t always clear that they lead to an app. This can be tricky if you only offer web payments, since you don’t want users clicking through to the app store by mistake. For PlantIn, this isn’t an issue. They lead with a QR code for easy app download, include app store links, and show an in-app screenshot. The screenshot clearly highlights the value users can get from the app.

The next section, “What is PlantIn?”, appears to explain what the app does, but it’s actually a statistical trust builder. It highlights six key stats designed to build credibility and confidence in PlantIn.

Before moving on to the app’s key benefits, each stat should be explained clearly so users understand how it works. The section then wraps up with a brief social proof example and links to relevant articles — for example, the one on using coffee grounds for your plants (which I can personally recommend).

What’s great about PlantIn is that it doesn’t rush users into conversion. Instead, it focuses on sign-ups and deeper content. It offers a wealth of in-depth pages, like showing plant types, plant diseases, and even mushrooms you can identify. This doesn’t take away from the core value of the app — the ability to identify plants with confidence — or distract from conversion, it shows value and builds trust.

It’s the same classic flow of signing up to purchase. This matters for apps because – without it – if buyers purchase without an account, it creates an awkward post-purchase flow to try and get them set up on the app. It also allows you to encourage them to sign up for emails so you can guide them further.

What I really like about PlantIn’s pricing step is that it clearly shows users how much they save by subscribing online. The app delivers lower fees via the web and stronger retention to the end user.

Free trials are less common on web due to fraud risk, so it’s notable that PlantIn offers one. They keep it short, likely to prevent abuse, and because users can see the app’s value relatively quickly.

The checkout appears in a pop-up, making it clear what you’re paying for and what you’ll unlock. By this point, it feels less like a hard sell and more like the logical next step after everything you’ve already explored.

What stood out to me overall is how often PlantIn repeats its value proposition without it feeling aggressive. Each step adds a bit more context, rather than simply pushing the same message harder.

That said, I do find the wording slightly misleading. The title says “subscribing on the web,” but all the plans use the term ‘access’. Only the small text — which oddly omits the dollar sign on the first charge — clarifies that it’s a recurring subscription. This risks unhappy customers who didn’t realize they subscribed. I would use the word subscription or ‘per X period’ clearly in the prices, to ensure it’s clear which options are subscriptions and which are not.

What can other apps learn from PlantIn’s web-to-app funnel?

1. Meet users where they are
Routing mobile and desktop users differently avoids forcing an app download when it doesn’t make sense, rather than treating all users the same.

2. Show the breadth of your app, not just the main feature
PlantIn does a great job of making the subscription feel like access to an ecosystem, rather than just a single tool, while avoiding the trap of presenting itself as an ‘all-in-one’ solution.

3. Use content to reduce anxiety
Especially for users who feel like they’re ‘bad at plants’, the content reassures them before trying to sell.

4. Keep the app visible throughout the journey
Even when monetizing on the web, the app remains front and center.

5. Don’t be afraid to communicate web-specific offerings
The cheaper web subscription is presented as added value, not merely a way to avoid fees.

4. YNAB Workshop Funnel

Web funnel type: workshop → web purchase or web onboarding → email → app install

YNAB… You Need a Budget, don’t we all? This subscription app, which unsurprisingly is a budget app, has an extensive web experience. Given the complexity of entering all the data needed to set up and track a budget, YNAB lets users complete the entire process on the web, with the app introduced much later in the customer journey than you might expect. So late, in fact, that I started doubting they even had an app — but they do!

Workshops and webinars aren’t just effective for B2B apps; they can work really well for consumer apps too, especially when you want to build trust or stand out in a competitive market. I previously worked with a meditation and mindfulness app that offered weekly workshops. They ran multiple 3- and 7-day challenges you could join live, each centered around a theme like stress or gratitude.

These free workshops helped users connect with the coach, and afterwards, they were encouraged to purchase the app. This approach not only drove short-term boosts but also often led to longer-term growth, as users realized they wanted more content from the coach.

Workshops to help you learn

YNAB is built around its unique methodology and does a great job of supporting users and helping them learn.

Signing up for a workshop is simple via Zoom, and you receive a confirmation email. At this stage, there’s no mention of the app, and so the approach is refreshingly un-salesy. The focus is purely on delivering value to both existing and new users.

So what happens if you start the web flow? Get ready for a long web onboarding. This flow can be accessed via the website or after a webinar. Note that YNAB also runs ads to a 34-day free trial page, which is personalized to the user’s pain point and also leads into the same web onboarding.

The web onboarding process

I found it fascinating how many steps you go through without any mention of the app or sales. The focus is really on creating a sense of investment, with enough ‘sunk costs’ that you’re naturally engaged. I also didn’t expect the setup to be so easy and enjoyable, despite the multitude of steps.

Talking about money can feel a bit icky, and the questions can get personal. Still, I felt surprisingly comfortable sharing complete insight into my financial approach — bet you didn’t expect that in a web-to-app example article!

I did find the setup a bit unusual: the content sits at the bottom of the screen, with the rest left blank throughout the onboarding process (shown in the screen one, but not in the following ones). Given the length of the flow, it sometimes felt incomplete.

In essence, strong web quizzes often blur the line with onboarding, but for YNAB, there is no blurred line: this is pure onboarding. A few highlights are worth noting:

Customized reviews: I got a completely different review depending on what I said my goal was
Gradual build-up of the ‘thinking power’ required: the questions started easy and get progressively more in-depth
Personalization of relevant follow-up questions: e.g. if I indicated I owned a house, there were later questions about home insurance etc.
Initial questions were easy to answer on the spot: later, more in-depth questions arose that felt personal or needed calculation, e.g. how much you want or need to save per month, or your combined income
Breaking up the questions: it is a lot of questions, but the pauses between for reviews, explanation, and feedback lighten the flow

Even at the end of the quiz, there’s no mention of the app or YNAB’s costs. Since it’s a tool designed to help you save money, spending on it might feel odd until you’ve experienced the value, which is likely why they offer an extensive 34-day free trial. This period spans over a calendar month, allowing you to input data, start achieving your financial goals, and learn more about YNAB.

There’s also a part two questionnaire for account setup and connecting to your bank account, followed by a more explanatory, passive onboarding phase.

Two highlights stand out here. First, after completing part two of the setup, there’s a celebration moment. When the goal is long-term, celebrating progress like this is powerful; who doesn’t love a bit of colorful confetti? Budgeting has never felt so fun.

Second, the flow is reassuring. I’m quite far along before they make a big, high-trust ask: connecting my bank details. They gently reassure me that it’s secure, which builds confidence before the action.

Yet… still no mention of the app? Not even in the menu.

The first time I saw the app was in a follow-up email sent the same day I signed up:

This demonstrates that a strong flow doesn’t need to lead with your app. If your app is primarily a retention tool or requires significant setup and context, it can be more effective to provide an extensive, educational setup on the web first.

What can other apps learn from YNAB’s web-to-app funnel?

1. Web-to-app doesn’t have to lead with the app
YNAB delays the app reveal almost to an uncomfortable degree, and that’s intentional. The app itself isn’t the core value proposition; the methodology is. The web experience does the heavy lifting by teaching, building trust, and getting users mentally invested before the app even enters the picture.

2. Workshops work when education is the product
The workshops aren’t a gimmick or a lead magnet tacked on for growth. They’re a natural extension of YNAB’s philosophy. If your product requires a mindset shift or the adoption of new behaviors, workshops can achieve what landing pages never will.

3. Long onboarding can work if it feels earned
This is a long flow, but it doesn’t feel that way. Questions start easy, gradually get more personal, and are regularly punctuated with reassurance, reviews, and explanations. In this case, pacing matters far more than the number of steps.

4. Delay the ‘big ask’ until trust is established
Connecting bank accounts is a major trust moment. YNAB waits until you’ve invested time, seen progress, and felt understood before asking for it. By then, it feels reasonable rather than risky.

5. Celebrate progress, not outcomes
Budgeting is a long-term game. YNAB celebrates setup milestones, not financial wins. That confetti moment after part two isn’t about money saved, it’s about momentum towards a goal.

6. Free trials should match the job to be done
The 34-day free trial isn’t arbitrary. It gives users enough time to complete a full monthly budgeting cycle and experience the benefits before being asked to pay. The trial length supports behavior change, not just conversion.

5: Photoroom’s free tool funnel

Web funnel type: free tool → web onboarding → trial offer → app install

Photoroom, the photo editing app, is one of my favorite examples of how a B2B-focused app can use web-to-app without feeling pushy. Instead of gating everything behind an account or trial, they let you do real work upfront. You can remove a background for free, directly on the web, with zero friction, and that alone delivers value.

What’s interesting is that the web experience doesn’t feel like a stripped-down teaser; it feels like a useful product in its own right. Yet, at every step, it subtly nudges you toward deeper commitment.

The moment you upload an image and see the result, you’ve already had the aha! moment, and that’s when Photoroom starts layering in the next steps.

Reminder: you can zoom in on all the detail right here

Give value first, then ask for commitment

Photoroom offers a range of tools that can be accessed and used directly online:

One of the smartest decisions Photoroom makes is not forcing account creation too early. You can complete your first action without signing up, which reduces initial friction, especially for people solving a one-off problem.

But it doesn’t stop there. They use that first success to justify the next ask. If you want to continue editing, export in higher quality, or explore additional features, you’re encouraged to create an account. At that point, it feels reasonable. You’re not being asked to pay, or download anything. You’re not even signing up just to try it; you’re signing up to continue something you’ve already started.

This is a good reminder that web-to-app doesn’t always need a hard gate. Sometimes, letting people experience the core value first is the fastest path to building intent.

Self-employed vs. business: two very different journeys

Once you create an account, Photoroom quickly asks how you plan to use the product. This is where the funnel clearly becomes B2B-focused.

If you indicate that you’re using it for personal purposes, the flow stays relatively lightweight. Even then, it checks whether you have a brand to import:

But if you indicate you’re using Photoroom for a business, the experience changes. The onboarding goes much deeper: they ask about your company, your needs, and your expected volume. This doesn’t feel like unnecessary questioning; rather, it feels like qualification.

Photoroom is clearly trying to understand what kind of customer you are and what pricing and setup will make sense for you. From a growth perspective, this achieves two things at once:

Improves relevance by tailoring the experience
Sets expectations early for more advanced, higher-value plans

This is a strong example of using web onboarding not just to convert, but to properly segment users before the app experience even begins.

Team setup as part of the funnel

One of my favorite parts of the Photoroom flow is how early they introduce team setup. For business users, inviting teammates isn’t treated as an advanced feature you’ll discover later; it’s positioned as a natural next step.

The interface makes it easy to invite your team and set up a shared workspace. This does two important things:

Increases switching costs early
Turns one user into multiple users before monetization even happens

By the time pricing is introduced, you’re no longer thinking as an individual evaluating a tool; you’re thinking as a team adopting a workflow. That shift alone changes how pricing is perceived.

Repetition without feeling repetitive

Photoroom does something subtle but highly-effective throughout the pricing flow: no matter which free tool you start with, you continue to see the same core features and value propositions repeated.

At first glance, it might feel like they’re under-selling the breadth of the product. But I think this is intentional. Rather than overwhelming users with everything Photoroom can do, they focus on a small set of core capabilities and reinforce them consistently.

This repetition builds clarity. It’s a good reminder that focus often converts better than completeness.

Pricing clarity and trial positioning

When Photoroom finally introduces the free trial, it doesn’t come out of nowhere. By this point, you’ve already:

Used the product
Created an account
Seen how it fits into your workflow
Possibly invited your team

The trial feels like a natural extension rather than an aggressive push. They’ve asked several questions and set you up with an account, which helps reduce the risk of failed online charges.

I also appreciate how clearly Photoroom communicates pricing. You know exactly what you’re getting, what you’ll be charged, and when. There’s no sense of being tricked into a trial you might forget about. This transparency builds trust, which is especially important for business users.

What can other apps learn from Photoroom’s web-to-app funnel?

1. Let users do real work for free
Photoroom shows that giving away meaningful value upfront doesn’t cannibalize conversion. It creates it.

2. Use web onboarding to qualify, not just convert
Asking whether someone is a business user unlocks deeper segmentation and more relevant pricing later.

3. Design for teams early
Introducing team setup before monetization increases commitment and expands account value.

4. Subtle repetition builds clarity
Focusing on a few core features across multiple entry points helps users understand (and remember!) what the product is really for.

5. Trials work best when they feel earned
By the time the free trial appears, it feels like the obvious next step rather than a risky decision.

There’s no single ‘best’ web-to-app funnel

Looking across all five examples, the biggest takeaway is that web-to-app isn’t a one-size-fits-all template. Calm, Blinkist, PlantIn, YNAB, and Photoroom all approach it differently because their products, audiences, and jobs to be done vary:

Some lead with emotion
Some lead with education
Some lead with utility

What they all have in common is intention and user value. None of these funnels treats the web as a thin acquisition layer whose only job is to push users into the app as fast as possible. Instead, the web is used to:

Build trust
Create commitment
Reduce uncertainty
And, in some cases, even deliver the core value itself

If there’s one thing to take away, it’s this: your web funnel should do the hardest work before the app ever opens.

That might mean helping users understand themselves better, like Calm. Or it might mean teaching them something useful, like Blinkist or YNAB. Maybe it’s letting them experience real value immediately, like Photoroom or PlantIn.

The right approach depends on your subscription app, of course, but the opportunity is the same. Web-to-app works best when it’s not just a bridge, but a meaningful part of the product experience that drives high-quality users.

Building apps for an existing audience: why distribution is the new moat

Mon, 12 Jan 2026 11:46:34 GMT

Remember when shipping an app meant months of coding, debugging, and praying your launch didn’t coincide with an iOS update that broke everything? Those days aren’t quite gone, but they’re fading fast. Thanks to AI-assisted development tools like Cursor, Bolt, Replit, and a growing army of ‘vibecoding’ platforms, the barrier to building has dropped dramatically.

Andrej Karpathy coined the term ‘vibe coding’ in early 2025 to describe a workflow where you guide an AI tool to generate code through conversation, rather than writing it line by line. In its purest form, you can almost “forget that the code even exists”.

This is genuinely exciting: more people can build. More ideas can ship. The app stores are about to get a lot more crowded..

But here’s the thing nobody’s talking about enough: if everyone can build, then building isn’t the competitive advantage anymore. The new moats are having a great idea and getting it in front of people who want it. And there’s a shortcut to both that smart developers (and smart creators) are starting to figure out.

The influencer app playbook isn’t new, but it’s never been more relevant

Cast your mind back to 2014. Kim Kardashian partnered with Glu Mobile to launch Kim Kardashian: Hollywood, a freemium game where players climb the celebrity ladder through fashion choices, relationships, and strategic selfies. The gaming press was skeptical. The app world shrugged. Then it made $1.6 million in its first five days. By the end of 2014, it had generated over $43 million in revenue. At its peak, the game was pulling in $700,000 per day.

The game wasn’t revolutionary from a mechanics standpoint. It was a narrative dress-up game with energy timers and premium currency. What made it work was that Kim Kardashian had 25 million Instagram followers at launch (she’s now north of 360 million), and her audience was exactly the demographic that would love a game about becoming famous. The distribution was built in. The idea was validated by the audience that already existed.

That playbook has only gotten more sophisticated since then.

From Hollywood to your home screen

Chris Hemsworth launched Centr in 2019, a premium wellness app featuring workouts, meal plans, and mindfulness content from a hand-picked team of elite trainers. It wasn’t just “Thor tells you to do pushups”. It was (is) a genuinely comprehensive fitness platform with cinematic production values. But the reason it could command premium subscription pricing from day one was that Chris Hemsworth’s 60+ million Instagram followers already trusted him on fitness. The app didn’t need to convince anyone that the guy who got jacked for Marvel movies knew something about working out.

Arnold Schwarzenegger took a similar approach with the Pump Club app, packaging 50+ years of fitness expertise into daily workouts, nutrition guidance, and habit-building tools. Conor McGregor’s FAST app sells the same conditioning protocols he uses in fight camps.

The pattern is clear: take an existing audience that trusts you on a topic, then give them a product that serves that trust. But it’s not just A-list celebrities anymore.

The creator economy meets the app economy

The really interesting shift is happening with creators who aren’t household names, but have built dedicated audiences in specific niches.

Kayla Itsines built her following on Instagram with ‘Bikini Body Guide’ workout programs. When she launched the Sweat app, she had a direct line to millions of people who had already done her workouts via PDF. The app reportedly sold for around $400 million in 2021. That’s not celebrity money. That’s creator-to-app-founder money.

Likewise, Chloe Ting went viral on YouTube with free workout challenges that racked up hundreds of millions of views. Her app translates those viral programs into structured plans with calendars, timers, and progress tracking. Her 25+ million YouTube subscribers didn’t need to be convinced that her workouts were effective — they’d already sweated through them.

And then there’s Hank Green.

When your audience IS your product insight

Hank Green (of VlogBrothers, Crash Course, and SciShow fame) launched Focus Friend in 2025: a cozy, gamified focus timer designed to help people with ADHD actually get things done. It features a ‘Bean Friend’ character that focuses when you focus, turning productivity into something closer to a Tamagotchi than a stern Pomodoro timer.

The app hit #1 in the US App Store. Above ChatGPT. Above TikTok. Above Instagram.

What makes Focus Friend interesting isn’t just that Hank Green has millions of followers (he does). It’s that he’s been openly discussing his own ADHD for years. His audience includes a massive number of people who relate to that experience. When he built an app to solve a problem he personally has, he was also building for an audience that had self-selected around that exact problem.

This is the real insight: creators don’t just bring distribution. They bring validated demand. They’ve spent years learning what their audience struggles with; what they want — what they’ll pay for. That’s market research that most app developers would kill for, and creators have it for free.

The two-sided opportunity

So what does this mean for you?

If you’re a developer who can build, but struggles with ideas or distribution, consider this: somewhere out there is a creator with an engaged audience and a problem worth solving, but no technical skills to build the solution. That’s a partnership waiting to happen. You bring the building. They bring the audience and the insight. You both bring the upside.

If you’re a creator sitting on an audience that trusts you, consider this: the technical barrier to building an app has never been lower. You don’t need to learn to code (though you can vibecode easily enough if you want to). You need to identify the problem your audience would pay to solve, then find a builder who can make it real. Or use the new AI tools to prototype something yourself and see if it resonates.

The best apps in this model aren’t vanity projects or cash grabs. They’re genuine solutions to problems the creator understands deeply because they’ve been talking to (and often experiencing alongside) their audience for years.

What’s next

We’ve been thinking a lot about this intersection of creators, builders, and audiences at RevenueCat. The explosion of AI-assisted development tools means more apps will ship in 2026 than ever before. But the apps that break through — the ones that find real users and generate real revenue — will increasingly be the ones that start with distribution and work backward to the product.

In the meantime, if you’re a developer looking for your next project, maybe spend less time on Product Hunt and more time in the comments of your favorite creators. And if you’re a creator wondering whether an app makes sense for your audience, the answer is probably yes — you just need the right building partner.

The hard part isn’t building anymore. The hard part is finding something worth building, and people who want it. Turns out, some people have been solving that problem for years. They just didn’t know they were doing app market research the whole time.

Enter the Shipyard

Speaking of using creators to find proven audiences… we just might have something to help you in your next app adventure.

Shipyard: Creator Contest is an app-building challenge where real influencers enlist you to build, launch, and monetize an MVP app for their audience. In four weeks or less.

From January 15, 2026, you can get involved in our new hackathon, Shipyard. There’s a $140k prize pool, briefs from influencers with huge follower counts, and the opportunity to build something for a ready-and-waiting audience.

Learn more here

How to add subscriptions to a Bolt app

Fri, 09 Jan 2026 11:42:34 GMT

In this guide we’re going to look at how to add in-app purchases, meaning simple monthly and yearly subscriptions, into an app we have created with Bolt. We’ll also add a paywall to monetize part of the content in the app, and implement logic for checking whether the user is eligible to access content.

We are first going to create our project with Bolt, then you can start making your own changes to the apps. In this guide we’ll build an app that works on both iOS and Android, but you can of course choose to build for only one of those platforms if you prefer. Our example app is from this repository.

As the first step let’s open bolt.new and give the following prompt to get things started:

Why not just add subscriptions as part of the prompt?

This prompt should provide you a working app that has all the UI parts and code necessary for handling subscriptions. If you navigate around the application, you’ll notice that everything appears functional, and even the subscription logic is already in place. However, when you press the ‘subscribe’ button, nothing happens.

You might have noticed that the prompt includes the react-native-purchases package. This is RevenueCat’s React Native SDK, required for enabling in-app purchases. The reason subscriptions still don’t work at this stage is because Bolt uses an app called Expo Go to preview your app. Expo Go is a prebuilt preview app that comes bundled with a fixed set of native modules. These allow for rich interactions with native code — like building advanced UIs or accessing the camera — but they don’t include the native modules required for in-app purchases.

How RevenueCat’s SDK solves this

To address this limitation, react-native-purchases automatically detects when it’s running in Expo Go. When Expo Go is detected, the SDK enters Preview API Mode. In this mode, all native calls are replaced with mock APIs. While this means subscriptions won’t actually function in the preview, the integration won’t break either. Instead, you can safely navigate your app and verify that your subscription-related logic is wired up correctly, without interrupting your development flow.

At this point, you have a fully-functional app created with Bolt, including subscription logic and the RevenueCat SDK. All features should work as expected — except for actual subscription flows, which require native modules not available in Expo Go. You can continue using Bolt to build and enhance your app. Once you’re happy with the result, proceed to the next section to learn how to deploy your app using Expo Application Services (EAS), which will enable full subscription functionality.

Testing with Test Store

RevenueCat also has a built-in testing environment that works immediately without platform setup, called Test Store. Setting up Test Store does not need any additional configuration, the only requirement is using a Test Store API key. Test purchases made through Test Store behave like real purchases and subscriptions and allow you to build your app logic around subscriptions without having to configure App Store and Google Play subscriptions. Test Store also works on Expo Go.

We won’t cover Test store in this blog post, but it’s worth considering if you’re still testing out your app idea, and don’t want to spend time on setting up different stores before your app and subscription logic is fully built.

Now that our app has the basic UI for subscriptions in place, we can integrate the actual subscription logic using the react-native-purchases SDK from RevenueCat. Since the SDK includes native code, and our app uses Expo, we need to configure it to work with EAS Build, Expo’s custom build service.

To get started, download the project you have created with Bolt to your computer and open it in your IDE of your choice (e.g. VS Code, Cursor). You will also need the command line, so open that and navigate to your project folder to run the following command:

This will install the depencies of your app.

Prepare Expo for native modules

To enable native code in an Expo project, we need to switch from Expo Go to EAS Build. This is required for react-native-purchases and any other library that depends on native modules.

Follow the official Bolt Expo integration guide to configure your app. The key steps are:

1. Install eas-cli if you haven’t already:

2. Log in and configure the project:

3. Once configured, use eas build instead of expo start to build your project for iOS or Android:

This will create a production build of your application that you can then submit to the app stores. If you run into any errors or need additional support, check out Expo’s guide for creating production builds for Android and their guide for creating production iOS builds.

We now have a working production version of our app for Android and iOS that we can start adding subscriptions to. Before we do that we need to set up Google Play Console, App Store Connect, and RevenueCat, connect these three, then add products for our users to purchase.

Before we work on enabling subscriptions for our app, let’s set up RevenueCat and configure our products.

Start by creating a new RevenueCat account at revenuecat.com for free.

Connect RevenueCat to Google Play Store

Start by connecting your Google Play account to the RevenueCat dashboard, which will allow RevenueCat’s servers to communicate with Google Play Store on your behalf. To do this we need to provide RevenueCat with a set of service credentials. The process for configuring all of these is a bit complex, but this is all done to keep security high by only granting necessary access to RevenueCat.

To get access to the Google Play console, where all your distributed apps will live, you need to sign up for a Google Play developer account, which currently costs a one time fee of $25. Learn more about setting up a Play Console developer account from Google’s official documentation.

Once you’ve set up your Play Console account, follow RevenueCat’s guide to connect Google Play console and RevenueCat.

Configure Google Play with Products

With our RevenueCat account connected to the Google Play Store, we’re now ready to configure in-app subscriptions for our app. First, log into Google Play Console, select your application, and navigate to Monetize > Products > Subscriptions in the sidebar.

Click the Create subscription button and configure your pricing and billing periods (e.g., monthly and yearly). Be sure to take note of the Product ID for each subscription — you’ll need this when connecting your app to RevenueCat.

For more detailed information follow our Google Play product setup guide.

Connect RevenueCat to App Store Connect

To set up products for iOS, iPadOS, macOS, tvOS, and watchOS, start by logging into App Store Connect. App Store Connect is Apple’s central hub for managing app releases, TestFlight, in-app purchases, and more. To do this you need an Apple Developer account, which costs $99 a year.

Once you’ve set up your App Store Connect account, follow RevenueCat’s guide on connecting App Store Connect and RevenueCat.

Configure App Store Connect with Products

Navigate to your app and in the left navigation column under monetization select the Subscriptions section. Here you can define your subscriptions for your app. You need to app a new subscription group, then create a new subscription and include the subscription in the previously created group.

For more detailed information follow our iOS product setup guide.

Import Products into RevenueCat

Now that your subscription products are live in both app stores, head back to the RevenueCat dashboard.

Navigate to your project’s Products tab and click + New > Import Products. RevenueCat will automatically fetch your available subscriptions from Google Play and App Store Connect. Select the ones you want to import and click Import. Your subscriptions will now appear in your RevenueCat project, ready to use.

Create an Offering

Offerings in RevenueCat are how you define which products to show in your app. This makes it easy to test pricing, paywalls, and product combinations, all without needing to update your app.

Go to the Offerings tab and click + New to create your first offering. You’ll assign the products (like your monthly and yearly subscriptions) to this offering, which your app will reference when displaying a paywall.

Follow the steps in RevenueCat’s Offering documentation to complete setup.

You should now have RevenueCat, Google Play Console, and App Store connect configured with subscriptions. Before continuing with the guide, navigate to the API keys section of RevenueCat dashboard and copy the Android and iOS SDK keys. We will need these in the next step to connect our app to RevenueCat.

Create a paywall

RevenueCat has paywall builder that allows you to remotely configure your entire paywall without any code changes or app updates. You can use paywalls to display different offerings and your app can multiple different types of paywalls. You can also test how paywalls perform with RevenueCat Experiments.

We are going to add a simple paywall to show our possible subscription options. You can find the Paywalls RevenueCat dashboard in your project’s Monetization tools section. Pick from the pre-made paywall templates or make a fully custom one, and choose the offering you created in the previous sections. Once you are happy with the changes hit ‘publish’ to make the paywall available for your app. Learn more about RevenueCat Paywalls in our overview video.

The prompt from before should have installed both react-native-purchases and react-native-purchases-ui in both already. Verify this by checking that the package.json file has the lines below:

The versions should be 8.11.4 or higher. If either of these are missing or the version are lower than the mentioned, install the RevenueCat SDKs, by running:

Initialize the RevenueCat SDK

You can now initialize RevenueCat in your app. This is typically done once when your app starts. Creating our app with Bolt created a commented section where to place the following code parts in our app. Most likely it is in a file called _layout.tsx

Paste the API keys you copied in the previous section of this guide into the apiKey part. This enables your app to interact with RevenueCat’s servers.

To check if the user has an active subscription, query getCustomerInfo() and look for an active entitlement:

Use this in both the Feed and Profile tabs to reflect the user’s subscription status.

Implement the paywall logic

Now we can update the paywall screen to show available offerings and handle purchases:

This fetches the product offerings from RevenueCat and initiates a purchase flow. After a successful purchase, the entitlement is checked and the paywall is dismissed if the subscription is active.

Update the OverlayImage component

Finally, use the isLocked value in your OverlayImage component to lock or unlock content:

This ensures that only subscribed users can access the full list of cat pictures.

Wrapping up

With the RevenueCat and Google Play Console set up, the RevenueCat SDK integrated, and the necessary code changes made to the Bolt-created app, our app is now ready to accept and react to users subscribing. You’ll now want to create a new EAS build of your app; once the build finishes processing, test your app and the subscriptions. If you run into any problems, check that you have placed the code provided in the correct places.

These guides can also help you:

Using Bolt with Expo to create mobile apps, covers everything you need to deploy new versions of your app
RevenueCat’s updated guide to working with Expo, if you want to dive deeper into integrating your app with RevenueCat
The ultimate guide to Android subscription testing, RevenueCat’s guide to testing Android subscriptions.

Building animated custom Paywalls in Jetpack Compose

Fri, 09 Jan 2026 01:00:31 GMT

Paywalls are the critical touchpoint between your app and revenue. While pre-built templates can get you started quickly, there are compelling reasons to build custom paywalls that match your brand identity and create memorable user experiences. An animated paywall that responds to user context, like one that transitions between day and night themes, can create an emotional connection that static templates simply cannot achieve. The psychological impact of a well-crafted paywall extends beyond mere aesthetics; it signals to users that your app is polished, professional, and worth their investment.

In this article, you’ll explore how to build sophisticated animated paywalls in Jetpack Compose. We’ll dive deep into a “Day & Night” paywall implementation, examining each animation technique step by step. You’ll also learn how to use Firebase for agile A/B testing of your custom paywall content, and discover when RevenueCat’s Paywall Builder might be the better choice. By the end, you’ll have a complete understanding of when and how to build custom paywalls that convert.

Building custom paywalls: Day & Night deep dive

Let’s examine a production-quality animated paywall that transitions between day and night themes on a 16-second cycle. This implementation demonstrates several advanced Compose animation techniques working together harmoniously. The paywall creates an immersive environment that changes dynamically, with the sun rising and setting, stars twinkling into view, clouds drifting across the sky, and UI elements adapting their colors to match the time of day. This continuous cycle captures attention and creates emotional engagement that static paywalls cannot achieve.

Architecture overview

The Day & Night paywall follows a layered architecture that separates concerns cleanly. At the foundation sits the DayNightBackground composable, which handles all environmental animations including the sky gradient transitions, the procedurally generated star field with individual twinkling behaviors, the sun and moon following arc trajectories across the sky, a parallax cloud layer that drifts continuously, and a landscape gradient that grounds the scene.

Above this animated background, the content overlay presents the actual paywall information: a greeting that crossfades between “GOOD MORNING” and “GOOD EVENING” based on the cycle, a feature list with animated checkmarks whose colors shift with the day/night state, price display with an animated accent color, and a call-to-action button that transitions between warm golden tones during the day and cool indigo at night.

This layered architecture provides several benefits. The background animation logic remains isolated from the content presentation, making both easier to modify independently. The background can be reused in other contexts if needed, and the content layer can be updated without touching the complex animation code. This separation also improves performance by allowing Compose to optimize recomposition independently for each layer.

Setting up the animation cycle

The entire paywall is driven by a single cycleProgress value that loops from 0 to 1 over 16 seconds. This duration was chosen carefully, long enough to appreciate the transitions without feeling rushed, but short enough that users experience the full cycle during a typical paywall viewing session:

This pattern is important for complex animations: use a single progress value as the source of truth, then derive all other animations from it. This ensures perfect synchronization and makes the animation easy to reason about. When multiple animations need to coordinate, as they do in this paywall, having a single driver eliminates timing drift and makes the relationship between elements explicit.

The LinearEasing choice is deliberate. For a continuous cycle representing time passing, linear progression feels most natural. Non-linear easing would make certain parts of the day feel faster or slower than others, which would break the metaphor. The RepeatMode.Restart ensures the cycle loops seamlessly from midnight back to sunrise.

The cycle splits into two phases. The day phase spans from 0.0 to 0.5, during which the sun rises, crosses the sky, and sets. The night phase covers 0.5 to 1.0, when the moon performs the same journey. This symmetrical division creates a balanced experience where users spend equal time in day and night modes, maximizing exposure to both visual treatments.

Implementing the animated background

The DayNightBackground composable handles all environmental animations. This is where the magic happens, transforming a simple progress value into a living, breathing scene. Let’s break down each layer and understand how they work together.

Procedural star generation

Stars are generated once and remembered, with randomized properties for natural variation. The procedural approach means every session produces a unique star field, adding subtle variety to the experience:

Each star has its own twinkle phase and speed, ensuring they don’t twinkle in unison. This desynchronization is critical for realism, synchronized twinkling would look artificial and mechanical. The y coordinate is capped at 0.6 to keep stars in the upper portion of the sky where they belong, preventing stars from appearing in the landscape area at the bottom of the screen.

The 60-star count balances visual density with performance. Fewer stars would make the night sky feel sparse, while significantly more could impact rendering performance on lower-end devices. The size range of 1 to 3 pixels (from Random.nextFloat() * 2f + 1f) creates a sense of depth, with smaller stars appearing more distant.

The remember block ensures stars are generated only once per composition, maintaining consistency as the paywall cycles. Without this, stars would regenerate on every recomposition, creating a chaotic flickering effect.

Frame-accurate delta time

For smooth animations independent of frame rate, we track actual elapsed time. This technique is fundamental to professional-quality animation and ensures consistent behavior across devices with varying performance characteristics:

This approach has two benefits. First, animations remain smooth regardless of device performance, a device running at 30fps will show the same animation speed as one running at 120fps. Second, animation speed is consistent across devices, so users see the same experience whether they’re on budget hardware or flagship phones.

The coerceIn(0f, 0.1f) prevents animation jumps when the app returns from background. Without this cap, the delta time could be several seconds if the app was suspended, causing jarring jumps in continuous animations like cloud movement. By capping at 0.1 seconds (100ms), we ensure smooth recovery even after brief suspensions.

The withFrameNanos function is key here, it suspends until the next frame and provides the precise frame timestamp in nanoseconds. This is more accurate than alternatives like delay() which can accumulate timing errors over long running animations.

Multi-phase sky gradients

The sky transitions through eight distinct color phases, creating a believable progression from dawn through day through dusk through night and back. Each phase uses a three-color gradient to add depth to the sky:

The color choices are intentional and based on observation of real skies. Sunrise features warm oranges and golds, transitioning through the top of the gradient to paler tones. Day uses familiar sky blues with lighter tones toward the horizon. Sunset intensifies the warm colors with deeper oranges and reds. Dusk introduces muted blue-grays as light fades. Night reaches deep navy and near-black at the top, while dawn adds hints of warm tones as the cycle prepares to restart.

The phase calculation normalizes progress within each half-cycle, creating a local progress value that runs from 0 to 1 within either the day or night phase:

This normalization simplifies the transition logic, each phase can work with a consistent 0-to-1 range regardless of where it falls in the overall cycle. The day phase occurs when cycleProgress is below 0.5, while the night phase covers the upper half.

Then each phase transitions smoothly using lerp (linear interpolation), which blends between color values based on a progress parameter:

This creates natural-feeling transitions with quick sunrise/sunset phases occupying 20% of each half-cycle and stable midday/midnight periods holding steady for the remaining 60%. This pacing mimics real daylight patterns where transitions happen relatively quickly at the horizon while the bulk of day and night are stable. The 20/60/20 split also ensures that users spending even brief time on the paywall will likely see some transition, keeping the experience dynamic.

Star twinkling with fade transitions

Stars need to fade in and out at dawn and dusk, while also twinkling individually throughout the night. This dual-animation requirement demonstrates how to layer effects cleanly:

The fade timing uses 15% windows at the edges of each phase, creating smooth transitions. The multiplier of 6 (derived from 1/0.15) ensures the fade completes exactly within the window. During the day phase, stars are invisible (alpha 0) for 70% of the time, only appearing during the dawn and dusk transitions.

The twinkle effect uses a sine wave offset by each star’s unique phase. The sine function naturally oscillates between -1 and 1, so (sin(...) + 1f) / 2f normalizes this to 0-1. Multiplying by starAlpha creates the overall fade effect, while the inner calculation (0.4f + twinkle * 0.6f) ensures stars never fully disappear, they oscillate between 40% and 100% brightness, mimicking the atmospheric twinkling of real stars.

The performance optimization if (starAlpha > 0f) skips the star drawing loop entirely during the day, avoiding unnecessary computation when stars aren’t visible.

Sun and moon arc trajectories

The sun and moon follow identical arc paths across the sky, creating a believable celestial motion. The trigonometry here creates a natural horizon-to-horizon path:

The trigonometry creates a smooth arc through parametric calculation. At dayProgress = 0, the angle is PI (180 degrees), so the sun is at the left side of the screen since cos(PI) = -1. At dayProgress = 0.5, the angle is PI/2 (90 degrees), placing the sun at the center top since cos(PI/2) = 0 and sin(PI/2) = 1. At dayProgress = 1, the angle is 0, positioning the sun at the right side since cos(0) = 1.

The 0.5f multiplier on the Y component creates an elliptical arc rather than circular, giving a more natural horizon-to-horizon path that doesn’t extend too high into the sky. The height * 0.1f offset shifts the entire arc downward so the sun and moon rise from and set to below the visible area, creating a proper horizon effect.

The horizon check if (sunY < height * 0.7f) prevents drawing the celestial body when it’s below the landscape area. This simple culling ensures clean transitions at sunrise and sunset, with the sun and moon appearing to rise from and sink below the horizon naturally.

Sun rendering with animated rays

The sun is composed of multiple layers for a luminous, living effect. Each layer serves a specific purpose in creating the overall impression of radiant warmth:

The outer glow uses a radial gradient that fades to transparent, creating a soft halo effect around the sun. This atmospheric glow adds depth and prevents the sun from looking like a flat circle floating in space.

The main sun body uses an offset gradient center (shifted 8 pixels up and left) to create a subtle 3D effect. This offset makes one edge appear brighter, as if the sun has volume and the light is coming from a consistent direction. The color progression from pale yellow at the center through gold to orange at the edge mimics the color gradation seen in photographs of the sun.

The rays animate in two ways. First, totalTime * 20f in the angle calculation makes them rotate slowly, creating a spinning effect. Second, sin(totalTime * 3f + i) * 5f makes each ray’s length oscillate independently, with the phase offset + i ensuring different rays pulse at different times. This combination creates an organic, breathing quality that makes the sun feel alive.

Parallax cloud movement

Clouds create depth through independent movement speeds, a technique known as parallax that’s fundamental to creating perceived depth in 2D scenes:

The five clouds have varying scales and speeds. Larger, slower clouds appear more distant, while smaller, faster clouds seem closer. This variation creates a sense of atmospheric depth, even in the flat 2D canvas. The Y positions are constrained to the upper third of the screen (0.1 to 0.4 of height), keeping clouds in the sky area where they belong.

Each cloud is rendered as overlapping circles with wrapping horizontal movement:

The wrapping formula % 1.4f - 0.2f ensures clouds exit on the right and re-enter from the left seamlessly. The 1.4 range (140% of screen width) combined with the -0.2 offset means clouds are generated slightly off the left edge of the screen, drift across the entire visible area, and continue slightly past the right edge before wrapping. This creates smooth, continuous motion without visible popping at the edges.

The cloud color and alpha change between day and night. Daytime clouds are bright white at 90% opacity, clearly visible against the blue sky. Nighttime clouds become dark gray at only 15% opacity, creating subtle silhouettes that are visible but don’t dominate the starry sky.

Animating UI elements with the cycle

The UI layer animates in response to the day/night state using animateColorAsState, which provides smooth interpolation between colors whenever the target changes:

The 800ms duration creates smooth transitions that don’t feel rushed. This timing was chosen to match the overall pacing of the paywall, fast enough to feel responsive, but slow enough to be perceivable and pleasing. The color choices reinforce the day/night theme: warm golden tones during the day suggest sunshine and energy, while cool indigo and silver tones at night suggest calm and sophistication.

The label parameters are important for debugging and tooling. When using Android Studio’s Animation Preview or Compose debugging tools, these labels help identify which animation is which in the visualization.

Greeting crossfade animation

The greeting text switches between “GOOD MORNING” and “GOOD EVENING” using Crossfade, which automatically handles the enter and exit animations for content that changes:

The Crossfade composable handles the transition automatically, fading out the old content while simultaneously fading in the new content. This creates a smooth handoff without any jump or flicker. The 800ms duration matches the other UI animations, creating a cohesive feel.

The greeting text itself serves an important purpose beyond decoration, it creates a personal connection with the user. Time-appropriate greetings are a small touch that makes the app feel aware of and responsive to the user’s context. Combined with the animated environment, this creates the impression of a thoughtful, polished experience.

Custom checkmark drawing

Feature list items include animated checkmarks drawn with Canvas, demonstrating how to create custom graphics that respond to animation:

Drawing the checkmark with Canvas instead of an icon gives you precise control and eliminates asset dependencies. The checkmark path is defined using relative coordinates (percentages of the canvas size), making it scale correctly at any size. The StrokeCap.Round and StrokeJoin.Round create smooth, friendly-looking line endings and corners.

The background color comes from the parent composable and animates with the day/night cycle. This means the checkmark circles smoothly transition from warm golden during the day to cool indigo at night, maintaining visual harmony with the rest of the paywall.

Integrating RevenueCat for purchases

The paywall integrates RevenueCat through the rememberPaywallState helper, which encapsulates all purchase logic and provides a clean interface for the UI layer:

The PaywallState class encapsulates all purchase logic, keeping the UI composable focused on presentation:

This separation of concerns follows a clear architectural principle: UI components should be responsible only for presentation, while business logic belongs in separate classes. The PaywallState manages all RevenueCat interactions, loading states, and error handling, exposing only the interface the UI needs. This makes the code easier to test, maintain, and modify—changes to purchase logic don’t require touching the UI code, and vice versa.

Firebase for agile A/B testing

Custom paywalls give you creative control, but testing different messaging and offers requires a mechanism for remote configuration. Firebase Real-Time Database or Firestore provides this capability, enabling you to iterate on paywall content without app updates.

Why Firebase for paywall content

RevenueCat excels at managing subscription products, pricing, and analytics. However, when you’ve built a custom paywall, you need remote control over the content layer, the headlines, subheadlines, feature lists, price display formats, and call-to-action text that influence conversion. These elements often benefit from experimentation, and waiting for app store review cycles to test changes dramatically slows iteration.

Firebase lets you change these values without app updates, enabling rapid experimentation. You can launch a test in the morning, gather data throughout the day, and roll out the winner by evening, a pace impossible with traditional app updates. This agility is particularly valuable in the early stages of monetization when you’re still learning what resonates with your audience.

The combination of custom UI (for brand expression and advanced animation) with remote content (for rapid iteration) gives you the best of both worlds. Your paywall looks and feels unique, but you can still optimize messaging as quickly as teams using templated solutions.

Setting up Remote Config for paywall content

First, define your paywall configuration structure in Firestore. This structure should capture all the text elements you might want to vary:

The default values serve two purposes. First, they provide a fallback if the network request fails, ensuring the paywall always displays something reasonable. Second, they document the expected content, making it clear what each field is for.

The variant field is important for analytics. By including the variant identifier in the configuration itself, you ensure that analytics events always include the correct attribution. This eliminates a common source of A/B testing bugs where the variant assignment and the displayed content become desynchronized.

Fetching configuration at paywall display

The hash-based variant assignment ensures consistency, the same user always sees the same variant across sessions. This is critical for valid A/B testing; if users saw different variants on different visits, you couldn’t accurately measure the effect of any particular treatment.

The fallback to default values (via the ?: PaywallConfig() null coalesce) ensures the paywall always works, even if Firestore is unavailable. This defensive approach prevents network issues from blocking purchases entirely.

Integrating dynamic content into the paywall

Modify the paywall to accept configuration:

By parameterizing the paywall with a config object, you’ve created a flexible system that supports unlimited variations. The animations and visual design remain constant (and distinctive), while the content can be tuned remotely. This separation reflects the insight that users respond to both form and content, the form (design) builds brand perception, while the content (messaging) drives conversion.

Tracking conversion events

To analyze A/B test results, log conversion events with the variant identifier:

These three events create a conversion funnel that lets you analyze where users drop off. By filtering each event by variant, you can compare performance across treatments. The paywall_type parameter supports analysis across different paywall designs if you have multiple.

Analyzing results in Firebase

Create a funnel analysis in Firebase Analytics by examining the progression from paywall_viewed to purchase_started to purchase_completed, filtering each step by variant. Compare conversion rates across variants to determine winners.

When interpreting results, remember that statistical significance matters. Small differences in conversion rates may be noise rather than signal, especially with limited sample sizes. Firebase’s audience features can help you understand segment-specific effects, a variant that works well for new users might underperform for returning users, or vice versa.

Best practices for paywall A/B testing

Several principles help ensure your A/B tests yield actionable insights. First, test one variable at a time whenever possible. Changing the headline, feature list, and CTA simultaneously makes it impossible to know which change drove the result. If you must test multiple changes together, treat the entire bundle as a single variant and don’t draw conclusions about individual elements.

Second, use consistent user assignment so the same user always sees the same variant. This prevents the noise that would come from users experiencing different treatments on different visits. Third, run tests long enough to achieve statistical significance, which typically requires 1000 or more conversions per variant depending on the effect size you’re trying to detect.

Fourth, consider segment-specific testing. New users and returning users often respond differently to messaging, and testing within segments can reveal insights that aggregate analysis misses. Finally, document and archive your results. Over time, you’ll build organizational knowledge about what works for your audience, informing future experiments and reducing the need to retest ideas.

RevenueCat Paywall Builder: Beyond custom

While custom paywalls offer maximum flexibility, RevenueCat’s Paywall Builder provides compelling advantages for many scenarios. Understanding when each approach makes sense helps you allocate development resources effectively.

What Paywall Builder offers

RevenueCat’s Paywall Builder is a server-driven UI system that lets you design paywalls without code changes, using a visual editor in the RevenueCat dashboard. Once designed, paywalls can be updated remotely without app updates, you can change colors, fonts, layouts, images, and copy at any time. Built-in A/B testing lets you test different designs with statistical rigor, automatically allocating traffic and tracking results.

Localization support manages translations in one place, with automatic serving based on user locale. Analytics integration provides automatic conversion tracking without additional instrumentation. And a template library gives you proven starting points that you can customize.

Server-driven UI advantages

The key advantage of Paywall Builder is server-driven UI. Your app renders whatever configuration the server provides, decoupling the paywall appearance from the app release cycle:

This single composable renders any paywall design you configure in the RevenueCat dashboard. No app update required to change colors, fonts, or layouts, swap images or icons, modify copy or pricing display, launch A/B tests, or roll out winning variants.

The operational implications are significant. Your product team can iterate on paywalls independently of engineering, accelerating the experimentation cycle. Bugs in paywall content can be fixed immediately rather than waiting for app store review. Seasonal promotions can be created and removed on exact schedules without app update coordination.

When to choose Paywall Builder

Paywall Builder is often the better choice when iteration speed matters most. If you’re optimizing for conversion and need to test many variations quickly, the visual editor and built-in A/B testing dramatically accelerate the feedback loop. The product team can create and launch tests without engineering involvement, freeing developers for other work.

Engineering resource constraints also favor Paywall Builder. Custom paywalls require development time for initial implementation and ongoing maintenance. Paywall Builder shifts this work to product and design teams, who can work in the visual editor without writing code.

If you don’t need advanced animations, Paywall Builder supports basic animations and transitions. If your paywall concept doesn’t require complex custom effects, the templates may be sufficient. Many successful apps use straightforward paywalls that focus on clear messaging rather than elaborate motion design.

Cross-platform consistency is another consideration. Paywall Builder renders consistently across iOS, Android, and web. Custom implementations require separate development for each platform, multiplying the engineering investment.

When custom paywalls still win

Custom paywalls remain the right choice when brand expression is paramount. If your paywall must match a distinctive visual identity with custom animations, templates can’t replicate that. The Day & Night paywall we examined could never be created in a templated system, the procedural star generation, trigonometric sun/moon paths, and synchronized multi-layer animation require custom code.

You need unique interactions that templates don’t support. Gamified paywalls, AR previews, gesture-based navigation, or mini-demos of premium features require custom implementation. These interactive elements can significantly impact conversion by letting users experience value before committing.

Sometimes the paywall is a product differentiator. If the paywall experience itself is a selling point, like a meditation app’s calming paywall that sets the tone for the premium experience, custom development is worthwhile. First impressions matter, and a distinctive paywall can signal the quality users should expect from the premium tier.

Hybrid approach

Many successful apps use both approaches strategically. A custom implementation for the primary conversion flow provides the brand expression and distinctive experience that first-time subscribers see. Paywall Builder handles promotional paywalls for seasonal offers, win-back campaigns, or experiment variations where rapid iteration matters more than custom design. Secondary surfaces like settings screen upsells or feature-gated prompts also use Paywall Builder, since these are seen less frequently and benefit more from easy configurability than custom treatment.

This hybrid approach maximizes both brand expression and iteration speed. The primary paywall creates the distinctive first impression, while Paywall Builder provides flexibility for ongoing optimization and promotional needs.

Conclusion

Building animated custom paywalls in Jetpack Compose opens creative possibilities that templated solutions cannot match. The Day & Night paywall demonstrates how layered animations, sky gradients, twinkling stars, celestial body trajectories, parallax clouds, and synchronized UI elements, can create an immersive experience that engages users emotionally. These techniques transform the conversion moment from a transaction into an experience, potentially improving both conversion rates and brand perception.

Firebase provides the remote configuration layer needed for agile A/B testing of paywall content. By externalizing headlines, features, pricing display, and CTA text, you can iterate on messaging without app updates while maintaining your custom animated experience. This combination, custom design with remote content, gives you both brand distinctiveness and operational agility.

However, custom paywalls aren’t always the right choice. RevenueCat’s Paywall Builder offers server-driven UI, built-in A/B testing, and rapid iteration capabilities that often outweigh the benefits of custom development. Consider your team’s resources, iteration needs, and brand requirements when choosing between custom and templated approaches. Many successful apps use both, custom for the primary experience, templates for promotional and secondary surfaces.

For complete documentation on RevenueCat’s SDK integration, refer to the official RevenueCat documentation. For full source-code covered in this blog post, check out the GitHub repository.

How Jeff Morris drives growth and monetization in mobile

Wed, 07 Jan 2026 14:06:35 GMT

Jeff Morris, former VP of Product at Tinder and now a partner at Chapter One, brings years of experience in mobile growth and monetization strategies. In this episode, he shares actionable insights on building a scalable product, optimizing revenue streams, and staying agile in the fast-evolving app ecosystem.

Product-market fit comes first

Before jumping into monetization, Jeff emphasizes the importance of ensuring product-market fit. Building a product that genuinely solves user problems and resonates with your audience is the key to long-term success. Monetization should follow naturally once you’ve built a loyal user base that values your product.

Test and adapt monetization strategies

The pressure to monetize early is rising, but Jeff advises against rushing into rigid strategies. Founders should test different models—such as subscriptions, paywalls, or in-app purchases—and adapt based on user responses. Flexibility and adaptation are critical in today’s competitive market, as the same monetization strategy doesn’t work for every app.

Experimentation is essential

Testing is not just necessary; it’s essential to growth. Jeff encourages founders to continually experiment with various aspects of their app, from creative assets to pricing strategies. Analyzing data and adjusting based on real-time results leads to smarter decisions that ultimately fuel growth and optimize revenue.

Quality over quantity in creative testing

When it comes to creative testing, Jeff advocates for fewer, more meaningful experiments over testing hundreds of creatives without understanding why they work. Focus on strong hypotheses and ensure every test is geared towards discovering what truly resonates with your audience. Effective creative testing should be iterative and data-backed, not just about numbers.

Innovate, don’t copy competitors

While learning from competitors is essential, Jeff warns against copying their playbooks without tailoring strategies to your app’s unique needs. Use competitor insights as inspiration, but adapt them based on your own data and user behavior to find what truly drives success for your app.

Accurate data is key

Data is at the core of Jeff’s approach to growth. He stresses the importance of accurate data instrumentation to make informed decisions. Whether it’s understanding user behavior, monitoring in-app analytics, or analyzing creative performance, having reliable data allows you to optimize your efforts and avoid costly mistakes.

Embrace unconventional approaches

Jeff encourages founders to think outside the box and not shy away from unconventional strategies. Small changes, such as how you map events or introduce new features, can significantly impact performance. Sometimes, doing the opposite of what’s considered conventional can open doors to new opportunities.

Conclusion

Jeff’s experience shows that mobile growth and monetization aren’t about blindly following best practices—they’re about continuous testing, learning from data, and persistence in the face of challenges. By focusing on building a great product, testing frequently, and listening to user feedback, founders can find what works for their specific app and achieve sustainable, long-term growth.

How Peloton lost me after a price hike and what they could have done differently

Mon, 05 Jan 2026 13:40:24 GMT

Even before the big debacle in the pilot episode of Sex and the City’s spin-off And Just Like That, Peloton was all the hype, and I ran quickly away from it. I’ve never been great at following the crowd, and its cult-like following? Intimidating.

Fast forward a few years: the craze had cooled, I had a slightly bigger space, and I got an irresistible offer. A friend was willing to give me his bike — barely used — for a third of the original price… if I could pick it up and haul it across London on a freezing February morning. Challenge accepted.

Here’s my story: from falling in love with Peloton, to struggling with the monotony, surviving a price hike, and eventually canceling my subscription. Think of this as interval training: after the high-intensity bits of my painful memories, you’ll get a lighter, easy-breathe moment with the takeaways you can actually apply to your subscription app.

Interval 1: jumping into my personalized plan

My first hiccup came during account setup. Reading the fine print has never been my strong suit, and sure enough, I couldn’t use the bike to its full potential without the All-Access subscription at £39 a month.

Whoops. But I was determined to give it a go. Plus, the subscription meant my partner could also use the bike, which seemed to excite him. Escaping the rain outside, I doubled down on bike rides.

The real highlight? Peloton’s personalized plan feature:

Peloton email around personalising your plan

I’ve long struggled to fit into the box of a set plan that most apps offer. They usually focus on one type of exercise, while I thrive on variety. I’m the kind of person who never makes a recipe more than twice — yes, seriously.

With Peloton, I quickly customized a routine that mixed biking, running, and strength training, and I was off.

Here’s what their onboarding flow looks like:

Peloton quiz

The onboarding is easy to navigate and never makes you feel stupid:

If you’re unfamiliar with a workout type, like HIIT Cardio, they explain it clearly
Visuals show exactly how to use the equipment
Goals are asked about in simple, straightforward language

Clear explanations of exercises

I loved the variety of instructors and music, which perfectly complemented the high-energy workouts. My weekly streak grew quickly — just one workout a week was enough to keep it going — so no matter where I was in the world, I always did at least one session.

Takeaway 1: help users get the most out of your app, fast

Finding content with Peloton was effortless. A few simple questions helped the app understand me and offer workouts I actually enjoyed. ‘Fast’ doesn’t necessarily mean a short onboarding, but even if your onboarding is longer, it should give users a clear sense of value right away.

Peloton excels at this. They don’t just create a personalized routine; they also help you find your favorite instructor with a separate, quick quiz. It’s like Tinder meets Strava, and it made me realize that matchmaking is exactly what had been missing from my workouts.

Instructor quiz on the Peloton website

Interval 2: the downward hill of using Peloton

You can’t stay in the honeymoon period forever, and ours ended over the summer. That’s when I noticed I was doing fewer and fewer workouts on Peloton. At first, I had a million excuses for the distance between me and Peloton; after all, I’d invested in the bike:

I’d been injured, so I couldn’t run
It was summer, and I was biking and swimming outside
My sister was staying with me, and wanted guided strength workouts
I’d been traveling

But I persisted, trying to get back into it. I even reset my personalized plan to mix things up, but it felt like I was getting the same workouts on repeat.

The plan offered a fixed week of classes, but there was no sense of progression or adjustment over time — just new versions of the same routines. It started to feel less like personalization and more like a static template that simply shuffled itself; making it harder to stay motivated when I was craving change.

Personalization without visible evolution can feel stagnant. When users can’t see their progress, even the best content library starts to feel repetitive.

I was already picking the most advanced workouts and experimenting with different instructors. I wasn’t a top performer (my power output on the bike could improve) but I didn’t know how to progress:

More workouts?
Different workouts?
If it was personalized, where was the guidance?

What was I even working toward? Slowly, the cracks started to show.

Takeaway 2: help users understand how recommendations are personalized to them

Peloton’s personalized plan quiz was great for generating recommendations, but it missed a critical step: explaining why those recommendations were made.

Users need to understand not just what to do, but why it’s tailored to them and what goal it serves. Explaining the reasoning behind recommendations maintains trust and motivation. Sometimes products make the assumption users come to them because they don’t want to think, but that isn’t always true — we want the hard part done, but that doesn’t mean we don’t care about the ‘why’.

If you’ve asked 10–20 questions during onboarding, don’t just hide behind a fake ‘thinking’ loader. Show users that their answers were heard. At a basic level, feed back their responses; at a more advanced level, demonstrate that you understand and confirm it with them. AI apps make this easier than ever.

For example, Noom’s weightloss app has a lengthy onboarding process, but it breaks it up with little screens that reflect what it’s learned from your answers, making the personalization feel real:

Noom’s personalization in the onboarding flow

It takes your answers to give you feedback on your profile and where you should focus, making you feel that Noom is truly personalized just from going through the onboarding process.

Takeaway 3: understand what drives short vs. long-term retention

When you look at your monthly versus annual subscribers, you’ll often find that those canceling after a few months churn for very different reasons than those who leave after a year or two. Short-term and long-term retention are not the same game.

There’s the initial activation phase, getting users to start using your app, which is easier for Peloton since many users have already made a big investment in the bike. That’s followed by the habit-building phase. But long-term retention requires something else entirely. Your user evolves, and your app has to evolve with them.

This isn’t the first time I’ve outgrown an app. With ADHD, I quickly tire of repetition. I’ve had the same experience with mindfulness and recipe apps. Once you’ve mastered the basics and explored what an app has to offer, you start craving the next level.

To sustain engagement, an app needs to grow and adapt alongside its users as their jobs-to-be-done evolve. Peloton did allow you to retake your quiz to refresh recommendations, but it missed an opportunity to introduce clear levels, milestones, or a sense of progress, something to make users feel like they’re moving forward.

Interval 3: getting the email all users dread… a price increase

At this point, my two core personality traits were at war:

The stubborn part of me that refused to give up on something I’d bought only nine months ago
The restless part of me that craves newness

That’s when it landed in my inbox: the email every subscriber dreads. Subject line: “Changes coming to your Peloton Membership”. I knew exactly what the changes would be.

Long before I’d finally joined the Peloton hype train, I’d actually used one of their previous price increase emails as an example of great communication. It was clean, clear, and transparent, mapping out exactly what was changing and why. They had this great table showing just how much had changed between 2014 and 2022, from the number of workouts to the addition of programs.

Peloton comparing the 2014 offering vs. the 2022 offering

Of course, it’s always easier to admire a price hike email when you’re not the one paying for it.

I still stand by it as a great email. I’m not a hater, and I can appreciate a good pricing update. So I opened this new one with an open mind, hoping for the same clarity. But instead of understanding, I was left confused. Here’s Peloton’s new price update email:

Email announcing price increase

I appreciated the clarity around when and how the change would happen. You’d be shocked at how often this is missed! As well as that, they gave me at least a month’s warning so that it wouldn’t come as a surprise.

However, this time there was no clear table overview, just a list of changes — many of which I wasn’t personally interested in:

Number of classes: “12,000 classes” does sound impressive, though at a certain point it borders on unnecessary — that’s 32 years’ worth of daily classes
Club Peloton: feels like something they use for engagement versus something I should pay more for
Injury prevention: whilst that in itself is interesting, the way it was phrased around Special Surgery meant I wasn’t sure if it was relevant for me
Personalized Training with Peloton IQ: felt a bit vague — I wasn’t sure what this was, I think it was a few stats I’d received whilst using the app which were helpful, but didn’t really change my training

But there was one line in the email really threw me off:

“Breathwrk, now a part of Peloton — science-backed breathing exercises to help you reduce stress, recover faster, and stay focused.”

What is Breathwrk?! I hadn’t seen any breathing content in the app, nor was it something I’d been looking for; I already used Calm for that. It feltThis would be like a hotel upgrading your room to include a karaoke machine — very cool, probably fun for someone, but completely irrelevant to why I booked the room — something you never asked for, and then charging you for it!

Takeaway 4: Communicate major new offerings in-app before the price increase

Ironically, I only understood what Breathwrk was after I canceled. It turned out to be a separate app Peloton had partnered with, but I never saw it mentioned anywhere inside the product.

Source: Breathwrk

I might have actually used it, or at least recognized it as added value, if it had been communicated before the price increase. A quick check of my inbox confirmed: they’d never emailed me about it either.

While it’s fine to highlight new features in a price increase email, this felt like over-explaining. Like attempted justification. A better approach is to show the value first, let users experience it, then communicate the price change. If you can’t ensure users have seen the updates, add more communication to build excitement before raising costs.

This sounds like an excellent partnership for them, but a pricing email might not be the time to name-drop it without any context.

Interval 4: searching for another membership option

Now, I’d be remiss not to acknowledge Peloton’s hybrid monetization model. They combine an in-app subscription with a physical product, which is a powerful move. But, while it’s bold, it also leaves very little room for choice.

I’d already realized I needed the top-tier subscription to unlock the bike’s full potential. Then, after a 15% price increase, I started hunting for alternatives that would let me keep using my bike: could I downgrade to a lower-tier subscription?

The answer was a solid no.

Peloton subscription options

To give credit where it’s due, Peloton’s app subscriptions do offer a sense of choice:

Monthly vs. annual subscriptions
A ‘basics’ tier, or access to all workout types

These options give users flexibility, at least on paper, but when it comes to actually using the bike I already own, that flexibility disappears. Once you’ve committed to the top tier, there’s little room to adjust without losing access to features you’ve grown attached to.

App One vs. App+ plan

I liked that Peloton offers options here, but I quickly realized that with my All Access subscription, the only choice was at £45/month. It almost felt like I was being punished for having the bike: some classes I could use on other equipment, but for the Peloton bike itself, access came at a premium.

Takeaway 5: reward customers who invest in your brand

Rather than penalize someone for buying pricey equipment, reward them with better pricing to keep them loyal. Imagine if it were more expensive to use Peloton on other bikes?

Suddenly, buying the bike, treadmill, or other equipment becomes an investment that pays off for sticking around. I’ve always hated how endless discounts are offered to new customers while existing users aren’t acknowledged for their loyalty.

A simple way Peloton could have done this is by ensuring that it is cheaper to use the app with their equipment vs. other brands, or delaying the price increase for existing subscribers.

Takeaway 6: give customers a sense of choice

Have you ever told a kid to eat broccoli? Chances are, it didn’t go well, for you or for the broccoli. But I learned a valuable lesson from my cousins when dealing with little ones under five: make it seem like an option. “Do you want to eat the broccoli or the carrots?” Suddenly, vegetables are being consumed either way, and we can all breathe a sigh of relief.

The takeaway? We all like to feel like we have a choice (even if it’s between two pre-selected options).

Peloton does this well with their standard app subscriptions, but I missed it when it came to owning Peloton equipment: one subscription, one duration. There was no way to scale back usage (e.g. subscribe for 4x a month) or pay upfront for a year to save.

From a psychological perspective, this matters. Research on self-determination theory shows that autonomy is a key driver of user satisfaction. When customers feel trapped by pricing or product limitations, perceived value drops fast, even if the product hasn’t changed. Monthly subscriptions may allow companies to charge more, but they also make it easier for users to say stop.

Interval 5: so I canceled my subscription

I apologized to my bike and went to cancel, thinking a monthly plan would make it easy to restart if I missed it.

That’s when things got a bit messy. I logged in on my phone… no subscription showing. Checked the website… still nothing. Confused, I contacted customer service.

First impressions: they were super helpful. No fuss, no issues. My subscription was stopped just days before the renewal. I really want to celebrate Peloton for this, as I’ve known some brands that make canceling near-impossible. I won’t name names…this time.

Chat conversation to cancel subscription

But then I waited for the questions… Why did I want to cancel my subscription? Did they want my feedback?

They didn’t come. Maybe they’d include a survey in the confirmation email later.

The confirmation email arrived… and still, no survey.

It felt like dumping someone with a heartfelt speech, only to get a shrug. Like, don’t you want to know why I’m ending it? Don’t you feel desperate to find out if there’s someone else? (For the record: I never cheated on Peloton.)

Confirmation of subscription cancelled

Overall, Peloton did a lot of things well:

Super clear confirmation that your account is cancelled — no fluff or noise
No guilt-tripping; it showed understanding
Clear timeline so you know when changes take effect
Easy instructions for how to restart or change your subscription

The missed opportunity? After a conversation and an email, I was never once asked to explain why. This is valuable feedback for a brand.

Takeaway 7: make cancelling an enjoyable experience

Hiding cancellations or creating a complicated process never pays off. I don’t know why my membership didn’t show up on my account at first — probably a glitch across devices — but once I contacted support, everything was handled politely, and I was able to cancel in two minutes.

Even if some people cancel directly through the app store, for web or in-app subscriptions, a clear, simple cancellation flow is key.

Takeaway 8: ensure you have a ‘clean’ cancellation email

A good cancellation email covers:

Confirmation that the subscription has been cancelled
When the account stops
A thank-you for being a subscriber
A chance to provide feedback if they haven’t already

Keep it short, concise, and skip the “DON’T ABANDON US” panic. Guilt tripping isn’t professional, and doesn’t work.

So about that feedback…

Interval 6: I got a feedback request!

I did eventually get a survey, but I’m not 100% convinced it was because I cancelled. It was a Net Promoter Score (NPS) survey.

NPS survey email

Interesting timing, right after cancelling? I rolled with it anyway.

Answering the questions, it became clear the timing probably wasn’t intentional, as the survey didn’t seem to even know my subscription had been canceled:

Questions in the feedback survey

I couldn’t select “I don’t have a membership” for the statement, “I’m happy with my Peloton membership”.

For Peloton, I wasn’t a raging ex blocked on all social media; I was the ex you’re still friends with, where potential still exists. But even then, you don’t ask your ex:

Am I evolving to meet your needs?
Do I value you as a friend/partner?

It felt… weird. If I had been the raging ex:

Let’s be honest, I probably wouldn’t have given feedback
This would have annoyed me even more

Still, I played the game, social niceties and all, trying to answer as best I could, even though I couldn’t indicate “I’ve cancelled!”

What Peloton did get right, though, was checking whether I’d seen their announcements.

Asking about which features I’d seen

A bit of a random mention, but too often apps assume their users just know what they’re doing. The other day, I discovered a core feature in an app I’d been using daily for three weeks, oops.

Takeaway 9: have a specific feedback form post cancellation

Keep it short, and ideally link it to the moment of cancellation to gather insights on why users are leaving. Here’s more on the best practices of a strong cancellation survey.

To give Peloton some grace (told you I’m a nice ex), they did send a survey one day after I cancelled and noted that the system takes 72 hours to update. Maybe I just got unlucky with an NPS survey during that window. That said… I still haven’t received my actual cancellation survey.

The cooldown: life after Peloton

What surprised me most was how emotional the experience felt. I’d built rituals around Peloton: the instructors, the playlists, the feeling of showing up for myself. That emotional connection kept me subscribed longer than any discount ever could. But once that connection faded, the price increase simply accelerated my exit.

For other apps, this is a powerful reminder: retention isn’t just about utility, it’s about identity and belonging. Once users stop feeling seen or progressing, they stop showing up.

It had nothing to do with working out; I’m still a fitness addict, training six days a week. Since cancelling, I’ve been testing a new app that I love: it challenges me, tracks my weights and reps, and shows me tangible progress.

But it doesn’t include biking workouts. And my Peloton bike, still sitting in my workout space, quietly calls me as the nights get darker and the days rainier.

I gave it a go without a subscription. Two short free classes brought back a wave of nostalgia. It was like running into my ex at the coffee shop we used to visit together.

The free tester class

Peloton’s story isn’t unique to fitness apps. Every subscription app faces the same challenge: evolving alongside its users. Whether you’re building a meditation, language-learning, or gaming app, these lessons are universal:

Help users get value fast
Explain how personalization works
Evolve with users as their goals change
Communicate new value before raising prices
Reward loyal customers, don’t penalize them
Offer flexible, fair pricing options
Make cancellation simple and respectful
Send clear, thoughtful confirmation emails
Collect timely, relevant feedback

When users feel both understood and in control, retention follows naturally.

For now, it wasn’t enough to bring me back, but I’m not ready to sell the bike either. Maybe, in time, we’ll find a way to make this expensive relationship work again…

Reduce support time with auto-attached app diagnostics

Wed, 31 Dec 2025 13:35:44 GMT

Most support emails start the same way:

“The app does not work!”

No device info. No OS version. No context. Your team wastes time asking follow-up questions and your customer waits for help.

You can fix that in one afternoon. Add a small diagnostics block to support emails your app sends. It gives your team everything they need to solve problems fast and your customers get better support without back-and-forth.

Give your team context before the first reply

Without context, support tickets turn into guesswork. Agents can’t see the customer’s setup or state. Maybe notifications are disabled, or large text pushed buttons off-screen.

Adding metadata changes that. When every support email includes the customer’s environment, accessibility settings, and subscription state, agents can spot the issue immediately instead of asking for details.

Add a diagnostics block that explains the problem before the customer does

Include a compact summary of the customer’s setup in each support email. Include the granted or denied permissions, important configuration options that might affect the user experience in the app. It might look something like this:

App: 3.5.2 (302) • iOS 17.2 • iPhone 14
Notifications: allowed (alert/badge/sound)
Text size: XL (Accessibility Large)
Locale/TZ: en-US / PST
Network: reachable (Wi-Fi)
RC User ID: abcd1234 • entitlement=active
Last screen: Paywall • Last sync: 2025-10-14T09:32Z

This one block replaces several messages of troubleshooting. Keep it short and human-readable. Five to seven lines is plenty.

Include details that help the agent act fast: app version, OS, permissions, accessibility settings, locale, timezone, and key RevenueCat context like user ID and entitlement status. Avoid personal data or tokens, and mention in your help center that diagnostics are attached to support emails.

Build it yourself in a few lines of code

You can add this now. On iOS or Android, pull data like notification settings, device info, locale, and entitlement status.

Track how much faster support gets

Once diagnostics are attached, measure the impact. Look at first-response time, time-to-resolution, and how often your support agents have to ask follow-up questions. You’ll see faster responses and fewer repetitive tickets.

Be transparent with customers

Tell customers what’s included in the diagnostics and why. Keep it visible in your privacy notice or support screen. And if you want to go the extra mile, add a toggle so they can choose not to include it.

Handle email support with Customer Center

If you don’t want to maintain your own diagnostic block, Customer Center does it for you.

A new Support tab in Customer Center brings all your support email settings into one place. You can decide who sees the “Contact Support” action, set the address those messages go to, and connect tools like Intercom or Zendesk without touching code.

The tab also adds a powerful improvement for debugging. You can turn on Support Metadata and Customer Center will attach a compact diagnostics block to every support email your customers send. It gives your team the context they need to resolve issues faster; app version, device details, permissions, subscription state, and other relevant signals.

Everything runs server side. When a customer taps “Contact Support,” the email routes through RevenueCat, matches the message with backend data, and inserts the selected metadata into the footer before delivering it to your support inbox. You get accurate, up-to-date context without asking customers for screenshots or extra details, and your team cuts troubleshooting time dramatically.

If you already rely on Zendesk or Intercom, the setup is automatic once you connect the integration. If you use a different tool, you can still forward emails normally and keep the metadata block intact. This update turns support emails into a reliable source of truth and makes Customer Center a complete home for managing support flows.

Add metadata to your support emails now.

Craft, Seasonality, and the Long Game

Wed, 31 Dec 2025 13:29:17 GMT

Jordan Morgan’s journey as an indie app developer is shaped by patience, experimentation, and a deep respect for craft. With years of experience building, selling, and even reacquiring apps, Jordan has navigated multiple phases of the indie landscape—from passion projects to sustainable businesses. Best known for apps like Elite Hoops and Alyx, Jordan’s work reflects a thoughtful balance between creativity and pragmatism.

In this episode of Launched, Jordan joins Charlie Chapman for an annual, reflective conversation on what it truly means to build apps that endure. Together, they explore seasonality, growth plateaus, paid acquisition, and the often-overlooked emotional side of long-term product building.

From Passion Project to Sustainable

Elite Hoops, Jordan’s flagship app for basketball coaches, began as a focused solution to a specific problem: helping coaches organize plays, drills, and practices more effectively. Over time, it evolved into a reliable, revenue-generating business—one defined not by explosive growth, but by consistency.

Jordan explains that Elite Hoops is highly seasonal, with most revenue generated during the basketball season. Rather than fighting this reality, he embraced it. Each year, the app grows during peak months and stabilizes during the off-season, resulting in a steadily rising baseline. This predictable rhythm has enabled Jordan to reinvest with confidence, plan for the long term, and resist the pressure to chase constant growth.

Learning the Realities of Acquisition: Growth VS Paid

A central theme of the conversation is Jordan’s evolving relationship with paid advertising. For years, he ran ads intuitively—without deep attribution or advanced tracking—relying instead on instinct and observation. While this approach worked early on, it eventually revealed its limits.

By working with a professional marketing agency, Jordan began to understand where his growth was truly coming from. He discovered that seasonal demand and strong App Store search performance were driving much of Elite Hoops’ success, while some paid campaigns were offering little real impact. This realization marked a turning point: moving from indie intuition toward more disciplined, data-informed decision-making.

The experience reinforced an important lesson—scaling sustainably often requires uncomfortable shifts, including better instrumentation, clearer attribution, and a willingness to admit what isn’t working.

Reconnecting with Craft Through Alyx

Alongside the business-focused Elite Hoops, Jordan built Alyx, a caffeine-tracking app designed as a creative outlet. Unlike his sports apps, Alyx was intentionally crafted as a playground for iOS features—integrating HealthKit, widgets, shortcuts, App Intents, and system-level APIs.

Alyx wasn’t built to maximize revenue. Instead, it served as a reminder of why Jordan started building apps in the first place: joy, curiosity, and craftsmanship. Shipping Alyx alongside a new iOS release became a personal milestone, symbolizing a return to playful experimentation and platform-native design.

This dual-track approach—one app focused on sustainability, the other on creative freedom—has allowed Jordan to balance business responsibility with creative fulfillment.

Building for Longevity in a Changing Indie Landscape

Jordan and Charlie also reflect on the broader indie ecosystem. They discuss how conversations around app development have shifted from craftsmanship toward growth metrics and monetization strategies, and how parts of the once-vibrant indie community have fragmented over time.

Jordan’s perspective is grounded and optimistic. Rather than chasing trends, he believes longevity comes from solving real problems, respecting users, and staying aligned with personal values. Not every app needs to scale endlessly; some are meant to grow steadily, support their creators, and evolve thoughtfully over time.

Conclusion

Jordan Morgan’s story is not about overnight success or viral growth. It’s about building apps that last—through seasonality, plateaus, and changing platforms—while staying connected to the joy of making things well.

Whether through a sustainable business like Elite Hoops or a craft-driven passion project like Alyx, Jordan’s journey offers a powerful reminder: meaningful products are built patiently, intentionally, and with a long-term mindset.

For builders navigating the tension between craft and commerce, this episode is a thoughtful exploration of how to keep both alive—and why the long game is often the most rewarding one.

Paywalls now work on the web

Wed, 31 Dec 2025 13:12:59 GMT

If you already use RevenueCat Paywalls on mobile, you can now use those same paywalls in the browser.

The paywalls you’ve designed for iOS and Android now render on the web, using the same layouts and components.

One paywall across mobile and web

Web paywalls aren’t a separate object or a new paywall type. They’re the web version of the paywalls you already create at the Offering level.

An Offering can include mobile products, web products, or both. When it includes both, the same paywall layout serves mobile and web users.

Your structure, copy, and experiments carry over automatically. You design a paywall once and use it across platforms.

Where web paywalls show up

You can use web paywalls in two places, depending on how your product is set up.

Inside Web Purchase Links
Web Purchase Links are RevenueCat-hosted checkout URLs. If a link uses the default package selection page, you can replace that step with your paywall.

Users see your messaging, layout, and pricing context before checkout begins. You control the experience earlier in the flow, where it matters most.

Embedded in your web app with Purchases.js
If you use Purchases.js, you can now render paywalls directly inside your web app. Call presentPaywall, pass the HTML element where it should appear, and RevenueCat handles the rest.

The paywall renders in place and continues into checkout without custom UI or hand-built flows.

Works with Web Billing and Paddle

Web paywalls support both RevenueCat Web Billing and Paddle.

Which products appear depends on the web config attached to the surface showing the paywall. A Web Purchase Link connected to a Paddle config shows Paddle products. Switch that same link to a Web Billing config and it shows Web Billing products instead.

The paywall layout stays consistent while the product source changes based on configuration.

Change paywalls without shipping updates

Web paywalls are hosted and server driven.

You can update copy, layouts, pricing blocks, and calls to action from the dashboard. When you publish, changes go live immediately.

You can also target paywalls by country, platform, app version, or custom segments. Experiments work the same way they do on mobile, so you can test pricing, layout, or messaging on the web with the same tools.

When something stops converting, you can respond the same day.

Run subscriptions from one place

You can embed web paywalls directly into your app or link to them through hosted URLs. Either way, you manage subscription flows for mobile and web from the same system, using the same paywalls and workflows.

Paywalls on the web are available now.

How Alper Taner Navigates the Evolving World of Mobile Growth

Wed, 24 Dec 2025 14:48:37 GMT

Alper Taner has spent over a decade in mobile growth, working across a wide range of verticals and managing large marketing budgets. In this episode, he shares his insights on what it takes to drive growth in today’s ever-changing app landscape.

Focus on Data-Driven Decisions

Alper emphasizes that while best practices can be helpful, they shouldn’t be followed blindly. The key is to prioritize what works for your specific app, based on your own data and current stage. Whether it’s testing creatives, bidding strategies, or incrementality, always ground your decisions in your app’s data, the same approach might not work for every account, so testing and adapting are crucial.

Don’t Rush to Call Something a Problem

One of Alper’s most critical insights is the importance of understanding the facts before reacting. For example, low trial conversions may seem problematic, but they may simply reflect the business model or user acquisition strategy. Test, iterate, and diagnose before labeling something as an issue. Often, low metrics are just the starting point for valuable insights.

Creative Testing: Quality Over Quantity

Alper challenges the standard approach of testing hundreds of creatives with little focus on why they work or don’t. He advocates for testing fewer creatives with strong hypotheses and focusing on what makes them successful. It’s not about the numbers—it’s about finding what resonates with your audience and optimizing accordingly. Vigorous creative testing should be both iterative and radical to uncover real winners.

Control Your Spend, Guide the Algorithm

A major theme in Alper’s approach is taking control over your budget. He advises setting clear spend limits, adjusting bids based on performance, and using tools like budget caps to guide the algorithm. Don’t let platforms dictate your spend—use intelligent, strategic control to optimize your campaigns effectively.

Learn From Competitors, But Don’t Copy

Alper cautions against blindly copying competitors. While it’s helpful to learn from what others are doing, the real value lies in customizing those insights for your app and audience. Competitor ads can inspire, but success comes from tailoring strategies to fit your unique goals and data.

The Importance of Accurate Data and Instrumentation

Accurate data is at the heart of Alper’s marketing approach. He stresses the importance of proper data instrumentation to ensure that you can make informed decisions. Whether it’s MMP, in-app analytics, or creative performance, interpreting data accurately is essential to guiding your marketing efforts and avoiding costly mistakes.

A Holistic Approach to Testing and Learning

Alper advocates for testing everything from bidding strategies to event mapping. He explains that small changes, like adjusting how events are mapped, can significantly impact performance. At the same time, always be open to radical testing—sometimes, doing the opposite of what’s commonly recommended can unlock new opportunities.

Conclusion

Alper’s story is a reminder that in the world of mobile growth, success is about innovative experimentation, data-driven decisions, and constantly challenging what’s considered “best practice.” Be persistent, iterate based on results, and stay focused on long-term growth—it’s all about finding what truly works for your specific app and market.

Understanding Google Play’s subscription lifecycle: a complete guide

Mon, 22 Dec 2025 00:05:47 GMT

Managing subscription lifecycles on Android is one of the most complex aspects of in-app billing implementation. Subscriptions go through numerous states throughout their lifetime, from initial purchase to renewals, grace periods, account holds, pauses, cancellations, and eventual expiration. Each state transition requires specific handling in your app to ensure users receive the correct entitlements, while your backend maintains accurate subscription records. Understanding these lifecycle events is essential for building a robust subscription system that minimizes involuntary churn and provides a seamless user experience.

To make it a little clearer, you will break down the complete Google Play subscription lifecycle in depth. We’ll cover every subscription state and the transitions between them, examine how Real-Time Developer Notifications (RTDN) inform your backend of changes, understand the differences between auto-renewing and prepaid subscriptions, and see how proper lifecycle handling can recover revenue from failed payments. Finally, we’ll look at how RevenueCat simplifies this complexity by abstracting away much of the lifecycle management.

The subscription lifecycle at a glance

Before diving into the details, let’s establish a mental model of how subscriptions flow through different states. A subscription begins with a purchase, enters an active state, and eventually either renews successfully, encounters payment issues, gets canceled, or expires. The complexity arises from the numerous intermediate states and recovery mechanisms that Google Play provides.

Each state has specific implications for user entitlements and requires different handling in your app and backend.

New subscription purchases

When a user purchases a subscription, your app receives a SUBSCRIPTION_PURCHASED notification, and the subscription enters the SUBSCRIPTION_STATE_ACTIVE state. This is the starting point of the lifecycle.

The critical acknowledgment requirement

One of the most important aspects of handling new purchases is acknowledgment. Google Play requires you to acknowledge a subscription purchase within three days of the transaction. If you fail to acknowledge within this window, the user automatically receives a refund, and the subscription is revoked.

The acknowledgment serves as confirmation that you have granted the user access to their purchased content. It’s a safeguard that protects users from situations where a purchase succeeds on Google’s side but fails to register in your app.

Understanding the purchase response

When you query a new subscription purchase using the purchases.subscriptionsv2.get API endpoint, you receive detailed information about the subscription state:

Field	Value for new purchase
subscriptionState	SUBSCRIPTION_STATE_ACTIVE
acknowledgementState	ACKNOWLEDGEMENT_STATE_PENDING
autoRenewEnabled	true
expiryTime	Next renewal date

The expiryTime field indicates when the current billing period ends and renewal will be attempted. For a monthly subscription purchased on January 15, this would be February 15.

Linking purchases to user accounts

Google Play provides ExternalAccountIdentifiers to help you associate purchases with user accounts in your system. When configuring the billing flow, you can pass your internal user ID:

These identifiers are returned in the purchase response and RTDN notifications, allowing your backend to correctly attribute purchases to user accounts even in edge cases like upgrades, downgrades, or resubscriptions.

Subscription renewals

For auto-renewing subscriptions, Google Play automatically attempts to charge the user’s payment method when the billing period ends. Successful renewals trigger a SUBSCRIPTION_RENEWED notification.

What happens on successful renewal

When a subscription renews successfully, the subscription remains in SUBSCRIPTION_STATE_ACTIVE, and the expiryTime is updated to reflect the new billing period. Importantly, renewals do not require acknowledgment, only the initial purchase does.

Your backend should update the stored expiry time when receiving the renewal notification:

Renewal date behavior

Google Play follows specific rules for renewal dates that you should be aware of:

Subscriptions started on 29, 30, or 31 of a month will renew on day 28 (or 29 in leap years) when the following month has fewer days
Once a renewal shifts to an earlier date (like 28), it stays on that date for subsequent months
For example, a subscription starting March 31 renews April 30, then May 30, June 30, and so on

This behavior can affect analytics if you’re tracking renewal patterns, so keep it in mind when building reports.

Grace periods: the first line of defense

When a renewal payment fails, Google Play doesn’t immediately suspend the subscription. Instead, it enters a grace period: a recovery window during which the user retains full access while Google retries the payment.

Grace period configuration

Grace periods are enabled by default in the Play Console and can be configured per subscription:

Billing period	Available grace period options
Weekly	3, 7 days
Monthly	7, 14, 30 days
Annual	7, 14, 30 days

During the grace period, the subscription state changes to SUBSCRIPTION_STATE_IN_GRACE_PERIOD, but autoRenewEnabled remains true because the user hasn’t canceled; they just have a payment issue.

Handling grace period in your app

When you detect a user is in the grace period, you should encourage them to update their payment method. Google provides the In-App Messaging API to display a standardized payment update dialog:

The key point is that users retain access during the grace period. Your app should continue providing the subscribed features while simultaneously nudging users to fix their payment method.

Silent grace period

Even if you configure a zero–day grace period in the Play Console, Google Play still provides a minimum one–day silent grace period for payment processing retries. During this silent grace period, the subscription appears as SUBSCRIPTION_STATE_ACTIVE (not IN_GRACE_PERIOD).

This is important to understand because you might receive a delayed notification about payment issues. After 24 hours, the subscription will transition to one of several states depending on the outcome:

SUBSCRIPTION_RENEWED if the retry succeeded
SUBSCRIPTION_ON_HOLD if account hold is enabled
SUBSCRIPTION_CANCELED if the user canceled during this time
SUBSCRIPTION_EXPIRED if no recovery mechanisms are enabled

Account hold: the second chance

If the grace period expires without successful payment recovery, the subscription enters account hold. This state represents a more serious payment failure where the user loses access to subscribed content.

Account hold duration

Account hold is enabled by default with a duration of 60 days minus the grace period length. For example, if you have a seven–day grace period, account hold lasts 53 days. During this time:

The subscription state is SUBSCRIPTION_STATE_ON_HOLD
The expiryTime is set to a past timestamp
The subscription is not returned by queryPurchasesAsync()
The user should lose access to premium features

User experience during account hold

Your app should detect when a user’s subscription is on hold and display appropriate messaging. Since subscriptions on hold are not returned by queryPurchasesAsync(), you need to query your backend or the Google Play Developer API directly to check for this state:

This implementation requires some infrastructure: your backend must receive and process RTDN notifications, store subscription state, and expose an API for your app to query. You also need to handle edge cases like network failures, state synchronization, and ensuring your backend state matches Google Play’s state.

With RevenueCat SDK, this complexity is taken away entirely across platforms. RevenueCat processes RTDN notifications on your behalf and maintains subscription state that you can query with a single call:

RevenueCat’s CustomerInfo automatically reflects the current subscription state, including account hold status via the billingIssueDetectedAt field. The managementURL property provides a direct link to Google Play’s subscription management screen where users can fix their payment method.

During account hold, users can still cancel, restore, or resubscribe. If they fix their payment method, you’ll receive a SUBSCRIPTION_RECOVERED notification, and the subscription returns to SUBSCRIPTION_STATE_ACTIVE with the same purchase token — it’s a recovery, not a new purchase.

The billing date reset

An important detail: when a subscription recovers from account hold, the billing date resets to the recovery date. If a user’s subscription was originally set to renew on day 15 of each month, but they recover from account hold on day 22, their new renewal date becomes day 22.

Subscription pausing

Google Play allows users to pause their subscriptions — a feature that can reduce cancellations by giving users a temporary break without losing their subscription entirely.

Pause configuration and availability

Pause functionality is enabled by default in the Play Console but is only available for certain billing periods:

Billing Period	Available Pause Durations
Weekly	1, 2, 3, 4 weeks
Monthly	1, 2, 3 months
Three-month	1, 2, 3 months
Six-month	1, 2, 3 months
Annual	Not available

Annual subscriptions cannot be paused, this is a deliberate limitation because the pause period could potentially exceed the subscription duration.

The pause lifecycle

Pausing involves multiple notifications as the pause progresses through its stages:

User initiates pause: SUBSCRIPTION_PAUSE_SCHEDULE_CHANGED notification
- State remains SUBSCRIPTION_STATE_ACTIVE
- User retains access until current billing period ends
Pause takes effect: SUBSCRIPTION_PAUSED notification
- State becomes SUBSCRIPTION_STATE_PAUSED
- User loses access
- PausedStateContext contains the expected resume date
Subscription resumes: SUBSCRIPTION_RECOVERED notification
- Can be automatic (pause period ends) or manual (user resumes early)
- State returns to SUBSCRIPTION_STATE_ACTIVE

If the user manually resumes their subscription before the pause period ends, their billing date changes to the date they resumed. This is similar to the billing date reset that occurs after account hold recovery.

Handling pause in your app

Handling subscription pauses requires tracking multiple states and coordinating between your app and backend. The challenge is that paused subscriptions behave differently from other non-active states, a scheduled pause still grants access, while an active pause does not.

Your backend needs to process RTDN notifications to track pause state changes:

On the client side, your app needs to query the backend to determine the current pause state and display appropriate UI:

The complexity here involves distinguishing between a scheduled pause (where users still have access) and an active pause (where access is revoked). You also need to handle the case where users cancel their scheduled pause, and provide a way for users to resume early if they choose.

With RevenueCat, pause state management becomes straightforward:

RevenueCat automatically tracks pause state through its server-side RTDN processing. The managementURL property provides a direct link to Google Play’s subscription settings where users can view their pause status, cancel a scheduled pause, or resume early. This eliminates the need to build custom deep links or track pause scheduling on your backend.

Additionally, RevenueCat’s webhooks notify your server of pause events in a normalized format, making it easy to trigger pause-related communications like “We miss you!” emails or special offers to encourage early resumption.

Cancellations and expirations

When a user decides to cancel their subscription, the lifecycle enters its terminal phase, but cancellation doesn’t mean immediate loss of access.

The cancellation grace period

Upon cancellation, users retain access until the end of their current billing period. The subscription enters SUBSCRIPTION_STATE_CANCELED, and the expiryTime indicates when access will be revoked.

Understanding cancellation reasons

The canceledStateContext field provides valuable information about why the subscription was canceled:

User voluntarily canceled (check userInitiatedCancellation for the survey response)
Developer canceled via API
Subscription was replaced (upgrade/downgrade)
Payment failed and all recovery mechanisms were exhausted
Google canceled due to policy violations

This information is valuable for understanding churn patterns and improving retention strategies.

Expiration: end of the line

When the expiryTime passes for a canceled subscription, or when account hold ends without recovery, the subscription expires. You receive a SUBSCRIPTION_EXPIRED notification, and the state becomes SUBSCRIPTION_STATE_EXPIRED.

At this point, you should:

Revoke all entitlements associated with the subscription
Mark the purchase token as invalid in your database
Optionally, offer win-back promotions to the user

Restore and resubscribe: bringing users back

Google Play provides two mechanisms for users to return to a subscription they previously had: restore and resubscribe.

Restore: before expiration

If a user cancels but then changes their mind before the subscription expires, they can restore it. This uses the same purchase token and continues the subscription as if it was never canceled.

Your app receives a SUBSCRIPTION_RESTARTED notification, and the subscription returns to normal active status. Importantly, you don’t need to acknowledge restored subscriptions because you already acknowledged the original purchase.

Resubscribe: after expiration

If the subscription has already expired, users can resubscribe, but this is treated as a new purchase with a new purchase token. You’ll receive a SUBSCRIPTION_PURCHASED notification and must acknowledge within three days.

The resubscribe response includes helpful fields for linking the new subscription to the user’s existing account:

Upgrades, downgrades, and plan changes

When users change their subscription plan, whether upgrading to a more expensive option or downgrading to save money, it creates a new subscription while invalidating the old one.

The linked purchase token

Plan changes generate a new purchase token, but the response includes a linkedPurchaseToken field pointing to the previous subscription:

Proration modes

When implementing plan changes in your app, you can control how billing is handled using different proration modes:

Mode	Behavior
IMMEDIATE_WITH_TIME_PRORATION	User is credited/charged immediately, billing date unchanged
IMMEDIATE_AND_CHARGE_PRORATED_PRICE	User charged prorated amount immediately
IMMEDIATE_AND_CHARGE_FULL_PRICE	User charged full new plan price immediately
DEFERRED	Change takes effect at next renewal

The choice of proration mode affects user experience and revenue recognition, so consider your business requirements carefully.

Revocations and refunds

Sometimes subscriptions end abruptly due to revocation or refund, bypassing the normal cancellation flow.

When revocation occurs

You receive a SUBSCRIPTION_REVOKED notification when:

You revoke the subscription via the Developer API
A chargeback occurs
Google revokes due to policy violations

Revocations are immediate, the subscription jumps straight to SUBSCRIPTION_STATE_EXPIRED, and you should revoke access immediately:

Prepaid subscriptions: a different lifecycle

While this article focuses primarily on auto-renewing subscriptions, it’s worth understanding how prepaid plans differ. Prepaid subscriptions don’t automatically renew; users explicitly purchase additional times.

Key differences for prepaid plans

Aspect	Auto-Renewing	Prepaid
Renewal	Automatic	User-initiated top-up
Grace Period	Yes	No
Account Hold	Yes	No
Pausing	Yes (if enabled)	No
States	All states	Only Active, Pending, Expired

Prepaid acknowledgment timing

Prepaid plans have stricter acknowledgment requirements:

Plans ≥ 1 week: acknowledge within three days
Plans < 1 week: acknowledge within half the plan duration

For a three–day prepaid plan, you must acknowledge within one and a half days, or the user receives a refund.

How RevenueCat simplifies lifecycle management

Managing all these lifecycle states, notifications, and edge cases requires sophisticated backend infrastructure and careful implementation. This is where RevenueCat provides substantial value by handling most of this complexity automatically.

Automatic state management

RevenueCat maintains subscription state in real-time, processing Google Play’s RTDN notifications on your behalf. Instead of building infrastructure to receive, validate, and process notifications, you simply query RevenueCat for the current customer state:

The CustomerInfo object reflects the current state of all subscriptions, including:

Active entitlements
Expiration dates
Whether the user is in a grace period
Billing issues that need attention
Management URL for subscription settings

Handling grace periods and billing issues

RevenueCat’s CustomerInfo includes a billingIssueDetectedAt timestamp when a subscription has payment problems. You can use this to show appropriate messaging:

RevenueCat also provides webhooks that notify your server of subscription events in a normalized format, making server-side integration much simpler than processing raw RTDN notifications.

Cross-platform subscription state

One of RevenueCat’s most convenient features is maintaining subscription state across platforms. If a user subscribes on Android and later opens your iOS app, their subscription status is automatically recognized. This is particularly valuable for lifecycle events, a subscription that enters grace period on Android will be reflected in the iOS app’s CustomerInfo without any additional implementation.

Revenue recovery

RevenueCat’s Billing Alerts feature can automatically attempt to recover failed payments by:

Sending customizable email notifications to users with billing issues
Prompting users to update payment methods at optimal times
Tracking recovery rates and providing analytics

This automates much of the grace period and account hold handling that would otherwise require custom implementation.

Analytics and insights

Understanding your subscription lifecycle patterns is crucial for optimization. RevenueCat provides detailed analytics including:

Churn analysis by cancellation reason
Grace period and account hold recovery rates
Subscription duration and renewal patterns
Revenue metrics across lifecycle stages

These insights help you identify where users are dropping off and opportunities to improve retention.

Best practices for lifecycle management

Based on the lifecycle stages we’ve covered, here are key practices to implement:

Always verify on your backend

Never trust the client-side subscription state alone. Your backend should:

Process RTDN notifications (or use RevenueCat’s webhooks)
Verify purchases using the Google Play Developer API
Maintain authoritative subscription state

Handle grace periods proactively

Users in grace periods are at high risk of churning. Implement multiple touchpoints:

In-app messaging using Google’s API
Push notifications reminding users to update payment
Email campaigns for users not opening the app

Make cancellation reversible

Since users retain access until their billing period ends, make it easy to restore:

Show clear ‘Resume subscription’ options
Don’t punish users who explore cancellation
Consider exit surveys but don’t make them mandatory

Plan for edge cases

Real-world subscription management involves many edge cases:

Users switching devices mid-subscription
Multiple purchases from the same user
Refunds and chargebacks
Subscription transfers between accounts

Build your system to handle these gracefully, or use a service like RevenueCat that handles them automatically.

Summary

Google Play’s subscription lifecycle is comprehensive but complex. From the initial purchase through renewals, grace periods, account holds, pauses, cancellations, and expirations, each state requires specific handling to ensure users receive correct entitlements while your business captures all possible revenue.

The key states to understand are:

Active state where users have full access
Grace period where users retain access while you attempt payment recovery
Account hold where access is suspended pending payment fix
Paused state where users voluntarily pause their subscription
Canceled state where users retain access until their paid period ends
Expired state where access should be revoked

Whether you implement subscription lifecycle management directly or use RevenueCat, understanding these lifecycle stages is essential for building a robust subscription business on Android. The difference between losing a subscriber to involuntary churn and recovering them often comes down to how well you handle grace periods and account holds. The difference between a confusing user experience and a seamless one depends on how gracefully you handle pauses, cancellations, and restorations.

For complete documentation on subscription lifecycle management, refer to the official Android Developer documentation and RevenueCat’s subscription guidance.

Monetize faster with RevenueCat Test Store by testing purchases without App Store or Play Console

Fri, 19 Dec 2025 16:13:33 GMT

A hosted test store that behaves like a real store

Test Store is a first-class store object inside RevenueCat; it stores products, serves offerings, accepts purchases, and records transactions for testing only. It is not a simulator or a local mock. When your app uses a Test API key, the SDK fetches Test Store products, runs the test purchase flow and returns customerInfo and entitlements that match production shapes. Test activity is marked sandbox and kept separate from production.

Skip store setup and get a working paywall in minutes

You can skip the slow parts of early monetization. No need to configure App Store Connect and Play Console credentials. Test Store is provisioned automatically with every new project so you can design paywalls, test purchases, and iterate on subscriptions without waiting for platform setup.

Start testing paywalls instantly and run repeatable subscription tests

Start immediately; a Test Store appears with every new project
Validate paywalls end to end; receipts, entitlements, and customer objects match production
Run subscription lifecycle tests quickly
Test in Expo, web previews, simulators, and dev builds that lack native store APIs
Rotate Test API keys for safety and keep test traffic out of revenue metrics

Never ship an app with a Test Store API key

Enforce production keys at release. Test Store uses its own key so you control which store your app talks to during development, but production builds must switch to your platform-specific API keys. RevenueCat enforces this for a reason; if a release build initializes with a Test Store key, the SDK will show an alert and crash the app. That hard stop protects the security of your entitlements and prevents test purchases from leaking into production.

To lock things down even more, use the Sandbox Testing Access allowlist. You can restrict Test Store and other sandbox purchases so only approved App User IDs receive entitlements or virtual currency during testing. That way, non-production purchases stay in a safe, controlled lane while your real customers remain unaffected.

Create a project and run your first test purchase in minutes

Create a new project in the RevenueCat dashboard and the Test Store is ready by default. Point your dev build at the Test API key, fetch offerings, and make a test purchase; you’ll see customerInfo update and entitlements change just like production.

Test Store removes the biggest speed bump in early monetization: no platform credentials, instant provisioning, and realistic test purchases so you can iterate faster and ship with confidence.

To learn more, head over to the Test Store docs.

What app buyers really want: insights from 10 leading acquirers

Thu, 18 Dec 2025 14:40:24 GMT

Despite the fact many app developers dream of selling their app, the world of app buying is still rather uncharted territory. Much like job interviews or talking about personal finance, people seem to shy away from frank conversations.

Luckily, we don’t. And it seems about time someone demystified these questions.

Questions like:

What’s my app worth?
Do I need to stay after the acquisition?
Can I stay after the acquisition?
Do buyers prefer organic or paid traffic?
How good does my retention need to be?
What’s a multiplier and how do I get it/do it/be it?

Answering those (and some others) is the goal of this article. Currently most app acquisition advice floating around the internet is either outdated, generic, or coming from people who’ve never actually bought an app.

For various reasons, many buyers keep their perspectives private; but just as job interviews are getting more transparent in what to prepare, we think founders deserve reliable acquisition guidance. So, we went straight to the source!

This is the real state of industry acquisitions, straight from the people shaping the vertical: buyers.

If you’re a founder looking for an exit, or even just a newbie planning ahead, we promise you this is worth 10x the hours you’ll spend watching interviews, listening to podcasts, and in 1:1 conversations.

Featured app buyers

Evelin Herrera is Founder of EHVM App Capital, the mobile app M&A firm working with high-growth app founders on exits and strategic acquisitions. Every day, Evelin is in the field working directly with founders and buyers, facilitating deals. So who better to get the real answers from buyers on what they’re looking for?

After scouring her network, Evelin interviewed ten experienced, international buyers on everything from valuation to founder status post-acquisition. We’ve taken those interviews, and unpicked the answers to all those questions you haven’t had ticked off yet (or are too afraid to ask).

Here’s who Evelin spoke to:

🇺🇸 Dan Novaes, Co-Founder & CEO at Mode Mobile
🇫🇷 Guillaume Larrieu, VP of Business Development at Quiet
🇨🇦 Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital
🇸🇰 Matej Lancaric, Independent User Acquisition & Marketing Consultant
🇪🇸 Michael McPhee, Head of Business Development and M&A at Leadtech Group
🇵🇱 Paweł Pochowski, Head of Business Development at Nova Sphere
🇬🇧 Ryan Thorpe, Director of Growth at Reflective Apps
🇺🇸 Tom Kenney, CEO & Co-founder at LOYAL
🇹🇷 Yalçın Özdemir, Founder & CEO at AppNation
🇺🇸 Zach Tobin, Founder of Product Growth LLC

These are the people acquiring, integrating, and scaling apps today, spanning app categories like gaming, health & fitness, productivity, utilities, and lifestyle. Read on for a peek into their world…

TL;DR: the real state of app acquisitions (according to the people writing the checks)

If you’re just here for the quickfire facts, we’ve got you covered. From 10 hours of interviews, here are the highlights you need to know if you’re interested in selling your app.

The majority of buyers prefer keeping original talent (including the founder) in place post-acquisition: they benefit from product knowledge, quick iteration, and being able to scale without delays.
The starting point for valuing your app is 3–5x EBITDA (earnings before interest, taxes, depreciation, and amortization), provided your app is older than two years and has four plus months of subscriber retention.
Strategic acquisitions (not purely financially-motivated) do happen, but they’re rare and require a lot of matchmaking.
Most companies offer 100% upfront cash as standard, but some offer variants like earnouts or equity. Consider these options carefully, as they can increase/decrease your overall valuation.
Different buyers favour more organic or more paid traffic; organic builds reliable growth, but paid user acquisition (UA) drives scale. Try targeting a 50/50 mix to show strong metrics and reduce the risk of algorithmic reliance.
Why are buyers looking to acquire in the first place? Buyers have seen double revenue in 12–18 months for <$500k acquisitions, so financial incentives are high. Many acquirers also prefer buying versus building from scratch to reduce risk, accelerate growth, and start with apps that benefit from proven product-market fit (PMF).
The top green flags for acquisition are: high retention, low running costs, organic compounding, domain authority, proven PMF and market momentum.

What actually drives app valuation, and the truth about multipliers

This is the first question developers always have: how much can I get for my app business? But valuation is tricky — you have to reflect potential future growth, stickiness > trends, technology moats (if any), and multiple other factors.

The best way to answer the crux of this question is by hearing it from the folks who put the capital on the table. But, before we dive in, let’s cover a couple of basics: acquisition types and multipliers.

Strategic vs. financial acquisitions

Believe it or not, not all apps are bought just for financial gain. In fact, most are a mix of strategic moves, financial motivation, and passion projects. But broadly-speaking, there’s two types of acquisition: financial and strategic.

Financial acquisition are valuations are solely based on the financial performance of the company:

“Financials are the priority, but if something lines up strategically with what we’re building, we’ll go there too.” — Dan Novaes, Co-Founder & CEO at Mode Mobile

Strategic acquisitions consider the strategic value (e.g. a gap in their app portfolio, or particularly strong market value) an acquisition is bringing to the business — typically these come with a premium price:

“We’re always looking for acquisitions that help us advance our strategy of building a portfolio of high-quality life improvement-focused apps. We then base our valuation on a number of factors.” — Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital

Are multipliers the defining factor in an acquisition?

In the world of mobile app acquisitions, multipliers are tossed about left, right, and centre. Along with all the wonderful acronyms that come with them.

In short, a multiplier is a simple way buyers estimate a business’ value, based on core financial metrics. It’s about saying “we value your app at X times what it earns”, aka thinking about what it could earn.

Most acquisitions use a core metric like monthly recurring revenue (MRR), annual recurring revenue (ARR), or EBITDA as the baseline. A multiple is the price per unit. So if an app makes $100k EBITDA, and buyers typically pay 3-5X EBITDA, then the app is worth $300-$500k. Buyers anchor value on these metrics because they’re disciplined, and it minimizes risk of overpaying.

“Valuations are always based on multiples. If you’re not disciplined, you’ll overpay which makes it that much more difficult to succeed. Valuations need to create a win/win for all parties, including the buyer.” — Tom Kenney, CEO & Co-founder at LOYAL

Many founders obsess over multipliers and assume they’re the be-all and end-all for getting acquired. But the reality Evelin heard from every buyer was that multipliers are a starting point, not a golden rule. The real valuation moves up or down depending on a number of factors (which we’ll get into shortly) like retention, scalability, growth, team etc.

For example, Yalçın Özdemir, Founder & CEO at AppNation, explained how, for the right app, valuations can be flexible:

“When we identify opportunities where our strengths can quickly improve the revenue, we’re willing to stretch valuations. In these cases, we see the real value in the match between what the founder has built and what we can contribute.” — Yalçın Özdemir, Founder & CEO at AppNation

When multipliers don’t tell the full story

As Yalçın says, multipliers aren’t the sole deciding factor in whether a buyer is interested. The big picture matters too, and certain industries, like gaming, can be less rigidly-reliant on multiples:

“Multipliers are a useful tool, but they’re not the only method we rely on — and certainly not always the most accurate. For example, games often experience revenue decline once user acquisition spend is reduced. In these cases, a valuation based solely on the past 12–24 months might not reflect the true potential.” — Paweł Pochowski, Head of Business Development at Nova Sphere

Early-stage apps or products in emerging niches can also be poorly reflected by multiples alone. Paweł explained that these categories may not have had a chance to prove their value through performance metrics yet: “In these scenarios, we look beyond historical data and consider market trends, strategic fit, and growth potential. If we see strong momentum or a unique positioning, we’re open to offering above-standard valuations.”

“We start with financial performance, then dig deeper into the performance metrics, and build a comprehensive model that allows us to understand an app’s history, its current place in the market and value to current and past users.” — Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital

Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital, also says many buyers factor in their current app portfolio when valuing new apps: “We consider how complimentary it is to our overall portfolio and ultimately determine what price we are able to pay. We can, and do, pay higher multiples for assets that accelerate our overall plan, but within a range that is based on financial discipline.”

How to hack the high-multiple tier

So what’s the secret to your app sitting in that magic high-multiple tier?

Typically, valuations are a multiplier range e.g. 3–5x EBITDA. Different factors make apps lower or higher, and a handful of buyers will stretch beyond standard ranges when an app unlocks something bigger for their app portfolio.

These reasons could be:

Cross-sell potential
Category expertise
Shared users
Proven PMF in a target market
A feature set they lack internally

This is why founders should talk to multiple buyers. Your best valuation may come from the buyer who sees the most synergy between your app and their current portfolio, not the highest revenue multiple.

Across every buyer Evelin spoke to, there was an unmistakable pattern. If you want the upper end of the multiplier range, you need these three things:

Strong retention: this signals undeniable product-market fit, and is the best predictor of long-term cash flow
Low operational burden + clean architecture: buyers want to scale quickly and easily — they can’t do that if there’s missing documentation, inconsistent analytics, or messy code
Organic or compounding distribution: this equals an efficient growth engine; think untapped markets, clear opportunities to expand features, early traction in a category etc.

Not much to ask, right?

Takeaway: valuation + multipliers

While multipliers are simple to understand and have a quick potential for evaluating your app, it’s more important to find a buyer that’s the right fit. If your app helps a buyer advance faster towards their goal, offers a strategic or portfolio fit, or has growth momentum, you’re far more likely to get a much higher multiplier.

Likewise, if a buyer can clearly see where they’ll create value, the app becomes more attractive — and more expensive. Early trajectory and category dynamics also influence valuation almost as much as financials. But remember: financial responsibility still holds out. Most buyers put stock in EBITDA/MRR multiples, and won’t take a big financial risk.

The app buyer wishlist: what founders should optimize before acquisition

While multipliers play a part in getting that offer, there’s a lot of factors that influence whether buyers move a deal forward. Evelin asked about the top three things buyers look for in an app, and do you know how many said the same top three factors?

Yup, zilch. There’s no one-size-fits-all approach.

But just like the signals influencing your multiplier, there were frequent recurring factors that all buyers put as priorities. Primarily, everyone mentioned retention and having ‘sticky’ users.

“Ultimately, the lower the price of the acquisition, the better. And the faster the return-on-investment, the better. But we look at so many factors and how they relate to each other.” — Ryan Thorpe, Director of Growth at Reflective Apps

Here’s what our buyers are looking for:

Retention
Organic growth
Monetization potential
Valuation and ROI
Technical infrastructure
Product-market fit
Familiarity with the vertical and/or strategic/portfolio fit
Market momentum

Let’s break these down.

Priority	Why?	Relevant metrics
Retention	Retention is a key signal your user base isn’t going anywhere (and therefore has financial potential). Buyers see this as a quality signal and a sign you’ve got PMF. They want to see low churn and user ‘stickiness’; people keep coming back, even when the product doesn’t have new features, or has the odd bug. Retention is the strongest signal of PMF, future cash flow, and downside protection. High retention reduces risk, even if growth slows.	DAU/MAU Cohort retention Churn rate Conversion rate
Organic growth	Buyers are looking for growth, domain authority, and demand driven by organic channels. While not all buyers care whether traffic is organic or paid (more on this later), everyone agreed that organic growth indicates positive brand association and compounding growth potential.	% of installs from organic Keyword rankings (ASO + SEO) for core terms Review volume + average rating
Monetization potential	While it may feel counterintuitive, buyers see under–monetization as a plus, since it indicates the app can make more money than it currently is. They’re looking for proven monetization success, clear room for improvement, and revenue quality as well as quantity.	ARPU Annual vs. monthly subscription mix RPI Subscription pricing and offer structure
Valuation and ROI	This is our multiplier moment. Buyers mentioned that the deal needs to make financial sense for both parties. Some had specific cash offer ranges in mind, while others specified that payback periods factor into their decision. Several said they’d pay more if the app was a good ‘fit’.	LTV/CAC Payback period Gross margin
Technical infrastructure	Buyers are looking for apps that are easy to maintain. The infrastructure should be stable and scalable. Clean architecture, well-documented processes, and a reliable backend were all directly called out.	App stability metrics Infrastructure cost as % of revenue Billing failure rate
Product-market fit	Across the board, buyers want to see evidence that the app truly solves a problem for a defined, existing audience. Without PMF, even the best-looking app is a no-go.	Retention Long-term subscribers Churn rate Social proof
Familiarity with the vertical and/or portfolio fit	Buyers prefer markets they already understand, where existing analysis can be repurposed and userbases overlap. A number of buyers said they prioritize apps in familiar markets which fit within their portfolio. However, some buyers were category-agnostic and instead looked for niche verticals with room for growth, even outside their expertise. Others said they look to plug gaps in their existing offering.	Category benchmarks vs. peers (e.g. retention, ARPU) Overlap with buyer’s existing portfolio Pricing alignment with competitors
Market momentum	Apps in growing or emerging spaces are popular. Category leaders and UA are used as a proxy for measuring momentum. Acquirers want to see a ‘booming niche’ or high-potential in a vertical.	Install growth rate (MoM/YoY) Revenue growth rate Category growth indicators Category benchmarks
Timing	Two buyers explicitly mentioned timing and looking for signals that the app can go further, but needs some help. Bottlenecks like bandwidth limits, founder fatigue, little knowledge of marketing, or hitting an execution ceiling were all mentioned.	Qualitative signals

Almost no one values pure revenue alone. High multiples and desired apps come from alignment, across retention, distribution, monetization, and personal buyer fit.

Above all, everyone was looking to see an app that has found its place with strong audience and market fit. If it slots into a strategic or portfolio gap, even better. The recurring theme is this app works, but we can make it work much better.

Okay, we know that multipliers don’t always tell the full story, and we know what buyers look for — let’s dig a little deeper into how you can illustrate these points when your app’s being assessed.

Retention signals that tell buyers your app is ‘healthy’

Retention is a crucial point for many buyers — and it makes sense; if you’re paying years in advance of the business’ success, you want to retain paying users for a considerable time. Buyers consistently ranked retention as one of their top three valuation drivers, but how can founders prepare a retention story that clearly demonstrates stickiness, and reduces perceived risk?

Based on Evelin’s conversations, retention signals fall into three buckets:

1. Retention matches category benchmarks: Buyers aren’t looking at universal stats, they’re evaluating retention relative to category norms, price point, subscription length, frequency of use etc.

“I look at who’s the biggest player in the category? How much revenue are they earning? What kind of UA channels do they run? This then serves as a benchmark for the app I’m considering. All this comes into my decision matrix.” — Matej Lancaric, Independent User Acquisition & Marketing Consultant

The State of Subscription Apps report shows how drastically retention shifts between categories. Make sure you know your industry, what competitors are doing, and how you hold up.

2. Clear stories behind early churn: With 30% of subscriptions cancelling in the first month, churn doesn’t mean an automatic ‘no’ from buyers. But you need to show that you understand why the churn happened, and have used it as a lesson to course-correct. If you can explain churn, you can defend your valuation.

3. Cohorts that stabilize over time: Even if churn is high, you can still gather evidence that the most important long-term users stick. Create a holistic view of your retention, across different subscription plans, user segments, and attribution sources.

Now, if you’re looking at your RevenueCat dashboard and panicking about your retention rate, hold on a moment. The threshold considered ‘strong retention’ varies considerably between buyers:

Ryan Thorpe, Director of Growth at Reflective Apps, said “We have some apps as low at 25%, others as high at 60% on yearly subscriptions. It massively depends on what you class as ‘healthy’, and the kind of subscription model you’re running.”

Meanwhile, Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital, said: “Generally, I would say 60–70% is a decent range for annual subscription retention, depending on the app category and age. But there are a number of factors that can impact retention (like pricing strategy). It’s just one of many metrics we look at to determine whether an app is a fit for us and what its value is.”

Takeaway: retention signals

This is a breath of fresh air for developers: it’s not all about subscriber retention — all the other signals we outlined on the app buyer wishlist matter too. Consider payback periods, your pricing model, and LTV/CAC ratio; all of these add up to tell your retention story. And even then, ‘good’ retention can be anywhere between 25–70%, depending on who you’re asking.

Make sure you understand your app’s metrics, know your category benchmarks, and can explain (or defend) any questions that may be thrown at you. Resources like the State of Subscription Apps report are a great place to start when comparing what ‘good’ looks like. You can also use tools like RevenueCat’s Subscription App Healthscore calculator to see how you measure up to competitors.

Paid or organic? Buyer preferences on traffic and UA

Another question Evelin gets all the time is whether organic traffic or scaling paid user acquisition (UA) matters more in valuations. This was one of the most polarizing questions in her interviews — some buyers want pure organic, others want pure paid. Most fall somewhere in between.

Buyers who strongly prefer organic growth

Organic traffic is seen as lower risk and higher value for money. Zach Tobin, Founder of Product Growth LLC, prefers organic: “It’s less effort to maintain, though it carries risk of algorithm changes. Ideally we want 100% organic, but I’ll invest in paid up until the breakeven point, which usually works out to an 80/20 split.”

Ryan Thorpe, Director of Growth at Reflective Apps, agreed: “Organic traffic is more reliable in distribution, predictable in its yearly returns, and has no additional high marketing costs.”

These buyers value defensibility, and compounding growth. Organic growth is perceived as a sign of quality and secure product-market fit; making it an indicator for future reliability.

“The higher the organic traffic, the better. High organic traffic that is compounding is what we’re looking for: a predictable trend, where distribution is effectively free with product-market fit attained and momentum accelerating.” — Ryan Thorpe, Director of Growth at Reflective Apps.

Buyers who prefer paid user acquisition

But for other buyers, paid UA is seen as more predictable and thus scalable:

“Paid traffic is the backbone of our strategy… We’ve seen way too many examples of young apps rapidly showing growth through pure organic activities, but being unable to sustain that for the long run. Long-term profitability and scalability means paid UA.” — Guillaume Larrieu, VP of Business Development at Quiet

Tom Kenney, CEO & Co-founder at LOYAL, explained that paid traffic can be a tactic to “break through the app store noise”, while other buyers preferred paid UA for its clearer insight into CAC, ROAS, funnel performance, and channel trends — helping prevent costly future mistakes.

Buyers who want a balance of organic and paid traffic

While some buyers said solely paid or organic traffic would turn them off an app, the majority of buyers said they wouldn’t be closed off to a split traffic mix, with many buyers actually preferring this for its balanced growth potential.

Guillaume Larrieu, VP of Business Development at Quiet, said 75/25 paid/organic is a good mix for his acquisitions: “It’s even better if organic installs are driven by organic activities, like viral videos or social content, rather than ASO implementations.”

Other buyers, like Dan Novaes, Co-Founder & CEO at Mode Mobile, were happy with a more even split:

“I like paid traffic with a strong organic multiplier. Paid is predictable and scalable if you know what you’re doing. Algorithms change, so you can’t just rely on organic. A perfect world is 50/50 organic/paid.” — Dan Novaes, Co-Founder & CEO at Mode Mobile

Takeaway: organic vs. paid traffic

Both types of traffic are relevant, but it’s clear that having paid UA is useful for buyers wanting to see metrics, profitability, or avoid old mistakes. While organic tells a story of pure growth, paid is seen as more predictable.

You don’t need a perfect traffic mix before selling, but you need to be able to back your traffic split:

If organic is your strength, quantify defensibility
If paid is your strength, present UA profitability + failed experiments + learnings

Make sure you can offer buyers clarity on what channels work, what channels don’t work, why, and where you’ve built efficiency.

“We don’t have a preference for type of traffic, but if the app is doing paid acquisition then we really need to understand the UA metrics and what’s driving paid user performance, so we can determine how sustainable and scalable it is.” — Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital

Closing the deal: how to find (and actually talk to) a buyer

So you know what buyers are looking for, you’ve cleaned up your numbers, and coordinated the story of your app’s success. Now you just need to get in front of a buyer.

Sometimes a buyer may approach you, but if you’re ready to go right away, here’s how to get started.

Research different types of buyer: individuals and businesses acquire apps for many reasons, and these different buyer types will look for different things. Spend some time familiarizing yourself with who buys apps, and where your app would fit best.
Find your buyers: once you know the type of buyer you’re looking for, it’s time to network. There are websites and marketplaces where you can advertise your app, or you can speak to an M&A expert. Your best bet is typically networking in-person and LinkedIn. You’ll normally be looking for folks with business development, M&A, or partnership in their job title.
Build a target list: after identifying your buyers, start tracking everyone in a spreadsheet. Record buyer info, typical deal size, recent acquisitions, and how to contact them. You can use this to document your outreach progress, too.
Reach out via channels that don’t waste time: warm intros (founders, angels, lawyers, accountants, UA consultants) will always outperform cold calling/emailing. If you can’t find a mutual connection, direct outreach can work through the proper channels. You can also check out founder or buyer forums or marketplace websites, where buyers may be discreetly lurking. And don’t forget in-person networking opportunities!
Lead with a message, not your life story: your first message shouldn’t be a pitch. It’s a qualifier. Keep it simple, straightforward, and factual. Add top compelling metrics (think MRR, margin, growth), any relevant info (like similar apps they’re acquired, mutual connections etc.) and ask for a follow-up call.

Once you get to the first call, your next moves will depend on who you’re talking to and what they’re looking for. Remember to lead with a combination of facts and storytelling, and keep momentum up in your conversations.

What does receiving an acquisition offer look like?

You know how job ads frame ‘compensation packages’ versus individual salaries? Well, acquisition offers are similar. Typically, there’s three main structures to offers:

Cash: fixed purchase price, paid upfront when the deal closes — this is the lowest risk for sellers, and most common kind of offer
Equity: part (or all) of the price is paid in shares of the buyer’s company; tying your payment to their growth
Earnout distribution: a portion of the price is paid only once hitting agreed revenue, profit, or growth targets post-acquisition

Of the buyers Evelin spoke to, 66% do cash offers, with the remainders doing a mix of cash and equity or earnouts. While cash offers won’t necessarily pay out in one chunk (most buyers do 50% at a time, sometimes 6/12 months after the deal), they’re typically the best outcome for sellers, though equity can be valuable if being acquired by a successful company.

What makes a deal close fast?

This section answers one of founders’ biggest questions: What makes a buyer say ‘yes’ quickly?

Across interviews, buyers described what makes a deal feel ‘clean’ and easy, opposed to risky or slow. Here’s what speeds up decisions:

Clean, consistent financials: speed requires all the numbers to be in order. No messy revenue classifications. No unexplained cliffs. No ‘miscellaneous’ line items. Anything but clear numbers will add a red flag and significantly slow down the process.
Clear handover documentation: buyers moving quickly need to know they can pick up the new app and keep it ticking over without any trouble. This means getting access to: architecture overviews, data taxonomies, analytics events, roadmap history, experiment logs, growth playbooks, and anything else you have lurking in your Google Drive!
A transparent founder: yes, fast-closing deals rely on a solid business, but they’re also impacted by trust. Buyers who click with a founder and feel they’ve made a trusted connection will overlook imperfections and move faster.
A believable growth story: quite simply, buyers want to clearly be told what happens after they buy the app. Help plot their success, and they’ll be eager to sign on the dotted line.

The talent taboo: Do app buyers want founders to stay?

Most founders assume a buyer will want them gone immediately. But in reality, the answer is more nuanced — and varies depending on the buyer’s operating model.

Across all interviews, we noticed three things:

Historical learnings can be very useful to support product scale
Developers bring product and vision, then acquirers add marketing and monetization expertise
Acquirers are interested in long term relationship-building

Buyers value product knowledge more than headcount

Many acquirers prefer the original team to remain during the transition (or longer) for the undeniable reason that they deeply understand the product’s history, vision, and technical decisions.

“We like the teams to stick around as long as they’re still committed. The history of what they’ve tried is useful context, and we can build on that. Where they’re weaker, we plug in our expertise.” — Dan Novaes, Co-Founder & CEO at Mode Mobile

Michael McPhee, Head of Business Development and M&A at Leadtech Group, said they ‘absolutely’ want founders to stay: “We always try to keep the team behind the app engaged after the acquisition. They know the product best, and their expertise is crucial for continued development and fast iterations.”

Paweł Pochowski, Head of Business Development at Nova Sphere, agreed: “From a practical standpoint, having the original developer onboard ensures smoother maintenance and faster implementation of changes.”

For many buyers, acquisition is about combining skillsets of the founding team and the new owner. Michael explains: “At Leadtech, we focus on scaling marketing, monetization, and UA, while the original team focuses on product enhancements. This balance builds strong long-term partnerships and is one of the keys to our success.”

Buyers don’t want to relearn the product from scratch. They want continuity, and to capitalize on existing success.

Founder involvement signals belief and influences valuation

Some buyers also explicitly said that a founder wanting to stay post-acquisition can influence higher valuation. Paweł Pochowski, Head of Business Development at Nova Sphere, said the team prefers original creators to remain involved:

“Their continued commitment is a strong signal they believe in the product and are motivated to see it evolve.” — Paweł Pochowski, Head of Business Development at Nova Sphere

Founders wanting to stay part of the team not only indicates belief in the product, but a level of passion and commitment that’s desirable of any team member. Rather than wanting to grab the cash and jump ship, founders who stay involved can support future growth, and enable smooth handovers when (or if) the time comes to part ways.

Some acquisitions are structured to absorb the product

Despite the benefits of creators remaining involved, large app studios or portfolio operators — particularly those with their own internal product, engineering, and UA teams — are less dependent on founders staying. However, this doesn’t mean they’re kicking you out of the door.

As Yalçın Özdemir, Founder & CEO at AppNation, puts it:

“We don’t expect founders to stay on after an acquisition. As a large app studio, our in-house teams, systems, and expertise allow us to integrate products efficiently and unlock value independently. That said, in rare cases where founders are deeply embedded in the product and critical to its continuity, we may ask them to remain for a transitional period of a few months.”

This is why it’s crucial to talk about your future as a founder with any potential buyers — wanting to leave or stay with the app won’t necessarily impact the sale, but it’s vital you’re all on the same page.

Takeaway: closing the deal

Once your numbers and story are tight, closing the deal is primarily about:

Finding the right buyer
Making it easy for them to say yes

Get to know your buyer types, build a focused list of targets and start networking. Deals move fastest when financials are clean, handover docs are ready, and founders are transparent. You don’t need to commit years of your life post-acquisition, but you do need a clear transition plan. If you’re hoping to exit, consider how you can still convey confidence and historical product context to the new owners, be it through roadmaps, documentation, or a new advisory role.

Checklist: founder prep-list for getting acquired in 2026

If you’re simply looking for a to-do list that answers “What do I need to do to get my app acquired?” then your wish is our command.

Below is a foolproof checklist, distilled from Evelin’s app buyer interviews, ready for you to take the next steps towards acquisition. Think of this as ongoing prep for any founder looking to exit, be it today or five years from now.

1. Prepare your metrics

Metrics are the evidence buyers need to decide whether your app is worth their time. Prioritize clarity and consistency — confusing or contradictory metrics slow deals more than ‘bad’ metrics.

Top-level data points to prepare:

LTV by cohort and LTV/CAC ratio
Retention curves (D7, D30, D90+ where possible)
Churn reasons (voluntary vs. involuntary)
Organic vs. paid traffic split
UA profitability (by channel + key experiments)
Revenue breakdown (subscription vs. IAP vs. ads)
% of users on annual plans (if applicable)

2. Prepare your product

Think of yourself as a salesperson: for the highest valuation, you need to make it as simple and appealing as possible for buyers to pick up the product and make money.

Remember: Buyers aren’t looking for perfection, they’re looking for low friction.

Clean up any messy code paths or one-off hacks
Reduce reliance on fragile third-party dependencies
Improve onboarding clarity
Tighten paywalls and pricing logic as necessary
Grow your organic traffic where possible (ASO, reviews, SEO)

3. Prepare your financials

Messy or unclear financials are one of the fastest ways to kill a deal. If a buyer has to infer what’s going on with your numbers, they’ll assume the worst. Make sure they don’t need to guess.

Before talking to buyers:

Review and cut non-essential costs (this will improve EBITDA and optics)
Clean and reconcile your profit and loss statement
Clearly document add-backs and one-off expenses
Prepare MRR breakdowns (country, store, plan, platforms)
Be ready to explain any revenue spikes, anomalies, or drop-offs

4. Prepare your team

Buyers care less about headcount, and more about continuity and protected knowledge. Make sure you have conversations with your team before speaking to buyers.

You need to decide:

Who’s staying post-acquisition, and for how long?
What knowledge or responsibilities need to be transferred?
Whether you’re open to staying involved, and in what capacity
Updated contracts, NDAs, and IP assignments

5. Prepare your handover

Deals move faster when buyers can clearly see how they’ll run the app without you. Document things only you currently know, or product decisions and historic context that may be helpful for the team:

Current and historic product roadmaps
Feature gating logic
Paywall logic and pricing history
Onboarding flows and funnels
Architecture overview (simple is fine)
Brand assets and press kit
A master doc of tools, SDKs, dashboards, logins

6. Prepare your deal

Don’t wait until an offer appears to think about what you want, how you’ll approach acquisition conversations, and who else needs to know.

Here’s what you should think about:

Decide your minimum accepted offer and structure (cash vs. earnout vs. equity)
Identify your ideal buyer type (studio, roll-up, strategic)
Build a target buyer list
Talk with at least five potential buyers before choosing
Prep your first message and practice your pitch
Be honest with yourself about timing, motivation, and trade-offs

You don’t need to tick off every item on this list at once, it’s a big job. But each checkmark is something prepared ahead of time, so when the right buyer shows up you can move forward quickly.

Final thoughts: the reality of selling apps in 2026

After speaking to buyers, and having spoken to many founders over the years, Evelin says the biggest misconception founders have about acquisitions is that buyers are looking for perfection.

They’re not.

They’re looking for:

Predictable revenue
A product with real PMF
Retention that holds
A growth story that makes sense
A clean, transparent business

Founders who can clearly communicate these signals, both in narrative form and in hard data, are going to consistently earn higher valuations and close deals faster. So if you’re wanting to sell in the next 12–24 months, start preparing now. You don’t need a perfect app or perfect pitch — you need a clear story, transparent figures, and the right buyer.

Looking for more? Here are some related readings and tools to help you on your path to acquisition.

Interview transcripts: read the full interview questions and answers
RevenueCat’s subscription healthscore calculator
Report: State of Subscription Apps (perfect for industry benchmarking!)
Blog: How to sell an app, lessons from David Barnard
Podcast: What makes an app worth buying? Lessons from BlueThrone’s shift from volume to value
Podcast: How real demand turned a hobby app into a business
Evelin’s template: App learnings and experiments documentation
Evelin’s template: Profit and loss statement

The play-once game that sparked an indie dev career

Wed, 17 Dec 2025 09:47:26 GMT

When Taiwo Omisore set out to make mobile games, he didn’t plan on building a business. He simply wanted to make something fun during his long commute. Over time, those experiments turned into a catalog of 15 quirky, joyful, and highly personal apps. One of them, a game designed to be played only once, changed his life.

This week on Launched, we talk with Taiwo about how a side hobby became a full-time indie business powered by constraints, shareability, and unexpected virality.

The app that turned everything around

In 2020, Taiwo released One Chance, a game you can only play once. No retries. No replays. One Chance consisted of 14 quick mini-games, a leaderboard, and that’s it. He shared it quietly on TestFlight and Reddit. Then it started spreading—first in Germany, then globally. Soon, it was featured on the App Store.

What surprised him most wasn’t the downloads but the behavior. People dug up extra devices just to try again. Friends and coworkers turned it into a competition. And the game’s single ad, shown only after gameplay, became a smart trade for attention.

Real users and measurable feedback

Taiwo’s apps are playful, often strange, and always rooted in real-world input. Early on, he handed his phone to strangers on trains for feedback. Later, he’d bring folding tables to public spaces and host multiplayer games live with passersby.

That same openness shaped everything from features to monetization. After One Chance took off, Taiwo experimented with subscriptions in apps like MultiWords and 10 Games. By focusing on simple mechanics, thoughtful UX, and low-friction monetization, he found a model that worked.

Many of Taiwo’s apps have no ads or in-app purchases. Some, like Who Am I?, even inspired physical art exhibitions. Others, like Of The Day, are updated daily with curated content and community submissions. He answers emails personally and celebrates being a one-person studio.

Social media became a way to connect, not just promote. On TikTok, he shares coding sessions, street interviews, and app concepts. One clip even prompted a journal entry by Harry Styles.

A developer-first approach

Today, Taiwo is a full-time indie. But his approach hasn’t changed. He builds fast, ships often, and keeps the focus on fun. His apps aren’t optimized for retention. In fact, some are designed to be deleted. And yet, they continue to find an audience, thanks to the care he puts in them and their contagious charm.

Conclusion

From single-play games to curated journals, this episode captures what’s possible when an indie dev leads with curiosity. Taiwo Omisore shows that with honesty, experimentation, and a little bit of joy, even the simplest ideas can turn into something lasting.

Monetize from Your IDE: AI assistant + RevenueCat MCP in the IntelliJ Plugin

Wed, 17 Dec 2025 01:32:17 GMT

We’ve announced the RevenueCat IntelliJ plugin and now it’s even got smarter. With the new AI Assistant feature, you can now query your subscription metrics, explore offerings, and get answers about your RevenueCat integration, all without leaving your IDE. Behind the scenes, this AI Assistant is integrated with the RevenueCat MCP Server, bringing the power of AI-assisted subscription management directly into your development workflow.

In this article, you’ll explore how the AI Assistant works in RevenueCat’s IntelliJ plugin, what you can accomplish with it, and how this feature can help you make data-driven decisions that boost your subscription revenue.

What is the RevenueCat MCP Server?

Before diving into the AI Assistant, let’s understand the foundation it’s built on. The Model Context Protocol (MCP) is an open standard that allows AI assistants to interact with external tools and data sources. RevenueCat provides an official MCP Server that exposes subscription management capabilities to AI models.

The MCP Server provides tools for fetching subscription metrics like MRR, active trials, and revenue. It can list and inspect offerings, packages, and products. It retrieves customer subscription information and provides documentation and resource links.

The IntelliJ plugin’s AI Assistant uses the same underlying tool architecture as the MCP Server. This means you get consistent, reliable access to your RevenueCat data directly inside your IDE with our preferred AI model.

Setting up the AI Assistant

Getting started with the AI Assistant takes just a few steps.

First, open IntelliJ Settings and navigate to RevenueCat, then AI Settings. Enable the AI Assistant toggle to activate the feature.

Next, choose your AI provider. The plugin supports OpenAI (GPT-4o, GPT-4o Mini), Anthropic (Claude 3.5 Sonnet, Claude 3 Haiku), and Google (Gemini 2.5 Flash, Gemini 2.5 Pro). Each provider has different strengths—GPT-4o and Claude Sonnet excel at complex reasoning, while GPT-4o Mini and Gemini Flash offer faster responses for simpler queries.

Then enter your API key for your chosen provider. The key is stored securely in IntelliJ’s credential storage on your local computer.

Finally, make sure your RevenueCat API credentials are configured in the main RevenueCat settings panel.

Once configured, you’ll find the AI Assistant panel in the RevenueCat tool window. The interface is simple: a chat-style conversation where you can ask questions and receive responses.

What can you do with the AI Assistant?

The AI Assistant exposes four core capabilities through its tool set. Let’s explore each one with practical examples.

Fetching subscription metrics

The most common use case is checking your subscription health without leaving the IDE.

Ask the assistant “What are my current metrics?” or “Show me my MRR” and you’ll get a formatted response with your Monthly Recurring Revenue (MRR), active trials count, active subscriptions count, and total revenue. More than just querying, it’s your mini consultant. You can play with these metrics and get useful strategies to boost your revenue.

This is invaluable during development. You can push a new paywall implementation, then immediately check if metrics are trending in the right direction. No dashboard tabs, no context switching.

You can also ask follow-up questions like “How does my trial conversion look?” or “What’s my revenue growth?”, and “What can I do for boosting my revenue?” The AI will analyze your metrics and provide insights based on the data.

Exploring offerings and packages

When implementing purchase flows, you need to know exactly what offerings and packages are available.

Ask “What offerings do I have configured?” and the assistant will list all your offerings with their lookup keys, display names, and whether each is marked as the current offering. For each offering, you’ll see the packages it contains.

This is particularly useful when you’re implementing a paywall and need to reference the exact package identifiers. Also, you can get directly the SDK API codes, by asking like “How should I fetch offerings on Android using Kotlin?”

No more switching to the dashboard to double-check package names. Ask the assistant, get the answer, keep coding.

Checking project configuration

Before diving into implementation, verify your setup is correct.

Ask “What’s my project status?” and the assistant will show whether your API key is configured, your project ID, whether the SDK API key is set up, and the status of notifications and webhooks.

This quick health check catches configuration issues before they become runtime bugs. If something’s missing, the assistant will tell you exactly what needs to be configured.

Finding documentation and resources

When you need help with implementation, ask “Where can I find documentation for Android integration?” or “How do I set up webhooks?”

The assistant provides curated links to relevant RevenueCat documentation, SDK guides for Android, iOS, Flutter, and Kotlin Multiplatform, community forums and GitHub issues, and the RevenueCat dashboard and API reference.

Choosing the right AI model

The plugin supports multiple AI providers and models. Here’s how to choose:

For complex analysis and detailed explanations, use GPT-4o or Claude 3.5 Sonnet. These models excel at understanding nuanced questions and providing comprehensive answers. They’re ideal for questions like “Analyze my subscription trends and suggest improvements.”

For quick queries and fast responses, use GPT-4o Mini, Claude 3 Haiku, or Gemini 2.5 Flash. These models respond faster and cost less per query. They’re perfect for simple lookups like “What’s my MRR?” or “List my offerings.”

For balanced performance, Gemini 2.5 Pro offers strong reasoning capabilities with good response times.

You can switch models at any time in settings. Try different models to find what works best for your workflow.

Boosting revenue with AI-assisted insights

Beyond convenience, the AI Assistant can actively help you improve your subscription business.

Identify optimization opportunities

Ask “What do my metrics tell me about my subscription health?” The AI will analyze your MRR, trial counts, and active subscriptions to identify patterns. Low trial conversion? The AI might suggest reviewing your onboarding flow. High churn? Consider implementing win-back campaigns.

Validate A/B test implementations

When implementing offering experiments, verify your setup is correct. Ask “Show me all my offerings and their packages” to ensure your test and control offerings are configured properly before running the experiment.

Debug purchase issues faster

When a user reports a purchase problem, you can quickly check your configuration. “Is my project configured correctly?” gives you an instant health check. “What packages are in my default offering?” helps verify the user should see the right products.

Getting help and exploring more

The AI Assistant includes a help icon that links directly to the RevenueCat MCP usage examples documentation. This resource provides additional query examples and advanced usage patterns.

You can also explore the RevenueCat IntelliJ plugin’s other features. The metrics dashboard, offerings explorer, SDK release notifications, and webhook listener all complement the AI Assistant to create a complete subscription development environment.

Conclusion

The RevenueCat IntelliJ plugin’s AI Assistant brings subscription intelligence directly into your development workflow. By combining the power of modern AI models with RevenueCat’s comprehensive tooling, you can query metrics, explore offerings, check configuration, and find documentation—all without leaving your IDE.

The result is less context switching, more flow state, and faster development cycles. Whether you’re building your first paywall or optimizing a mature subscription business, having AI-assisted access to your RevenueCat data makes the process smoother.

The feature is available now in the RevenueCat IntelliJ plugin. Configure your AI provider, connect your RevenueCat credentials, and start asking questions. Your subscription metrics are just a chat message away.

How to monetize your app without ads

Tue, 16 Dec 2025 11:58:46 GMT

Ads are a common way of monetizing apps — providing a way to extract value from users without making them pay for the app directly. However, due to the scale they require most in-app ads never end up providing enough money to justify the downsides they bring. Additionally the negative effect on user experience and the dependency on ad networks to end up tilting the scale to the negative.

At RevenueCat we aren’t against ads by default, but for most apps asking customers to pay for the app is a better way. This reasoning comes into effect especially when you’re monetizing a new app, where retention is more important than acquiring. That’s why we made this guide to monetizing your app without ads, going through all the other monetization methods you have at your disposal.

This guide takes an indie developer friendly approach, suggesting methods you can adopt from already before you launch your app, and offering guidance on moving from one monetization method as you scale.

Why indie developers should not choose ads

When you’re an indie developer, ads are most likely the worst choice for monetizing your app. Hear me out. You most likely built your app because you yourself had use for it? Or perhaps you wanted to build something cool, or perhaps you just like building apps. Whatever the case is, what you’re predominantly not interested in is money in most cases, but building something people want to use.

There is a certain thrill that you get when you see people using your app that is hard to beat. It can almost become a goal to get more users. At the same time, you wouldn’t mind getting a little bit of monetary recognition for your work. At that point you start to think “I don’t want to restrict my app from anyone, I’ll just put ads”. But ads come with multiple downsides:

Massive downgrade to user experience and messy looking UIs
Plenty of privacy concerns due to user data tracking
Performance issues (draining more battery, more data usage)
Your personal brand will take a hit

In general, it’s hard to position your app as a serious app with ads. There are plenty of ways to monetizing your app that have way fewer tradeoffs. Not to mention how little money ads usually bring you.

To give an example let’s look at the 1000 true fans hypothesis, an article by Kevin Kelly about how you can build a business or side hustle by just having 1000 true fans who all pay a little bit for the things you’re producing. 1000 people paying just a dollar a month is $12k a year. If you had 1000 users using your app with ads, you would only get a few dollars per month.

The core non-ad monetization models

Whether you’re targeting iOS or Android, the ways you can monetize your app are the same. Let’s go through all the ways you can monetize your app beyond ads.

Pay to download

Pay for the full version of the app used to be a common model back when software was still sold on CDs (ask your father). Back then developers could release a new every year and capture more revenue from users as they bought the new version of your app.

App Store and Google Play Store still support putting a price on your app, but Apple for example considers this model outdated. As developing and supporting an app is a continuous process, the only time you should consider adopting pay to download is if you’re going to release your app once, and make only very limited changes to it in the future.

In-app purchases (IAP)

Once the user has downloaded your app, whether that was for free or for a charge, you can actually ask users for more money. Both Play Store and App Store support payments inside apps for purchasing digital goods inside the app, hence the name in-app purchases. There are few different in-app purchase options: consumables, non-consumables, non-recurring subscriptions, and recurring subscriptions: the latter which we will talk about in its own section. Let’s first go through the other options.

Consumables

Consumable in-app purchases are payments for things in the app that the user purchases and then consumes, such as extra lives in a game. They grant users the access to contents only until they are used in the app, so they work well for example in games where you can build custom economies based on them.

Non-consumables

These purchases never expire and the user is for example able to recover the purchases after uninstalling and reinstalling the app, as the purchase information is stored by Apple and Google. You can make non-consumable purchases unlock features in your app for permanent use. You could almost think of these as a way of moving the pay to download further into the actual app itself.

Non-recurring subscriptions

These purchases as the name suggests only grant the user access to features of the app for a certain period of time, for example one month, after which Apple and Google (TK check if google has this type actually) mark them expired. You can build for example limited time

Subscriptions

Of all the mentioned in-app purchases options, only consumable in-app purchases (through repeated use) and recurring subscriptions (through periodic payments) bring you that much needed recurring revenue to continue building your app. Building your monetization around consumable purchases can be difficult, so recurring subscriptions is your best option for monetizing your app if you’re looking for recurring revenue.

The fundamental concept behind subscription is simple: the user pays a periodic subscription fee and has access to all features of your app during the subscription period. If they do not cancel their subscription their access to the app continues, and they keep paying you.

Both App Store and Play Store provide extensive options for configuring subscriptions with different billing periods, prices, and offers such as free trials. Deciding on the pricing can get tricky, but benchmarking against your competitors is a good way to go. You can learn about these from our State of subscription apps report.

Donations and tip jars

Perhaps you don’t want to limit your users’ access to your app or its features, but if they feel like sponsoring you in any way, you wouldn’t say no to that? These types of payments, whether they are sponsorships, donations, or tipping also have to go through Apple’s and Google’s in-app purchase infrastructures.

Donations and tipping and essentially just consumable purchases. If you’re interested in learning more about implementing these in your app, I suggest you take a look at this blog post about building a tip jar in your app.

Virtual currencies

Virtual currencies are in-app currencies that allow your users to pay for using features and services of your app, without having to go through the in-app purchase infrastructure. This could be for example something like Duolingo Gems, which allow you to restore your broken streak. Another type of currency could be a second of video generation in an AI video creation app.

The power of virtual currencies is that you can grant users with virtual currencies either through purchases or by completing certain actions. RevenueCat’s Virtual currencies feature allows you to grant them through both subscriptions as well as consumable purchases, meaning users could receive 500 gems every month for their subscription, but on top of that they can still purchase additional gem packs. Alternatively you could also grant a few gems for watching an ad (if you decide to keep those around).

Games and gamified apps often use some form of virtual currencies, but as mentioned they can also be a flexible monetization method for AI powered tools, where the AI usage can be directly tied to usage. If you’re building an AI-powered app, take a look at this tutorial on monetizing your AI app with virtual currencies.

Hybrid models

Sometimes the best monetization strategy is one that combines multiple different models. Your app could offer both recurring options for monthly and yearly subscriptions, with an extra lifetime subscription that uses a non-consumable in-app purchase to do that. Hybrid models are becoming far more popular and effective than they were in the past. According to the 2025 State of Subscription Apps report, more than 35% of apps now combine subscriptions with consumables or lifetime purchases, and the fastest-growing categories (Gaming at 61.7% and Social & Lifestyle at 39.4%) are leading the shift.

If your app currently has ads, one option is not to transition away from them completely, but instead make it so that the free version of the app has ads, which users can then remove by subscribing. You can learn more about this approach from our building ad-free subscriptions with RevenueCat article.

Virtual currencies is the most flexible option for hybrid models, as mentioned above, since it allows you to add two different recurring revenue models, subscriptions and consumable in-app purchases, without having to manage the complex in-app currencies yourself.

How to find the best model for your app

Since there are multiple ways to monetize your app, it might not be instantly evident what model suits your app the best. This is also something where RevenueCat can help you

Use State of Subscription Apps report to understand your competitors

Every year RevenueCat publishes a report called the State of Subscription Apps, a preview into our insights on in-app subscription performance benchmarks, drawing from the world’s largest and most comprehensive subscription app data set.

The report is a valuable tool for understanding how apps are performing under different monetization scenarios, across both the iOS and Android ecosystems. You can find the latest report here.

Experimentation is the key

Once you have a hunch on what kind of monetization method and pricing could work for your app it’s time to get to work by experimenting. RevenueCat allows you to build different paywalls, target specific types of users, build multiple pricing options with offers, and best of all extensively experiment and test which of these changes convert best to paying users. RevenueCat’s blog has articles around price testing your app’s subscriptions and a study guide for building paywalls that you should go through, should run into a wall.

Wrapping up

Ads promise easy revenue, but for most indie developers they deliver the opposite: low earnings, lower retention, and a worse user experience. Sustainable growth comes from models that align your incentives with your users — and that almost always means asking people to pay for the value you’re building.

Subscriptions remain the most reliable path to recurring revenue, but they’re not the only one. Consumables, virtual currencies, and hybrid approaches let you monetize different user segments without compromising the product experience. As the 2025 State of Subscription Apps shows, the top-performing apps increasingly mix models to boost LTV and give users more flexibility.

Where you start matters less than how quickly you learn. Experiment with pricing, trials, paywalls, and offers. Use data to refine your approach. And lean on tools like RevenueCat to test, iterate, and scale your monetization without rebuilding infrastructure every time.

Build something people love — then choose a monetization model that helps you keep building.

HDYHAU surveys as an attribution source: when they work (and what to do when they don’t)

Tue, 16 Dec 2025 10:50:07 GMT

Uncovering where users first heard about your app and how they came to download it is an age-old problem for app businesses. Tracking attribution is key to tapping into your best user acquisition (UA) sources, but with advertising spread across multiple channels and things like word-of-mouth hard to track, teams are often left in the dark.

‘How did you hear about us?’ (HDYHAU) questions seem to solve this problem, but are they really the solution?

Why use HDYHAU?

Many subscription apps face growing data discrepancies when it comes to tracking attribution. This is largely because iOS remains the primary source of revenue — but while these users typically have higher conversion rate (CVR) and stickiness, iOS offers limited attribution tracking. Structured frameworks for modelling attribution on iOS can help, but that’s only part of the equation.

To address these gaps, teams have opted for a simple way to measure the impact of ads: directly asking users “How did you hear about us?”. This question, commonly shown during onboarding or purchase flows, allows users to self-report their acquisition source. The answer options typically include:

Facebook
Instagram
TikTok
YouTube
Google
Friend
Other

(There are some apps that randomize the order of the options to ensure answers from users are intentional, but in my experience, this doesn’t tend to impact the distribution of the answers.)

For early-stage teams running a small number of social channels (often Meta or TikTok) HDYHAU data has been a gamechanger; helping surface under-attribution in probabilistic systems and align performance with blended results. In these cases, self-reported data often appears more consistent than network or mobile measurement partner (MMP) reporting. However, as apps scale and expand into additional channels, HDYHAU responses become increasingly unreliable as an attribution source (more on this later).

The HDYHAU question fixes a common issue that all advertisers have with iOS: it gives the possibility of comparing like-to-like in a landscape where every attribution methodology works in a different way. If you use tools like Amplitude or Mixpanel, you can have graphics like this:

As you can see, this graphic is simply showing the answers for the HDYHAU question on a weekly basis, so if you take the campaign data, the MMP data, and compare them against this first-party data, you have a very simplistic way of seeing if your campaigns are underattributing or not.

According to my experience, when you use probabilistic methodologies like ADC for TikTok or AEM for Meta, you will likely track less conversions in your campaigns than have actually happened — leading you to make wrong paid UA decisions.

However, with HDYHAU, you quickly solve that problem by comparing both sources, so you can see if certain attribution channels are over- or under-attributed. That looks like this:

Since you (understandably) expect the user-reported data to be most accurate, marketers using HDYHAU as an attribution source typically place more importance on this first-party data than the MMP or ad network data. In most cases, they see greater impact on the blended results when they enable campaigns (like in the screenshot above, from a current project of mine).

Example: how HDYHAU impacts revenue

In my example above, the average difference between HDYHAU and the installs reported by Meta on a daily basis is 95. Assuming you have a 5% CVR, you’re roughly missing ~5 subscriptions per day (150/month) comparing the two attribution sources.

Note: You can also have direct subscription reports on Amplitude, if you group users by the answer they gave in the HDYHAU step, but for the sake of this example let’s keep it simple.

Let’s consider two scenarios where we follow this first-party data:

Scenario one:

On day 90, your app has a lifetime value (LTV) of $50; on day 60, it has an LTV of $30
You don’t have HDYHAU in place, so you’re relying on MMP and ad network data for attribution
You spend $10k on paid campaigns during one month, then crosscheck Meta and MMP data, reporting 200 purchases — resulting in a $50 customer acquisition cost (CAC)
In this scenario, your LTV would cover that CAC in 90 days, so from day 90 you would start to make profits

Scenario two:

Imagine the same scenario, but you do have HDYHAU in place:
You see the same difference on conversions as in my example above (~150/month)
With your first-party data in place and spending $10k on paid, you report 350 subscriptions in the same period of time, giving you a CAC of ~$29
In this scenario, you begin making profit from day 60

In a business model where cash flow is critical, this difference is hugely impacting every decision on weekly optimization of paid campaigns, and how aggressively you can scale them.

This is why first-party data has become a highly-valued data source for app teams relying on social ads. In a world shaped by ATT, SKAN, and privacy constraints, it’s one of few reliable ways of ensuring paid campaigns get the credit they deserve — because the answer is coming directly from users, rather than depending on probabilistic attribution methodologies that rely on fingerprinting.

At a first glance, HDYHAU feels like the perfect solution to address all this attribution mess happening in iOS. No black boxes, no delayed postbacks, no large discrepancies. Just a direct answer from your user collected within your product.

But there’s two significant flaws in this:

The easy-to-read attribution breaks down when you diversify paid ad channels
And what’s more, HDYHAU relies on users accurately recalling and recording where they first heard about you

Most companies begin with the classic ad networks (Google, Meta, TikTok) when they start paid UA, and using first-party data with this setup is smart — it’s likely more accurate than relying on probabilistic attribution. But when you have a large budget for these channels and run alternative ad channels (e.g. a demand-side platform (DSP)), HDYHAU begins losing accuracy.

On a high level of spend, you have a large presence across social media due to paid ads and multiple channels — users will likely have come across an advert, logo, or app name long before they actually download the app. So when they click ‘Facebook’ or ‘TikTok’ as where they first heard about you, they’re actually selecting:

What they think influenced them
What options feel familiar to them

At this point, HDYHAU surveys aren’t capturing causal attribution; they’re identifying perceived influence, brand familiarity, and recall under pressure.

Example: how distribution of spend impacts HDYHAU

This fundamental flaw of HDYHAU at a large business level is also why the distribution of media mix and ad spend will likely affect the distribution of answers.

For example, if your media mix is 60% Meta, 20% TikTok, 20% Google, you’ll likely have a HDYHAU attribution that reflects this, even after running campaigns in an alternative channel. This interpretation becomes critical the moment you introduce these channels into your media mix.

This screenshot is real data from a recent Applovin campaign I ran for a new client. They have a rough $50–60k spend, with 90% to Meta and the remainder to TikTok. We started Applovin for the first time in November and began monitoring the answers to ‘Other’ in the HDYHAU survey.

As you can see, there’s no difference in the baseline after running the campaigns for more than 10 days and spending more than $10k (the minimum budgets in these platforms are much higher). The MMP reported +200 conversions to the campaigns based on last click, so we would have to see an uplift in this baseline.

The reason behind this is simple — platforms like Applovin operate very differently from traditional social ads: they buy inventory across thousands of apps, and show ads beyond social media platforms e.g. playing a game, scrolling, or waiting for a reward. So later, when users reach the HDYHAU question, they just select the most familiar option.

Meta, Google and TikTok benefit massively from this bias, since they’re culturally-dominant and top-of-mind. So even if users didn’t discover the app on these platforms, they’re a safe choice.

The result? HDYHAU surveys over-attribute conversions to the most recognizable platforms → you draw conclusions based on inaccurate data → you base budget allocation and channel optimization decisions on this.

TL;DR: when to use/avoid HDYHAU for attribution

When HDYHAU is treated as accurate attribution, demand-side platforms are set up to (look like they) fail. This doesn’t make HDYHAU surveys useless, but it does limit their use to specific scenarios. Here’s a summary:

✅ When HDYHAU surveys can be reliable:	❌ When HDYHAU may be misleading:
– Paid acquisition is limited to one–two major social platforms – Spend is relatively concentrated (e.g. Meta or TikTok) – The goal is detecting under-attribution in probabilistic systems – Teams are early-stage and optimizing for speed over precision – You want to get indicators of shifting channel familiarity and trends – You need directional insights on brand awareness	– Multiple channels run simultaneously (social + DSPs + search) – Brand presence is already high across platforms – Users are exposed to ads outside recognizable environments

How to measure attribution with DSPs

If you read to this point you’re probably wondering what you should rely on for attribution. HDYHAU surveys are still useful, but only on the small–medium level. Exploring how to measure attribution for larger ad budgets is another article in itself — but broadly-speaking, these are the most effective approaches to see if DSPs are really bringing impact:

Incrementality tests with GEO holdouts
Incrementality tests with Ads ON/OFF
Incrementality tests with budget ramps
Blended performance analysis
SKAN analysis (less effective because it tends to underattribute)

In my opinion, it’s valuable to run incrementality tests where you maintain the classic channels with a stable spend for a few days, and then you substantially increase the budget on the DSP. You can then measure how the baseline of conversions changed before and after starting the campaign in the DSP — and attribute the difference in the baseline to the MMP.

With this approach, you don’t need to pause your main growth driver, since you normally start with DSPs when you’ve already reached a nice volume of spend on the classic channels.

Yes, these methods are slower, less intuitive and harder to justify but they measure causality, not memory.

The value of HDYHAU is how you use them

In the current privacy landscape, first-party data feels like a safe fallback; but data being first-party doesn’t automatically make it correct. The work of growth teams and marketers is to adapt your framework to track data to the current channel mix and then compare how it evolves when a new channel is introduced.

If you want to understand whether your spend is working, you need measurement frameworks built for causality: incrementality tests, controlled experiments, and blended performance analysis. Surveys can still play a role, but only as qualitative context — not as evidence.

Announcing RevenueCat IntelliJ Plugin

Mon, 15 Dec 2025 01:30:14 GMT

Building subscription-based apps involves constant context switching. You write code in your IDE, check metrics in the RevenueCat dashboard, monitor webhook events in a terminal, and browse documentation in a browser. Each context switch may break your flow and add friction to the development process. What if you could bring RevenueCat directly into your IDE?

Today, we’re announcing the RevenueCat IntelliJ plugin, which is a tool that integrates RevenueCat’s core functionality directly into your IDE. You can track metrics, receive purchase notifications, integrate SDKs, set milestones, and stay updated with releases without leaving your development environment.

The plugin works across the entire JetBrains IDE: IntelliJ IDEA, Android Studio, WebStorm, PyCharm, Fleet, and 10+ other IntelliJ-based IDEs. Whether you’re building Android apps in Android Studio, cross-platform apps in IntelliJ IDEA, or React Native apps in WebStorm, the plugin provides a consistent experience.

Getting started

The plugin is available on the JetBrains Marketplace. You can install it directly from your IDE:

Open Settings → Plugins → Marketplace
Search for “RevenueCat”
Click Install

After installing the plugin, open the RevenueCat tool window from the right sidebar. If you don’t see it there, you can enable it via View → Tool Windows → RevenueCat. Then first, configure your API credentials in the settings panel, and you’ll see your metrics appear immediately. You can get all of these keys on your RevenueCat dashboard.

Track key metrics

The plugin displays your RevenueCat dashboard metrics directly in your IDE. You can monitor MRR, active subscriptions, active trials, revenue, and other key metrics at a glance while you’re working on your app.

The metrics panel shows your current subscription values without requiring you to open a browser. When you’re debugging a purchase flow or implementing a new subscription feature, having immediate visibility into your metrics helps you verify that changes are working as expected. The data refreshes by clicking the refresh button, or when you change any configurations.

This is particularly valuable during feature development. When you’re implementing a new subscription tier or modifying your paywall, you can immediately see the impact on your metrics. You can start your morning by exploring the metrics on the IDE directly and focus on your code right away.

Receive notifications for purchases and webhook events

Want a little dopamine hit from new purchase notifications while you’re building? Stay informed about what’s happening with your app’s subscriptions in real-time. The plugin can receive RevenueCat’s webhook events and display notifications for new purchases, renewals, cancellations, billing issues, and other subscription lifecycle events directly in your IDE.

You can set up a webhook for your IDE in the RevenueCat settings. This plugin includes a lightweight local server to listen for webhook events, so you’ll need to configure webhook integration on the RevenueCat dashboard and install ngrok by following the plugin guide. Once it’s set up, the webhook listener will automatically start whenever you restart your IDE.

Once you’ve finished the configuration, you can send a test event from the dashboard by going to Integrations (left menu) → Webhooks → Send test event.

The webhook integration works by running a local server managed by a plugin that receives events from RevenueCat server. When a purchase occurs, a renewal process, or a subscription cancels, you get an immediate notification in your IDE. This creates a tight feedback loop during development, you make a test purchase, and within seconds you see the confirmation appear in your IDE.

This is particularly useful during development and testing. When you’re testing purchase flows with sandbox accounts, you can immediately see whether the transaction went through without checking the dashboard or digging through logs. The notification shows you the event type, the product involved, and relevant details, giving you instant feedback on your implementation.

Browse and manage offerings

Your offerings define what subscription products are available to your users. The plugin displays your offerings directly in the IDE, showing each offering with its packages, current status, and paywall configuration.

Each offering card shows the offering name, the number of packages it contains, and the individual packages with their display names and identifiers. You can quickly scan your product catalog without opening the dashboard. For offerings marked as current, a badge indicates which offering your app serves by default.

The plugin provides a part of RevenueCat’s paywall functionality. If an offering has a paywall configured, you can click the Paywall button to open the paywall tab of your offering directly in your browser. If an offering doesn’t have a paywall yet, the Add Paywall button creates one for you and opens the paywall builder so you can start customizing immediately.

The Manage button takes you directly to the offering’s configuration page in the RevenueCat dashboard. This provides quick access when you need to modify packages, update metadata, or configure advanced settings. Instead of navigating through the dashboard hierarchy, you jump straight to the offering you’re working with.

Integration wizard: Easy SDK and Paywall setup

Setting up RevenueCat in a new project involves multiple steps: adding dependencies, configuring the SDK, setting up entitlements, and integrating paywalls. Each platform has its own requirements, and getting the configuration right requires consulting documentation and copying code snippets. The integration wizard guides you through this entire process.

The wizard supports Android, Kotlin Multiplatform, and Flutter projects. It detects your project type and generates the correct dependency configurations with the latest SDK version for your build system, whether that’s Gradle, or pub.yaml. Beyond dependencies, the wizard suggests initialization code tailored to your platform.

You can choose between SDK-only integration or full paywall integration. The SDK-only option sets up the core RevenueCat functionality for fetching offerings and processing purchases. The paywall integration option adds RevenueCat’s UI components, generating the code to render the paywalls that you can customize in the RevenueCat dashboard.

The wizard eliminates the friction of initial setup. Instead of spending time on boilerplate configuration, you can focus on building your subscription experience.

Set milestones and monitor progress

Building a subscription business is a long-term endeavor. Having concrete goals to work toward helps maintain momentum during development. The plugin lets you define revenue and subscriber milestones to track your app’s growth.

You can set targets for MRR, active subscriptions, active trials, new customers, or total revenue. The plugin monitors your progress against these milestones and displays your current standing. When you hit a milestone, the plugin celebrates with you, providing a moment of recognition for your progress.

This feature transforms abstract business goals into tangible targets visible in your development environment. When you’re deep in implementation work, seeing that you’re 80% of the way to your next subscriber milestone provides motivation to push through. It connects the code you’re writing to the business outcomes you’re working toward.

Stay up to date with SDK releases

RevenueCat’s SDKs are actively developed, with regular releases that include bug fixes, new features, and performance improvements. Staying current with SDK versions ensures you have access to the latest capabilities and fixes, but manually checking GitHub for new releases is tedious.

The plugin fetches release notes from RevenueCat’s GitHub repositories and displays them in a dedicated dialog. You can view the latest releases for Android, iOS, Kotlin Multiplatform, Flutter, and React Native SDKs. Each release shows the version number, publication date, and full release notes, so you can quickly assess whether an update is relevant to your project.

More importantly, you can enable notifications to get alerted when new SDK versions are released. When a new version drops, you’ll see a notification in your IDE with the version number and a link to the full release notes. This helps you stay current with bug fixes, new features, and breaking changes without manually checking GitHub or subscribing to release notifications.

The notification system is opt-in on a per-platform basis. If you’re only building Android apps, you can enable notifications just for the Android SDK. If you’re building cross-platform, you can enable notifications for multiple SDKs.

Browse blog posts and get notified

The RevenueCat blog publishes articles about new features, engineering insights, best practices, and mobile subscription industry trends. Staying informed about these updates helps you make better decisions about your subscription implementation.

The plugin fetches recent articles from the RevenueCat blog and displays them in a browsable list. Each article shows the title, publication date, and a brief description. Clicking an article opens it in your browser, letting you read the full content when you’re ready.

You can enable notifications to get alerted when new articles are published. This keeps you informed about RevenueCat updates, new SDK features, and industry insights without manually checking the blog. When a new article is published, you’ll see a notification in your IDE with the title and a link to read more.

Conclusion

The RevenueCat IntelliJ plugin brings subscription management more convenient directly into your IDE. Instead of context switching between your IDE, the RevenueCat dashboard, GitHub, and the blog, you can access everything from a single tool window. Track metrics while you code, receive instant notification on purchases, set up new projects with the integration wizard, monitor your progress toward business goals, stay current with SDK releases, and keep up with the latest articles.

Web-to-app funnels: the complete 2026 guide

Thu, 11 Dec 2025 14:00:00 GMT

Web-to-app funnels are having a moment — but they’re a lot more complex than send traffic to a landing page and profit. In this guide, we’ll break down when web-to-app actually makes sense, the benefits and disadvantages, how to design and test your first funnel, common questions, and what the future holds for web-to-app.

Personally, I love web-to-app because it blends the best of both worlds I work in: e-commerce and apps. You get the storytelling, experimentation, and control of a web funnel, with the retention and lifetime value power of an app. When it’s done right, it feels like the perfect growth setup. However, it does come with its challenges. I’m excited to guide you through it all.

What is a web-to-app funnel?

Web-to-app funnels (sometimes written as web2app) do exactly what they sound like: they start on the web and drive users into your app. That might mean someone signs up or pays on the web before downloading the app (technically called web-to-web), or sometimes the payment happens after they install the app (web-to-app).

In practice, most people just call it all “web-to-app”. And honestly, that’s fair, both approaches bridge the gap between web <> app. Here we’ll focus mainly on web-to-web funnels, as they differ most from in-app-only funnels.

Benefits of using web-to-app

Web funnels aren’t new — they’ve been popular for years, particularly in the health and fitness space — but their adoption has surged recently. Many believe funnels improve attribution and reduce costs, but of course there are pros and cons to web-to-app funnels. Let’s look at both sides.

1. Cost savings (debatable)

The first reason people often consider web-to-app is cost savings. But like I said, it’s not that simple — Apple and Google take 15%–30% in fees; that’s a big cut. By comparison, web payments usually cost far less (around 2%–3%, though when blended across all fees, more like 6%).

It’s natural to think web-to-app can save money, but it’s important to note that lower fees alone shouldn’t be the sole reason to switch.

As Thomas Petit, App Growth Consultant, explains on the Sub Club podcast, “People are going web-to-app for the wrong reason.” Setting up a web-to-app funnel takes time and effort. Testing a completely new flow can reveal that what works in-app doesn’t always work on the web, and conversion rates may even be lower. This can increase your customer acquisition cost (CAC).

The real benefit isn’t always reduced costs; it’s the potential for higher lifetime value (LTV) per user. Even if your overall costs don’t drop, the value each user brings can increase.

2. Improved retention and LTV

Data shows that web subscribers tend to renew at higher rates than App Store or Google Play users, which generally leads to better retention and higher lifetime value. One reason is friction: on a phone, all subscriptions are in one place, making it easy for users to cancel multiple services at once, a trend we often see in January. Another factor is that web subscriptions often skew toward higher-end offerings.

Web users may also be more accustomed to paying higher prices, making them comfortable spending more on your app as well.

Source: State of Subscription Apps report 2025

3. Simplified tracking and attribution

In 2021, Apple introduced the App Tracking Transparency (ATT) policy, which also resulted in the app world rethinking web-to-app. On the web, tracking is simpler, giving campaigns more data and a better feedback loop.

While web-to-app tracking isn’t perfect (for example, feeding purchase data to Meta seven days later can be tricky), it generally provides better insights into subscriber behavior, helping improve campaign performance, e.g. easily seeing how different acquisition sources impact retention and LTV.

4. Monetization freedom

Money-back guarantees? Go for it. Lifetime subscription offers? Bundles? Upsells? Multiple pricing tests? Go absolutely wild.

Over time, app stores have enforced stricter monetization rules and, as above, tracking. The web, however, is pretty much a free-for-all. You can experiment freely without worrying about app store constraints. Please note this is in no way an encouragement to follow dark UX patterns or test a million things at once — regardless of the channel, you should follow best practices and respect ethical monetization and UX. But this is one reason some folks favour web-to-app.

5. Quicker testing for multiple funnels

The rise in popularity of web-to-app has also driven the growth of no-code web app builders, making it easy for non-developers to build funnels quickly. Maybe not quite as fast as a paywall can be built in RevenueCat (fast, less than four minutes! See the speed-building championship), but still speedy work.

Early-stage startups even use Typeform surveys or simple landing pages as their first web-to-app funnels.

If you’re pre-launch, the joy of having the conversion on the web means you can use it to test messaging, pricing, and positioning early on. As Marcus Burke, Meta Ads & App Growth Consultant, puts it: “You’re not moving to the web to save a 30% store fee. You’re moving to the web as it allows you to differentiate yourself, learn fast, and empower marketing, no matter what your product roadmap looks like.”

6. Faster cash flow

In-app, when you get a new subscriber, great! Oh, wait, please hold up to 68 days for the App Store to pay you. Thanks a lot, App Store, that’s a long time for a cash-strapped startup.

While there are solutions (for example, RevenueCat is launching RC Capital to provide next-day payouts for App Store payout profits), web payments often result in immediate, or very quick, payouts by comparison to app stores.

7. Content-led discovery

As Thomas points out, web-to-app can also be a powerful tool for discovery: larger apps can use web-led content to attract new users. For example, Photoroom offers free web tools that drive awareness and funnel users into their app, creating a content-led growth strategy.

Disadvantages of web-to-app

Before you start building your web-to-app funnel (and attempt to beat that paywall speed-building record), there are some important downsides to keep in mind.

Apps often underestimate how much they’ll need to change or set up for the web. We’ve touched on additional costs and time for testing, but there are a few other factors to consider:

1. Free trials don’t work as well on the web

If your main strategy relies on free trials or a freemium model, it may not translate smoothly online. Web users often enter card details for cards with no balance, so you may need an alternative setup, like a low-cost trial (e.g. $1) or a money-back guarantee.

This can mean fewer free users entering your app, and makes comparing web versus app performance more complicated.

2. Impact on organic rankings and traffic

Many web-to-app funnels convert users directly on the web, which can reduce app installs, ratings, and reviews. In contrast, in-app campaigns drive traffic to app stores, even if users don’t convert immediately.

Fewer installs, ratings, and reviews may hurt your app store ranking and limit organic growth. Nathan Hudson, Founder of Perceptycs, explains the downsides of this as:

“This can also hurt apps scaling paid acquisition who will need support from ASO to continue scaling with their target ROAS. Stronger rankings mean a higher volume of organic installs, which can drastically lower your blended acquisition cost.”

3. Financial and legal complexities

We all cry about the greediness of the app stores charging such high fees, but the reality is they’re actually doing a lot of heavy lifting for us: handling different tax laws, chargebacks, and more.

On the web, you’ll need to handle this yourself. If your app is international, this gets even more complex. While there are solutions for this, like using a Merchant of Records (e.g. Paddle), it’s an additional cost and layer of complexity to the operation.

4. Messier attribution

Running multiple funnels across web and app introduces complexity in tracking and attribution.

App campaigns rely on SKAN or aggregated install data
Web campaigns use pixels and server-to-server tracking

If you’re testing both, it can get pretty messy. You risk having more users, which is great, but not being able to tell where they came from or assign them to the right funnel — making it harder to recreate success (or fix failure). You can improve this by ensuring you consistently tag users across web and app, as well as bringing together the data into a single source of truth.

Key differences between web-to-app and in-app purchases

So it’s clear that web-to-app and in-app purchases operate very differently. While web-to-app offers significant benefits, it’s not something you can whip up to test quickly. Web funnels come with added complexities, as Gessica Bicego, Marketing & Growth Consultant, explained in her workshop at App Growth Annual 2025:

“Web funnels may look simple, but several technical layers add complexity.”

An MMP helps manage deep linking and accurate attribution
A CRM tool is essential to capture and activate the emails you collect
You’ll need a payment processor that handles global taxes
Expect a high failed payment rate (around 50%), but tools and retries can significantly improve acceptance

Here’s a roundup of everything you need to know the differences between web-to-app and in-app purchases.

Area	Web-to-app	In-app purchases
Fees & margins	Lower processor fees (around 2–3% up to 6% including all costs) but higher build + maintenance effort. Savings aren’t guaranteed once conversion drop-offs are factored in.	15–30% store fee, but stores handle tax, refunds, billing errors, fraud, and global payment methods.
Conversion rates	Typically lower initial conversion due to browser handoff friction. Free trials often underperform without tweaks (e.g. $1 trials, money-back).	Smooth, trusted, one-tap purchase results in the highest trial start and paid conversion rates.
Retention & LTV	Users who push through friction tend to be stickier and renew more (potentially higher LTV).	Large volume, but generally slightly lower renewal rates.
Attribution & signal quality	More granular tracking and faster feedback loops. Better for creative testing and channel optimization.	Limited by ATT/SKAN, delayed + aggregated signals, harder learning cycles.
Pricing & monetization freedom	Full flexibility: lifetime deals, bundles, upsells, guarantees, etc. Great for experimentation.	Must comply with App Store rules, less pricing and UX flexibility.
Cash flow	Fast payouts, useful for cash-constrained teams scaling paid UA.	45–60 day payouts (unless using financing products).
User acquisition	Mainly Meta, but it also opens up new audiences and potential channels.	Additional campaign types/channels unavailable to web, e.g. ASO, Apple Search Ads.
Operational complexity	High: own billing stack, compliance with tax laws, fraud management, supporting failed payments, CRM activation.	Low: app stores handle payments, taxes, and global compliance.
Impact on ASO & organic search	Fewer users hit store pages, rankings can drop if too much spend shifts to the web.	Drives ratings, reviews, and traffic that boost discoverability.
Experimentation Speed	Marketers can build/test funnels without waiting for app releases.	More dev-dependent; shipping updates slows testing velocity.
Attribution Across Channels	Hybrid setups introduce attribution complexity across multiple funnels.	Single source simplifies measurement, but SKAN / ATT still impacts measurement.

Who should test web-to-app funnels?

There isn’t one type of app that should test web-to-app; it’s relevant at different stages and for different apps, depending on their category and audience. If you’re wondering ‘should we give it a go?’, these are some of the main groups that should consider testing web-to-app:

1. Early-stage startups

For early-stage startups, web-to-app can be a great way to test your initial funnel and iterate quickly while experimenting with paid acquisition.

That said, it’s best to avoid testing both in-app and web-to-app simultaneously — especially if you’re a small or bootstrapped team — as it can spread your focus too thin. Once you reach a later stage, running both can make sense.

The exception is if you’ve already started with in-app but discover that web is a better fit; in that case, it’s smart to shift your full focus and energy to the web funnel.

2. Apps looking to expand their paid reach

Paid optimization looks very different for app campaigns compared to web campaigns. By focusing on web, you can unlock an entirely new audience you may not have reached before.

It’s often suggested that there’s only about 15% overlap between app and web audiences on Meta, meaning a web campaign can open the door to a whole new audience. Weirdly enough, despite the 100s of apps I download (it’s for work, I promise!) I rarely see an app campaign on Meta, so I’m definitely in that web audience bucket.

3. Apps looking to improve profitability

While skipping app store fees can help, the real profitability boost from web-to-app usually comes from higher lifetime value and better retention. By building stronger relationships with web subscribers who tend to stick around longer, apps can meaningfully improve long-term profitability.

4. Apps focusing on older audiences

Older audiences are generally more comfortable with web-based flows, while younger users (like Gen Z) tend to prefer native app experiences. That doesn’t mean web-to-app can’t work for younger audiences, it just tends to perform better with slightly older demographics who are used to purchasing and subscribing through the web.

5. Certain categories skew more to web-to-app

Web-to-app first gained traction in health and fitness, as well as business apps, but the landscape is shifting. According to the State Of Subscription Apps report 2025, Health & Fitness is now one of the slower-growing web categories. Instead, we’re seeing strong growth across productivity, utility, and education apps as more of these verticals adopt web-first funnels.

We’re also seeing more Lifestyle, Entertainment, and Finance apps adopting web-to-app funnels. Ultimately, it’s less about the category itself and more about what you need to communicate to convince users to try your app.

As Gessica highlights, apps that perform best with web funnels often share these traits:

Your product needs more explanation (not easy to convey in a few lines or visuals)
The experience relies on emotional triggers that can be unlocked through questions or storytelling
You can offer immediate value during onboarding (e.g. quiz results, personalized plan, free tool)
Web onboarding helps educate, engage, and prequalify users before driving them to purchase.

So, category is the least important factor; it’s really about what your app needs to convey to convert users effectively.

6. B2B brands where employers pay

As someone who’s always been deep in B2C, I hadn’t initially considered this use case, but as Thomas explained on Sub Club, web-to-app can be especially valuable for B2B brands.

App stores bill directly to an individual’s card, which isn’t ideal for company-paid subscriptions. The web, on the other hand, allows employers to easily manage team billing, set up company-wide subscriptions, and streamline payment processes, all of which make B2B purchases far smoother.

Testing and measuring the success of web-to-app: free blueprint

As we’ve covered, web-to-app funnels come with added complexity, so take your time and set them up correctly. A common recommendation is to start with a funnel that mirrors your existing in-app flow; this helps speed up setup and minimize differences when comparing results.

That said, don’t just default to a quiz funnel. While quizzes are popular, they’re far from the only option.

To give you a hand, here’s my blueprint to building your first web-to-app funnel.

1. Determine your success metrics and test plan

When testing web-to-app vs. in-app purchases, looking only at conversion rates or CACs can be misleading. It takes time to optimize web conversion rates and build a system that smoothly drives users from the web to the app.

You may see higher trial-to-paid conversions, but other metrics may initially drop. Instead of focusing on short-term numbers, analyze average revenue per paying user (ARPU) and your LTV-to-CAC ratio, factoring in the extra costs of running a web funnel.
For most apps, it’s not an either/or decision. The key question is whether web-to-app helps you reach a new audience profitably. Define how long you’ll test (typically three–six months to get meaningful retention data) and what specific approaches you’ll try, to avoid never-ending tests.

2. Work out your web-to-app setup

Often, many people equate web-to-app with onboarding quiz funnels. While it’s a classic approach, it’s just one of many options — and your web-to-app funnel shouldn’t be a replacement for onboarding.

When testing, consider alternative flows such as:

Landing page → Checkout
Landing page → Sign-up → Install
Smart banners (AppsFlyer, Adjust, etc.)
QR codes → App Install
Email sequence → Web Paywall → Checkout
Lead magnet → App install
Blog post → Install
Webinar funnel → Checkout
Landing page → Web app demo → Checkout

That is not to hate on quizzes — they’re great for personalization, education, and more complex journeys, but they aren’t the only way. As Nathan puts it:

“Don’t just copy what everyone else is doing — think through what makes sense for your product. What are your unique selling points? What are your customers’ pain points? How can you best highlight and address those on the web before they even download your app? It might not be a web onboarding quiz.”

A simple starting point? Gessica shared that using a mini landing page can be an ideal first test to validate your web-to-app funnel before adding complexity.

Credit: Gessica Bicego

What’s great about Gessica’s example is that it mitigates some of the risks of a pure web funnel, particularly around payment setup, but it doesn’t unlock web campaigns on Meta, since payments still occur in the app.

For building landing pages and web quizzes, there are plenty of no-code tools available to help get started: Unbounce, ConvertKit, Web2Wave, and more.

3. Determine the offer structure

Most apps rely on hard paywalls, free trials, freemium, or some hybrid, but the offer structure often needs to change for web-to-app funnels. This is because:

Free trials convert worse on the web due to fraud and lower-intent users
Web checkout friction means users expect a clear, immediate benefit

Instead, we often see:

Paid trials (e.g. seven days for $1)
Money-back guarantees (effective for content or service apps)
Web-exclusive savings (passing fee savings on to users)

You can also simplify plan choices for web users:

Lead with a single annual plan for clarity and higher LTV
Keep monthly pricing in-app to encourage the correct behavior

I really like the example of Plantin, a plant-identifying app. They highlight that the best deal is on web and offer a free trial (but keep it very short) which strikes the right balance between incentivizing users and reducing friction. That 30% off, because it is via the website, makes you feel like you’ve found a special deal.

Over time, as you optimize, you’ll start to match offer structure to traffic intent and channel. For example, high-intent users may respond well to annual savings, while cold audiences may need a low-risk entry point or more explanation of how the money-back guarantee works.

4. Improve your initial funnel

In most cases, you’ll probably want to start by focusing on optimizing your creatives. Especially if you’re running web campaigns for the first time, you’re reaching a new audience, and your creatives will impact the quality of users you attract.

Trust is also a huge factor in web-to-app. In-app, you rely on the app store’s credibility and reviews; with web-to-app, you need to actively build and optimise trust, such as highlighting features, showing social proof and ratings, or introducing video paywalls to serve as mini demos.

From there, ensure you optimise your payment page. You don’t have the same restrictions as in-app on the paywall, so work to ensure the value is clear, that there is a good incentive to choose web, and that it continues to build trust.

A few general best practices to keep in mind:

Make checkout easy (e.g. Apple Pay)
Ensure a seamless handoff to the app (deep link, auto-login)
Maintain a mobile-first UX
Limit plan choices to prevent overwhelm

Once these bits of housekeeping are done, you can further improve your funnel, whether that’s testing and refining the landing page or optimizing your quiz questions (because yes, quizzes can be really useful tools). Questions in a quiz format help to build trust, but irrelevant or vague questions that don’t feel personalized can hurt your conversion rate.

5. Optimize the individual funnels further

The beauty of web-to-app is that you can customise your funnel for each audience. Anastasiia Karlova, Head of Marketing at Plantin, shared an insightful example:

They tested an ‘identify mushrooms’ ad with a web funnel focused on helping users understand which mushrooms they encountered and whether they were edible. It performed well on the web, but once users reached the app, there was no mushroom-related content, and they churned.

This shows that web funnels need to align with the app journey. Optimise each funnel for its channel, ensuring that the experience and content on the app matches what the user was promised on the web.

What’s next for web-to-app?

The future is exciting for web-to-app. Here’s my predictions for what we’ll see:

A larger number of apps testing web funnels as scaling through in-app channels becomes more competitive
More hybrid funnel models, with apps consciously deciding when to send users to the web versus pushing for in-app paywalls
After the Epic vs. Apple ruling (allowing web payments via app in the US), we can also expect to see this expand to other countries and markets, creating new opportunities for web-to-app strategies

As it becomes simpler to build and personalize funnels, we’ll likely see more segmentation and tailored flows for different audiences — for example, wellness app BetterMe already has at least 12 highly optimized funnels!

Web-to-app won’t make you grow overnight, it requires a conscious decision based on your app and how the pros and cons apply. That said, it offers a huge opportunity to unlock a new audience and grow your app. The surge in web-to-app funnels is happening for a reason — while it isn’t for every app, every app should consider whether strategically testing web-to-app could add value as an alternative or complement to their in-app funnel.

Frequently asked questions about web-to-app funnels

What exactly is a web-to-app funnel?

It’s when a user starts their journey on the web — through a landing page, quiz, or another flow — and then converts to install or subscribe in the app. The purchase can happen on the web or in-app.

Why are apps moving to web-to-app now?

After Apple’s ATT changes in 2021, attribution became harder. Web funnels also offer cleaner tracking, faster iteration, more control over pricing and messaging, and potentially higher LTVs.

Does web-to-app always save money?

Not always. Web fees are lower (blended around 5–6% vs. 15–30% through the app stores), but conversion rates can be lower, and additional tools may be needed. The net financial gain varies depending on your setup.

Do I need developers to launch a web-to-app funnel?

Not necessarily. No-code web funnel and landing page builders make it possible to test a funnel with minimal engineering support. Developer help may be required to ensure shared logins or deep linking are set up to reroute users after download.

Are web-to-app funnels allowed by Apple?

Yes, web-to-app funnels have always been allowed. Since the 2025 Epic ruling, apps in the US can also link out to external purchase options.

What kind of apps benefit most from a web-to-app funnel?

Apps with users familiar with the web, higher price points, or more complex onboarding journeys, like health, education, or productivity apps, tend to see the strongest results.

How Greg Cohn turned a failed app into a privacy powerhouse

Wed, 10 Dec 2025 13:40:30 GMT

Greg Cohn’s journey to creating Burner began with his first app, Wrangle. The app was designed to help people find others available for phone calls, but it didn’t gain traction. However, Wrangle introduced Greg to Twilio’s API, which would later play a crucial role in Burner’s development.

More importantly, it sparked Greg’s realization of a growing problem in mobile communication: the lack of privacy. This insight led him to create Burner, an app that would redefine how people manage phone numbers and safeguard their personal information.

On this episode of Sub Club, Greg shares the journey of how a failed product pivoted into Burner, a mobile privacy tool that has changed the way people manage multiple phone numbers.

Focus on real needs

Unlike many early-stage products that aim to cater to every possible use case, Burner began with a specific purpose: offering a solution for people who need temporary phone numbers for privacy. Greg built the app to address his own frustration with constantly having to hand out his personal number. His approach wasn’t about simply creating a flashy app but solving a real problem that users could immediately relate to.

The simplicity of the idea, combined with a focus on user needs over trends, led to Burner gaining traction quickly. Unlike other apps that try to capture attention through social media or viral loops, Burner grew because it offered something valuable: the ability to separate one’s personal and professional life seamlessly.

Iterate and build trust with your users

Greg didn’t rush to raise funds for Burner. Instead, he let the product speak for itself by offering a free, easy-to-use experience right from the start. As the app gained users, Greg stayed focused on iterating based on feedback and refining the experience. As he improved the app’s features, users began sharing positive experiences, which naturally led more people to download it.

Rather than chase virality, Greg emphasized building trust through product updates and staying user-focused. By keeping core features free and offering premium options as thank-you bonuses, Greg built a loyal user base that valued the app for what it truly offered: privacy and simplicity.

A product built for the long haul

As Burner continued to grow, Greg’s approach to scaling remained grounded. The app’s evolution from a paid download model to a subscription service was a natural step, but Greg didn’t focus on rapid scaling. Instead, he built a sustainable business model that prioritized user retention over short-term profits.

In the face of competitors and an increasingly crowded market, Greg’s primary goal has always been to stay authentic and focused on privacy. As the app expanded, he explored additional features, such as a VPN, to further enhance user security and privacy, demonstrating the company’s unwavering commitment to its core mission.

Conclusion

From a failed app to a highly successful privacy solution, Greg’s story is a lesson in staying true to your vision and listening to your users. For anyone building a product that solves a real-world problem, this episode is a reminder that the key to success isn’t always chasing growth, but delivering consistent, meaningful value.

App-to-web: navigating external purchases in iOS and Android apps

Tue, 09 Dec 2025 14:39:39 GMT

Over the past few years Apple and Google have opened the door for app-to-web, allowing developers to use external purchase flows for in-app subscriptions; making it possible to bypass app store fees and have more flexibility with pricing, promotions, and checkout experiments.

This has largely come about from court rulings like Epic Games v. Apple in the US and the Digital Markets Act in the EU, ultimately forcing Apple and Google to loosen strict requirements around in-app purchases (IAP).

For app teams, this opens up a new realm of app-to-web possibilities — but when it comes to the regulations surrounding app-to-web, it’s not quite so clear cut. New guidelines are constantly appearing and evolving, varying by country and app category, so it’s difficult to keep up with what’s allowed (or not).

To help, we’ve broken down the latest options, eligibility requirements, and commissions/fees for external payments around the world, on both the Apple App Store and Google Play Store. Here’s everything you need to know.

How external purchases with app-to-web work

Here’s a quick overview on how external purchases work, and the two primary ways to incorporate them in your app.

If you want to jump straight to Apple and Google’s purchase guidelines, click here.

1. External web link

Your app includes a link or button that sends the user to an external website (or opens a webview) where the user completes the purchase. The app then unlocks content/features based on that external purchase (usually by syncing with your backend).

Apple refers to this as using an External Purchase Link. For instance, a streaming app might have a “Subscribe on our website” button that opens its web checkout. After payment, the user can log into the app with the new subscription.

2. Third-party payment (in-app)

Your app integrates a non-Apple/non-Google payment gateway directly in the app’s UI. The purchase happens within the app, but not via App Store/Google Play billing. This is sometimes called alternative in-app payment.

A common example is using Stripe for in-app purchases, or showing a country-specific credit card form at checkout in lieu of App Store purchase dialogs.

While this used to be far trickier to implement, Apple v. Epic has meant third-party payments are much easier to use these days. However, Apple and Google have strict rules if you choose either of these paths:

Implementing third-party payment with Apple

You’ll need to request Apple’s special entitlements before offering any kind of external purchase flow
Depending on what you’re building, you’ll use either the External Purchase Link API (to send users to your web checkout) or the External Purchase Entitlement (to run a third-party payment flow inside the app)
Before users leave the app or pay through a non-Apple method, Apple shows a built-in disclosure sheet letting them know the purchase isn’t handled by the App Store
In some cases, if you use an external purchase entitlement, you cannot also offer Apple IAP in the same app in that region — it’s one or the other on a given storefront

Implementing third-party payment with Google

Google’s User Choice Billing means the user is offered a choice between Google Play’s billing and an alternative billing method during checkout
Developers must integrate Google’s alternative billing API to present this option
For External Offers (EEA only), the app can directly link out to a purchase web page (and Google will display a ‘leaving Play’ prompt to users on tap)
Like Apple, there are cases where you’re not allowed to mix standard Google Play Billing IAP with external offers

In-app purchases vs. external purchases: guidelines and regulations for Apple and Google

Most apps on both the Apple App Store and Google Play Store use the platform’s built-in billing system for subscriptions and digital goods. By default, you’re not allowed to direct users to a different payment flow inside your app unless you qualify for (and opt into) one of the external-purchase programs covered below.

For standard in-app purchases, each app store takes a cut. The standard commission for both Apple and Google Play is 30%, but both stores reduce this to 15% for developers making less than $1M/year from IAP. On Google Play, the 15% rate is also applied to recurring subscriptions after the first year.

To avoid these fees, apps are allowed to offer external purchases, as long as they adhere to the following guidelines:

Apple App Store external purchases guidelines

Region/program	Eligible apps	What’s allowed for external payments	Commissions/fees	Notes and references
United States: External Purchase Links	All app categories in the US App Store (including games)	Can include external payment links in-app to a web checkout	0% Standard App Store commission (15–30%) still applies to any purchases made via IAP	App Store Review Guidelines (United States)
EU/EEA: communication and promotion of offers Alternative terms/StoreKit External Purchase Link	All apps on an EU or EEA storefront	External purchases or payments allowed via link-out or third-party processing	If using IAP: 10-17% commission+ 3% payment processing If using external purchases: 2% Initial Acquisition fee + 5-13% (depending on optional store services) + €0.50 Core Technology Fee per first annual install over 1M	Requires opt-in to the Alternative Terms Addendum for Apps in the EU and/or StoreKit External Purchase Link Entitlement for EU storefronts Communication and promotion of offers on the App Store in the EU
EEA: music streaming services entitlement	Music streaming apps	External subscription link or button allowed to your website	Up to ~27% commission (roughly the normal 30% cut minus ~3% payment processing) If you instead opt into the EU Alternative Terms, external purchases are subject to the EU fee stack above (2% + 5–13% + 5% etc.) rather than a flat 27%	Music streaming services entitlement (EEA)
Netherlands: dating apps	Dating apps exclusive to the NL storefront	Alternate in-app payments and/or external link to web purchase are allowed alongside Apple IAP	Normal App Store commission minus 3% (e.g. 27% instead of 30%, 12% instead of 15% for small business/long‑running subs)	Distributing dating apps in the Netherlands
South Korea: StoreKit External Purchase Entitlement	All apps distributed solely on the South Korea App Store using a qualifying third‑party PSP	Alternate in-app payment providers allowed (no Apple IAP required) You cannot also offer IAP in the same SK app	26%	Distributing apps using a third‑party payment provider in South Korea
Global: reader apps (External Link Account Entitlement)	‘Reader’ apps whose primary purpose is providing magazines, newspapers, books, audio, music, or video, and that let users sign in to access previously-purchased content	Can include one link to your website for account creation and management The link must open in a browser Cannot offer IAP in the same app	0%	Distributing reader apps with a link to your website
Japan: Mobile Software Competition Act (MSCA)	All iOS apps on Japan App Store (all categories) with required entitlements	App-to-web purchases via Out-of-App Offers (external links to web checkout) Alternative in-app payments via Alternative Payment Processing (non-Apple PSPs) In-app display of prices and promotions for web purchases Apple IAP and external payment options must coexist and be shown side-by-side	Alternative Payment Processing: 21% (10% reduced cases) Out-of-App Offers (web): 15% (10% reduced cases; applies to renewals) Apple IAP: 21% + 5% payment processing (10% + 5% reduced) Alternative app marketplaces: 5% Core Technology Commission	External payments permitted under MSCA; Apple implements via entitlements, StoreKit APIs, disclosures, parity UI, default-browser links, and age restrictions Read Apple’s announcement here.

Google Play Store external purchases guidelines

Region/program	Eligible apps	What’s allowed for external payments	Commissions/fees	Notes and references
User choice billing: Australia, Brazil, Indonesia, Japan, South Africa, United Kingdom, United States and EEA	Non-game apps in Australia, Brazil, Indonesia, Japan, South Africa, United Kingdom, and United States All apps in EEA, South Korea, India	‘User choice billing’ (UCB): apps can offer users a choice between Google Play’s billing and an alternative in-app billing method	If using IAP: 15% for the first $1M/year in revenue 30% above $1M/year If using external billing system: Normal service fee minus 4% (e.g. 11% instead of 15%, 26% instead of 30%)	User choice billing on Google Play
EEA: alternative billing only (no Google Play Billing in the app)	Apps targeting users in the EEA that want to remove Google Play Billing entirely and use only their own billing in‑app	You complete in‑app transactions through your own (or third‑party) billing system only You are not allowed to offer Google Play Billing as an option in the same app	Standard Google Play service fee minus 3% (e.g. 12% instead of 15%, 27% instead of 30%)	EEA alternative‑billing program
EEA: external Offers Program (link‑out program)	Apps in the EEA that want to promote offers in‑app and send users outside the app (browser, other store, webview) for purchases/subscriptions	You can show in‑app promotional units and hyperlinks (‘linkouts’) that take users to your site or other destinations to purchase digital items or subscriptions	3% Initial Acquisition fee + 10% (required) Tier 1 service fee + 3% / 10% (optional) Tier 2 fee (10% for IAP or +3% for subs) + Variable per-install fees depending on app category	Fees are additive, so a typical Tier‑1 setup is roughly 13% on external sales, while Tier 1+2 can reach the mid‑20% range for some offers Changes to the external offers program for users in the EEA (includes IA %, Tier 1/2 fees, per‑install fee tables)
Japan: Mobile Software Competition Act (MSCA)	All apps distributed on Google Play in Japan (games and non-games), via program enrollment	User Choice Billing (UCB): side-by-side alternative in-app billing expanded to all apps App-to-web purchases via new Google Play link-out program In-app display of prices and promotions for web purchases Google Play Billing and external options may coexist	Google Play Billing: 15% for first $1M/year, 30% above Alternative in-app billing (UCB): standard service fee minus ~4% App-to-web purchases: competitive fees via Google program (rates defined by Google)	MSCA compliance via expanded UCB and new app-to-web program; participation subject to APIs and safety/security requirements Read Google’s announcement here.
United States: External Content Links Program (ECLP)	All apps and games on Google Play serving users in the US (mobile and tablet)	Developers can link users to an external website for in-app digital purchases or app downloads. Can be offered alongside or instead of Google Play Billing. Info screen shown before redirect.	Currently 0% (not yet enforced). Proposed: 10% subs, 20% other digital purchases. First $1M/year at 10%. Downloads: $3.65/install (games), $2.85/install (apps).	Created under Epic v. Google injunction. Enrollment required by Jan 28, 2026. Fees pending settlement ruling. Requires Google’s external links APIs. Enrolling in the external content links program for users in the US

Adding web checkout options to your app

If you’re reading this far, you’re probably already sold on app-to-web. The hard part isn’t why; it’s how to ship it quickly, stay compliant, and not turn your purchase flow into a science project.

RevenueCat Web is the simplest way to add a web checkout to a subscription app. Instead of stitching together a payment processor, entitlement sync, identity mapping, and analytics on your own, you get a full web billing stack that plugs into the RevenueCat setup you already use for mobile. Users can buy on the web and unlock access in iOS or Android right away, with one subscriber record and one source of truth.

Here’s how the pieces fit together:

Web Billing as your billing engine: Web Billing is RevenueCat’s native billing engine for web subscriptions. It manages the subscription lifecycle on the web and stays fully integrated with your RevenueCat products, customers, and entitlements. You don’t have to build or maintain separate web billing logic.

Web checkout surfaces that you can launch in minutes: once Web Billing is on, you can direct users to web checkout in a few different ways:

Web Purchase Button inside your in-app paywall: add a button component to any RevenueCat Paywall; tapping it sends users to a web checkout
Web Purchase Links: RevenueCat-hosted checkout URLs you can drop anywhere, including behind the Web Purchase Button — they work out of the box and support identified or anonymous flows
Web Paywalls shown via the Web SDK: if you have your own web app or landing pages, you can render a RevenueCat Paywall directly on your site through Purchases.js, then complete checkout there

Everything stays connected. The Web overview dashboard shows you everything in one place, and your web and mobile offerings live in the same catalog, entitlements sync automatically, and events flow into the same analytics layer.

How to keep app-to-web conversion strong

Teams usually worry that a web step will convert worse than native checkout. This can be easily avoided by sending users to a web paywall that completes the purchase on the same page (aka, RevenueCat’s Express Purchase button).

If Apple Pay or Google Pay is available in the browser, a wallet button shows on the web paywall. The user taps once, confirms in their wallet, and the purchase completes. RevenueCat then syncs access back to the app automatically.

This keeps the handoff short: paywall in app → paywall on web → wallet confirmation = access unlocked.

Examples of app-to-web

In-app upgrade with a web option: your in-app paywall includes a ‘Continue on web’ button. The web paywall opens with the same plan selected, and a wallet button appears when supported. Users who want a faster checkout finish in one tap.
Win-back discount: a churned user sees a targeted in-app paywall with a comeback offer. The web button routes to a separate web offering with the discount already applied, so the user doesn’t need to hunt for the right plan.
Campaign traffic you can measure: You share a Web Purchase Link in ads or email with UTM parameters intact. After purchase, a redemption step links the subscription to the user’s app account and unlocks access right away. You get clean attribution without custom glue code.

Ready to experiment with app-to-web?

As app-to-web guidelines continue to shift, your success depends on keeping checkouts flexible and compliant. We’ll keep this guide updated as Apple and Google refine their policies, so bookmark it and check back whenever you’re planning your next app-to-web iteration.

Whether you experiment with custom checkout code or get RevenueCat Web to do the heavy lifting, app-to-web can be an efficient and flexible purchase flow. Good luck, and happy testing!

November product updates: A Paywalls special with faster builds, sharper promos, and new proof points

Mon, 08 Dec 2025 12:59:26 GMT

November was a Paywalls month through and through. If Paywalls are a key part of how you grow, you’ve probably felt the same tension we have: keep shipping experiments, keep design quality high, and don’t lose days to handoffs or tiny UI chores.

This release set is about removing friction. You can move designs from Figma to live Paywalls without rebuilding, work faster in the editor, preview across more devices before you publish, and add real urgency to promotions with a Countdown component. We also shipped a new way to share verified performance metrics.

Here’s what’s new.

Export Figma designs straight into Paywalls

Design handoff shouldn’t mean starting over. Now it doesn’t.

You can export Figma mockups directly into the Paywall editor. Your layout comes in as native Paywalls components, so you can immediately:

Edit copy without touching the structure.
Swap products and packages.
Localize text.
Add experiments.
Target specific audiences.

The practical win is speed. Designers stay in Figma, and the team shipping paywall tests can go from “final mock” to “live variant” without recreating the layout by hand.

Import a Figma design ↗

Keyboard shortcuts in the Paywalls editor

When you’re iterating quickly, little clicks add up.

View all shortcuts ↗

Preview your paywall on more devices

A paywall can look perfect on one screen and awkward on another. That used to be something you discovered after publishing.

Now you can preview Paywalls across a wider set of iOS and Android phones and tablets. The canvas updates to real screen sizes, so you can flip through devices in seconds to:

Catch spacing issues early.
Confirm font sizes.
Check crops and media positioning.
Sanity-check scroll behavior.
Make sure your CTA lands where you want it.

It’s a simple change that prevents a lot of last-minute fixes.

Filter paywall templates

Templates are only helpful if you can find the right one quickly.

Start with a template ↗

Countdown component for your paywall

Promos work best when urgency is clear and real.

You can now add a Countdown timer to any Paywall. Set an end date once and the timer updates automatically. No extra code, no manual updates.

This is built for campaigns like Black Friday, launch promos, limited-time discounts, or any offer where timing helps people decide.

Add a Countdown ↗

When you’re talking about growth, proof matters.

You can now publicly share verified performance metrics from your RevenueCat project. You control what’s visible: publish with your project details, or anonymize the profile entirely.

It’s a clean way to back up results for partners, investors, or your community with real numbers pulled directly from RevenueCat.

Share your metrics ↗

If you want to try these updates, everything is live in the dashboard now. Start with the Figma export and device previews if your workflow includes a lot of Paywall design iteration. Add the Countdown component the next time you’re running a time-boxed promo. Each of these is aimed at the same thing: getting high-quality Paywalls live faster, with less friction along the way.

Why more ad channels for your subscription app doesn’t always mean less risk

Fri, 05 Dec 2025 11:09:15 GMT

This article is based on the assumption that most app teams diversify their ad spend because it feels safer. If Meta tanks your CPI overnight, or Google suddenly changes the optimal dimensions for creatives, it’s surely way safer to not be dependent on a single channel. Right?

Well, read on for a breakdown of ad channel diversification’s pros and cons, and what I’ve learnt scaling apps across Meta, TikTok, Google and more — like when channel diversification works (and when it doesn’t), how to make the most of your paid ad budget, and how to anticipate ad channel problems. Along the way, I’ll share real-life examples from my work with small, medium, and large apps.

What is ad channel diversification?

Ad channel diversification is the practice of splitting your paid user acquisition budget across multiple advertising platforms instead of concentrating it on one or two channels.

In other words, it is the practice of not putting all your eggs in one basket. You’re protected from Apple’s latest privacy rule, or Meta’s fickle algorithm, because you have traffic coming from other places. Sounds logical, right?

In reality, and my experience, following this advice can become a double-edged sword that kills your app’s growth and its chances of success.

Many subscription apps hurt ad performance by spreading budgets too thin. Ad channel diversification can be a huge win, but it can also dilute learning, slow optimization, and ad operational overhead. So when should you add new channels? This article aims to answer just that!

The hidden risks of ad channel diversification

Diversification sounds strategic, but the operational drag is real. When you split a budget across multiple channels, you’re also splitting:

Learning-phase velocity: each channel gets too little data to exit creative testing consistently
Creative bandwidth: your team now needs multiple formats, spec variations, and testing roadmaps
Optimization focus: time moves from ‘making what works work better’ to ‘keeping multiple sub-performing channels afloat’

Years ago, I experienced the pain of diversifying ad channels firsthand.

I worked with a subscription app, spending $80k/month exclusively on Meta with a blended return-on-ad-spend (ROAS) of 2.8x. The founder decided to diversify ad channels and split the budget: $40k for Meta, $25k for Google, and $15k for TikTok.

Three months later, the ROAS dropped to 1.9x across all channels. Why? None of the channels had enough budget to exit the creative testing phase consistently.

Creative volume couldn’t keep up with three different formats, and the growth team spent more time in meetings discussing ‘channel strategy’ than actually optimizing ads and user acquisition.
The uncomfortable truth is that diversification feels like risk management, but it’s often just dilution — of resources, insights, and priorities. Without time to analyze creative success and put learnings into action, all we’d done was spread the ad budget too thin and have nothing to show for it.

Signals you’re not ready to diversify ad channels

This list is designed to help you decide whether diversifying your budget is worth it. Think of these as red flags to sense-check your decision, or show someone why more ad channels could be a risk.

1. You don’t have enough bandwidth

Ever heard the phrase “don’t bite off more than you can chew”?

Understand and be conscious that the cost of losing focus is always higher than expected because it’s hard to measure. Teams frequently underestimate how much time disappears into creative resets, weekly channel reviews, and troubleshooting. And the consequences of not being able to say ‘no’ to more channels will only hit harder in the future.

2. You have narrow or niche audience constraints

I once advised an at-home services app that operated in just three cities (specific zip codes). Things started to work when we focused on keyword placements across Apple Ads and Google Ads (search-to-app), and stopped betting on broad targeting and algorithmic channels like Meta Ads and TikTokwith social content. In this case, the territory limitation and high CPM simply wasn’t worth the money.

If you operate in just a few specific areas or target a niche persona, keyword channels may be your best bets. Sometimes your app’s audience is limited; not accounting for that constraint, just because you want to diversify, is a risky move.

3. Your budget can’t sustain multiple channels

Concentrating your budgets is an opportunity, not a restraint. Ignoring that opportunity is a red flag. Spreading your budget too thin means:

More extended periods in the learning phase
Less signals to ad networks to optimize performance
Limited capacity to test ad creatives
Reduced scalability when things start to gain traction

4. You don’t have capacity for ad maintenance

Managing ads and keywords is one of the most tedious and time-consuming tasks for marketers. The minute you add more channels into the mix, you double (or triple, quadruple etc.) the work. So diversification takes much longer than expected, and most of the time, the anticipated performance uplift doesn’t reflect that increase in work, or justify it.

Fewer quality ad channels that you can actually maintain will almost always outperform lots of poorly-maintained channels.

5. You don’t want to tackle ROAS variance across channels

Different channels generate different results (obviously), and juggling all these results, understanding, and predicting them — all simultaneously — is a lot.

Having a clear understanding of your ROAS can be hard to predict for just one channel. For example, users coming from social media may be assigned a different ROAS target than users coming from high-intent keyword searches. That’s all well and good, if you can keep an eye on those differences in behavior, track them over time, and predict what’s coming next.

6. Your reporting and attribution stack isn’t ready

More data sources means more attribution confusion, more measurement problems, and more time spent debugging dashboards than driving results.

Which channels are telling the truth? Which channels are attracting the highest-quality users? Which channels should you prioritize?

If you’re spending less than $100k/month on ads, these are questions you want to avoid. But if you have multiple channels, you’re going to need to answer them. Consider whether the money and potential results compensate for that work.

When does it make sense to diversify your ad channels?

The way I like to approach ad budget diversification is by asking a simple question.

Will new ad channels make me make more money — and can I prove it?

You’re ready to diversify when the answer to each of these follow-on questions is ‘yes’:

Do I have the human capital (time and expertise) needed to make it work?
Do I have enough extra money to allocate to this risky test, without affecting my current user acquisition efforts?
Do I know how I will measure the potential uplift in performance attributed to this new ad channel?

Think about it in these criteria:

You have the people: someone owns experimentation, creative testing, and optimization for the new channel
You have the budget: enough to reach stable delivery without harming your existing winners
You have the measurement: a clear attribution plan for identifying incremental lift (not just last-click noise)

If these aren’t true, diversification usually becomes an expensive distraction rather than a growth lever.

6 Tips for diversifying ad channels

Before we get into some firsthand examples of how to choose and diversify ad channels, here are my top tips for increasing your ad channels. Keep in mind that these come from my own personal experience, so use them as proxies for your decision-making, rather than global rules.

If your budget is under $100k/month, focus on nailing one social platform — I suggest starting with Meta Ads or TikTok Ads
Keyword-based channels like Apple Ads or Google Ads can be operated in parallel with social media channels, but not at scale (especially Apple Ads)
For gaming apps, Applovin is one of the biggest ad channels to start with, but the big con is you need to pay for an MMP to run it
Never use the excuse of channel saturation if you are spending less than $100/month; to be blunt, this is not the reason why your performance sucks
If you’re an indie developer or lack the resources to produce high-quality video content at scale, start with Google Ads’ search-to-app campaigns (you can use tools like Appstack to make it happen quickly and easily)
Diversifying into ad channels that are not Meta, TikTok, Google, Snapchat, X, or Apple may expose you to potential ad fraud at scale — keep your money safe and avoid non-self-attributed networks (non-SAN)

Real-life examples of diversified ad channels

Let’s look at how this works in the real world. The following examples show the actual outcomes of diversifying (or not diversifying) ad spend across different apps and budgets:

1. Bible app

I’ve recently been advising a Christian app that was spending more $500k+/month on Meta Ads. They clearly had the economic resources to hire someone else or test new ad channels, but the main reason they were able to scale to that level was that they nailed Meta Ads first.

The primary way they did this was by optimizing ad network signaling, and leveraging strong testing capacity using the SVS framework.

They also have a strong mindset of focusing on one thing, but doing it better than anyone else. This is an example of the benefits of not diversifying, which saw a startup of 15 people scale to millions in ARR.

2. Fintech app

When working at a fintech company, we had a monthly budget of around $100k/month which then doubled to $200k/month after we saw success expanding into a new ad channel.

The reason this worked for us came from maximizing our existing channel’s success: we deployed the best-performing video ads from Meta Ads into TikTok Ads, and it resulted in significant numbers (positive ROAS).

Luckily, I had the resources to get enough time and allocation to test the new TikTok channel, so it wasn’t a huge risk. But this is one tactic for exploring a new channel without putting everything on the line. I call it a soft diversification test, limiting time and scope to a duplication strategy of your best-performing content, simply added to a new channel. Of course typically the best-performing content will be unique to each channel, but it’s a good proof of concept.

3. Photo and video app

Finally, I’ve recently consulted one of the biggest photo and video apps in the world (sorry, I can’t share the name!), who spend more than $3m/month. They’re highly diversified in channel, meaning even the biggest ad channels like Meta Ads and Google Ads only use 30% of their ad spend.

The reason it’s working for them is simple. Scale. They have the budget to have specialized people in each channel, with almost unlimited funds to test and scale as needed. This is obviously not always the case, and it’s a prime example of how much resource you need to expand without risk.

However, the flip side of this case is that the wider user acquisition function was pretty inefficient: ROAS was higher than reported, people weren’t working that hard, and they had serious measurement issues to determine what was actually moving the needle. Despite huge budgets, there were still issues under the surface.

So, should you invest in new ad channels?

The correct answer to your question: “Should I diversify my marketing budget allocation?” will always be simple: it depends.

I know, it’s annoying. But it’s true. And if someone tells you the opposite, doubt them.

To move from ‘it depends’ to a straightforward yes/no, keep these takeaways in mind:

Depth beats width below $100k/month: if you’re spending less than $100k/month, master one channel before adding another. Deep optimization on Meta or TikTok will outperform shallow testing across multiple platforms.
Use the three-question test: before diversifying, ask: Do I have the people? Do I have the budget? Do I know how to measure it? Three ‘yes’ answers mean go. Anything else means wait.
Creative production is the hidden bottleneck: three channels mean three different video specs, three sets of copy guidelines, and three times the creative refresh cycles. Most teams can’t keep up.
Attribution gets messy fast: each new channel adds another layer of measurement complexity. If you can’t clearly answer “Which channel drove this subscriber?”, then you’re not ready to add another one.
Context-switching kills performance: a growth marketer splitting time across four dashboards will always lose to one marketer entirely focused on a single platform. Optimization requires deep immersion, not surface-level monitoring.
Kill fast when channels don’t work: after 90 days, if ROAS is below your primary channel or the team is burning 20+ hours/week for less than x% of revenue, pull the plug and reallocate.
Perceived saturation isn’t absolute saturation: if you haven’t tested 100+ creatives/month (at least), exhausted all audience segments, and spent at least six months optimizing, you haven’t hit saturation; you’ve hit a skill ceiling.

So, that’s my whirlwind guide to diversifying your ad channels. I hope it helped guide your decision, and if in doubt, ask yourself those three questions. It’s helped me stay on track more times than I can count.

Context wins: the hidden third dimension of paywall targeting

Thu, 04 Dec 2025 13:38:51 GMT

When setting up your paywall targeting, how do you segment your audience? Naturally, you probably think about who the user is, and what they’re doing before they hit that paywall. But there’s another layer that influences whether they click ‘subscribe’: context.

Demographics say who, behavior says what, but context decides when. A user on the move vs. on the couch has radically different intent when faced with a Runna paywall.

Context is a combination of timing, motion and mentality. It’s about when a user is ready to commit. That timing shapes intent dramatically; the same person can feel ‘not now’ in one moment and ‘I’m ready’ a minute later, all depending on the context.

In a world where attention is shifting constantly, and 82% of trials start on day zero, showing the right message at the wrong moment may be the biggest leak in your funnel.

Learn how to trigger paywalls in those precious milliseconds when attention and intent peaks, and you can turn ‘not now’ into ‘subscribe’.

The cost of mistimed paywalls and the limitations of traditional paywall optimization

Every day, millions of users encounter paywalls at the wrong moment. They’re rushing to catch a train, trying to focus in a noisy environment or simply not in the right headspace to evaluate a subscription. The result? Frustration, negative reviews and lost revenue (that most apps never measure).

That friction pushes people out of the funnel.

To iron out that friction, you probably look to paywall optimization. Typically, paywall optimization means demographic filters, simple behavioral triggers and lots of A/B tests. But this 2018 playbook isn’t working anymore — the State of Subscription Apps report 2025 reveals some striking gaps between average apps and top performers:

Metric	Median apps	Top-performing apps
Download-to-paid within 35 days	1.9%	4.6%
Trial-to-paid conversion rate	34.8%	51.5%

Much of that gap comes down to when the paywall appears. Traditional optimization treats all day zero users identically; whether they’re commuting to work, lying in bed or sitting in a coffee shop. It’s ignoring the when.

So how do you serve users paywalls at the right time? Contextual targeting.

While paywall targeting allows you to customize your paywall and offerings to specific segments, adding context lets you also customize to the users’ circumstance, surroundings, and behavior.

A third dimension for targeting: the user’s context

Traditional paywall optimization relies on roughly five-10 data points, like time-since-install, features accessed, demographic info and basic usage patterns. This data barely scratches the surface of who your user is, what their life is like and how they interact with your app. You need context.

Your smartphone generates over 300 contextual signals every second: motion data, how the user holds their phone, battery level, ambient light, connectivity status and dozens more.

While human analysts can meaningfully process maybe three–four variables simultaneously when making targeting decisions, machine learning models can analyze all 300+ signals in real-time to identify the optimal moment for paywall display. Of course, context-aware machine learning doesn’t replace human intuition — it simply amplifies it, with real-time data that humans can’t process at the same scale.

These additional context signals don’t replace demographic and behavioral targeting; they add a third dimension that can significantly enhance targeting effectiveness. A 25-year-old professional might be your ideal customer demographic, but their conversion likelihood varies dramatically based on whether they’re walking to a meeting whilst on a business call and 5% battery, or relaxing on the couch scrolling TikTok with their phone plugged in.

Mobile gaming makes the impact of contextual targeting visible: immersion is fragile, time is valuable, and heavy-handed offers break flow. But by timing prompts to natural pauses, you can harness users’ engagement and meet them in context. One example is indie puzzle game Blackbox, who recorded a 50% revenue increase during peak periods and a sustained conversion lift over subsequent months — gains achieved by changing when paywalls appeared, not what they said.

9 strategic moves to improve paywall targeting (by role)

Timing of your paywall influences downstream metrics like refunds and early churn. The performance gap between top apps (4.6% download-to-paid) and the median (1.9%) is not only about pricing or features, it’s about whether the prompt arrives when a user is receptive. Used carefully, contextual timing can improve conversion and user satisfaction — the intent is not to show more paywalls, but to show them at better moments.

Contextual targeting strategies for growth teams

Growth teams live in a world of competing priorities: hit this quarter’s numbers, optimize long-term LTV, reduce CAC payback period and still find time to run meaningful experiments. Context-aware timing helps by improving the efficiency of the monetization funnel.

1. Rethink A/B testing: make timing the variable

A/B tests on paywall placement take weeks, and often miss the real driver of lift. Shift focus to when the prompt appears. Run smaller, parallel experiments across moments and segments, keep a true control, and judge outcomes on cohort LTV, refunds and early churn, not just day zero conversion.

2. Choose the right plan for the moment

The State of Subscription Apps report 2025 shows one-year retention differs by plan type (about 44.1% annual vs. 17.0% monthly vs. 3.4% weekly). Why not match which plan users are served to their context?

In high-consideration contexts such as stationary, longer evening sessions with deeper engagement, present annual plans or even lifetime subscriptions. In brief, in-motion sessions, surface shorter options like weekly or monthly. Validate the mix with retention and refund behavior rather than first conversion alone.

3. Hold back to capture more

This might seem counterintuitive, but one of the most powerful moves a growth team can make is holding back monetization prompts. For example, Dating app Wizz found that cutting prompt volume by roughly 50%, while timing offers to receptive contexts, ended with an 81% lift on the primary offer flow.

The lesson is simple: suppress in low-intent states and reallocate to moments instead of increasing total exposures. Users will feel less interrupted and more in control, and cohorts in the experiment above reflected it, with LTV up by roughly 20%.

Contextual targeting strategies for product managers

Product managers own the whole experience. Every monetization choice trades off exploration versus interruption. Treat timing as part of the product, not just a rule, so you can protect flow and still capture intent.

4. Make timing part of the UX

The best product experiences feel like they’re reading your mind; surfacing exactly what you need, exactly when you need it.

Instead of a single gate, context-aware apps let access and prompts adapt to the moment. One example could be a fitness app recognizing the difference between someone lying in bed in the evening versus someone on a jog. In the stationary moment, show a full upgrade view with plan details. In motion, allow the workout with a light ‘upgrade to save x%’ nudge. Same feature, different timing, less friction.

5. Progressive disclosure that respects context

Surface decisions when users have the attention to make them. Hold back in obvious low-consideration states (in Apple’s driving focus, during phone calls, or while abroad etc.) and follow up when the session lengthens, motion drops, or engagement deepens. You’re not showing fewer opportunities; you’re placing them where they fit.

6. Design for ‘it gets me’ moments

The holy grail of product experience is creating moments where users think “This app just gets me”. These moments build loyalty, drive word-of-mouth, and increase lifetime value. For example, a meditation app that offers a five minute session at 7am during their morning routine, and a sleep track at 10pm when the user lies in bed, feels tuned to the user’s life. Like it just fits.

But time is only one signal: combine session depth, motion, battery and connectivity to decide when to ask and what to ask for. Over time, these small, well-timed choices build trust and make upgrade prompts feel like part of the experience rather than interruptions.

Contextual targeting strategies for tech leadership

Engineering leaders don’t just ask “Does this work?”, they ask “Is it reliable, can it scale and can we maintain it?”.

Context-aware targeting adds real value, but remember to evaluate new capabilities through multiple lenses: implementation complexity, maintenance burden, scalability, privacy implications and strategic alignment.

7. Use existing device signals and minimize prompts

Many useful signals are available via standard APIs without new permission prompts: time of day, battery level, device orientation, network type, screen state.

Where a platform does require consent for certain motion or fitness data, respect that boundary and degrade gracefully. You can get meaningful context without expanding your permissions surface.

8. On-device inference for latency, cost and reliability

Running models on-device with Core ML or ML Kit keeps decisions close to the user. Latency drops to milliseconds, so timing can adapt within a session. Server costs are lower because phones do the work rather than a central service. Reliability improves because decisions do not depend on a network round trip and continue to work on WiFi, cellular or offline.

9. Decouple releases from experiments

Shipping timing changes through app releases create a bottleneck: engineering implementation, QA, review, store approval and adoption can turn a simple test into weeks.

Use remote configuration or paywall management to ship timing rules and model updates over-the-air, with rollback if metrics dip. This way underperforming models can be detected and corrected within 24 hours, without an app update. The effect is practical: product teams keep building core features, while monetization experiments iterate safely in configuration.

Beyond intuition: context is standard

The traditional approach of manual paywall optimization has reached its performance ceiling. When even the best-performing apps convert less than 5% of downloads to paid users, there’s enormous room for improvement — contextual intelligence could be the solution.

35% of apps now mix subscriptions with consumables and lifetime purchases, and AI apps already outperform other categories. The future of apps is hyper-personalization, and the trajectory for paywall targeting is clear:

2020–2022: Basic A/B testing of paywall copy and placement
2023–2025: Behavioral and demographic targeting
2026+: Real-time, contextual optimization via machine learning

As hyper-personalization becomes standard, the success of paywall optimization shifts from what you show to when you show it. In a crowded mobile environment where sessions are short and acquisition costs are high, timing your paywall to match user intent matters more than tweaking the design or copy.

Google Play’s subscription with Add-ons: guide to multi-line subscriptions

Thu, 04 Dec 2025 00:17:43 GMT

Subscription monetization on Android has evolved significantly over the years. With the introduction of base plans and offers in 2022, Google gave developers more flexibility in structuring their subscription products. Now, Google has taken another major step forward with Subscription with Add-ons, also known as multi-line subscriptions or multi-product checkout for subscriptions. This feature allows developers to bundle multiple subscription products together into a single purchase, creating a more streamlined experience for both users and developers.

Read on to explore what multi-line subscriptions are, discuss practical strategies for using them effectively, walk through the implementation details using the Play Billing Library directly, and finally examine how RevenueCat can simplify the entire process.

What are multi-line subscriptions?

At its core, Subscription with Add-ons is a feature that lets you bundle multiple subscription products together so they can be purchased, billed, and managed as a unified subscription. Rather than requiring users to make separate purchases for a base subscription and additional premium features, you can now offer everything in a single checkout flow.

Consider a music streaming application that offers a base ‘Premium’ subscription. Previously, if you wanted to offer additional features like ‘HiFi Audio’ or ‘Offline Downloads’ as separate paid add-ons, users would need to purchase and manage each subscription independently. This meant multiple transactions, multiple renewal dates, and multiple entries in their subscription management screen. With Subscription with Add-ons, users can select the base Premium plan along with any combination of add-ons and complete a single purchase. They see one combined price, go through one checkout flow, and have everything synchronized to a single renewal date.

The terminology can be a bit confusing at first. Google uses ‘Subscription with Add-ons’ as the official feature name, but you might also see it referred to as ‘multi-line subscriptions’ (referring to the multiple line items in a single purchase) or ‘multi-product checkout’ (emphasizing the checkout experience). These all refer to the same capability.

How the bundle works

When a user purchases a Subscription with Add-ons, the first item in the product list becomes the base item, and all subsequent items are treated as add-ons. This distinction is important because the base item determines certain behaviors for the entire bundle. For example, when the base subscription is canceled, all associated add-ons are automatically canceled as well. The add-ons cannot exist independently of the base subscription.

Google Play handles the complexity of aligning billing cycles automatically. When a user adds a new add-on to an existing subscription, Google Play calculates a prorated charge to align the add-on’s renewal date with the base item. This means that after the initial prorated period, all items in the bundle renew together on the same date. Similarly, if a user removes an add-on, it continues to provide access until the end of its current billing period but will not renew.

Key constraints to understand

Before diving into implementation, there are several important constraints that shape how you can use this feature.

All items in a Subscription with Add-ons must have the same billing period. You cannot combine an annual base subscription with monthly add-ons, or vice versa. If your base plan bills monthly, all add-ons must also bill monthly. This constraint exists because Google Play needs to synchronize renewal dates across all items.
This feature is only available for auto-renewing subscriptions. Prepaid subscriptions, which have a fixed duration and do not automatically renew, cannot be used as the base item or as add-ons.
There’s a maximum limit of 50 items in a single Subscription with Add-ons purchase. While most applications will never approach this limit, it is worth knowing if you are building a highly modular subscription system.
This feature isn’t available in all regions. As of the current documentation, India and South Korea don’t support Subscription with Add-ons. You will need to provide alternative purchase flows for users in these regions.
Finally, pausing and resuming subscriptions is not supported for subscriptions that have add-ons. If your application relies heavily on the pause feature, you will need to consider whether the benefits of add-ons outweigh this limitation.

Strategies for using multi-line subscriptions

Understanding the mechanics is one thing, but knowing how to apply this feature effectively requires thinking through your monetization strategy. Let me share several approaches that can help you maximize the value of Subscription with Add-ons.

The modular feature strategy

One of the most straightforward applications is offering a modular subscription where users can customize their plan by selecting only the features they need. Instead of creating multiple pre-defined tiers (Basic, Standard, Premium), you create a base subscription and a menu of add-ons that users can mix and match.

For example, a productivity application might offer a base subscription that includes core features like task management and basic collaboration. Add-ons could include advanced reporting, team management features, third-party integrations, or increased storage. Users who only need advanced reporting can add just that feature, while power users can add multiple add-ons. This approach can increase conversion rates because users feel they are paying only for what they actually need.

The key to making this strategy work is ensuring your base subscription provides genuine value on its own. If the base feels stripped down or incomplete, users may perceive the add-ons as nickel-and-diming rather than genuine flexibility.

The premium upgrade strategy

Another approach uses add-ons as a path to gradually upgrade users over time. You start users on a base subscription and then offer add-ons as upsells based on their usage patterns or at strategic moments in their journey.

Consider a photo editing application where the base subscription includes standard editing tools. As users become more engaged, you can offer add-ons like professional presets, advanced retouching tools, or cloud storage for their edited photos. The advantage of using add-ons rather than a traditional tier upgrade is that users keep their existing features and simply add new capabilities. There is no perception of ‘losing’ their current plan.

This strategy works particularly well when combined with personalized recommendations. By analyzing user behavior, you can surface relevant add-ons at moments when users are most likely to see value in them.

The bundle and save strategy

While Subscription with Add-ons allows individual selection of features, you can also use it to create attractive bundles. By setting prices strategically, you can make bundles of add-ons more appealing than purchasing items individually.

For instance, if your base subscription is $9.99/month and you have three add-ons each priced at $4.99/month, you might offer all three add-ons as a bundle for $11.99/month instead of $14.97/month if purchased separately. Users who want multiple features get a better deal, and you increase your average revenue per user. The bundled price still provides more revenue than users who might only purchase one add-on.

Managing complexity

One risk with add-ons is creating too much complexity. If users face a bewildering array of options, they may experience decision paralysis and abandon the purchase entirely. Consider limiting the number of add-ons to a manageable set, typically three to five options. Provide clear descriptions of what each add-on includes and who it is best suited for. You might also consider offering recommended bundles or a ‘select all’ option for users who want the complete experience.

Implementing Subscription with Add-ons without RevenueCat

Let us walk through how to implement Subscription with Add-ons using the Google Play Billing Library directly. This implementation requires Play Billing Library v5 or higher, though you should use the latest version (currently v8) to ensure access to all features and security updates.

Setting up your products in Google Play Console

Before writing any code, you need to configure your subscription products in the Google Play Console. The good news is that existing subscription products can be offered as add-ons without any special configuration. You do not need to create separate ‘add-on’ type products. Any auto-renewing subscription can serve as either a base item or an add-on.

When creating your products, remember that all items you plan to bundle together must have matching billing periods. If you want to offer both monthly and annual options, you will need to create separate base plans for each billing period.

Querying product details

The first step in your implementation is querying the available products from Google Play. You use the queryProductDetailsAsync method to fetch details for all the subscription products you want to offer.

The query returns ProductDetails objects for each subscription product. These objects contain all the information you need to display pricing to users and to launch the purchase flow, including the available base plans, offers, and their associated offer tokens.

Launching the purchase flow with multiple items

When a user selects their desired subscription configuration (base plus selected add-ons), you launch the billing flow with multiple ProductDetailsParams objects. The critical detail here is that the first item in the list becomes the base item, so you must ensure your base subscription is added first.

Each item in the list must be unique. You cannot include two ProductDetailsParams objects with the same product ID. The offer token specifies which base plan or offer to use for that item, and you must provide a valid offer token obtained from the ProductDetails.subscriptionOfferDetails() method.

Processing the purchase

After the user completes the purchase flow, your PurchasesUpdatedListener receives the result. Processing a Subscription with Add-ons is similar to processing a single subscription, with one key difference: the purchase grants entitlements for multiple items.

The purchase.products property returns a list of all product IDs included in the purchase. You should grant entitlements for each product and verify the purchase with your backend server before doing so.

Modifying an existing Subscription with Add-ons

Users may want to add more add-ons to their existing subscription or remove some they no longer need. When modifying an existing Subscription with Add-ons, you need to include the current purchase token and specify a replacement mode.

When modifying a subscription, you must include all items that should remain active after the modification. If you want to keep the base subscription and an existing add-on while adding a new add-on, all three must be in the product list. If you omit an existing add-on from the list, it will be removed.

The replacement mode determines how Google Play handles the billing transition. CHARGE_PRORATED_PRICE calculates a prorated charge for new items to align their renewal with the base subscription. Other modes like CHARGE_FULL_PRICE or WITHOUT_PRORATION are available depending on your use case.

Server-side verification and real-time notifications

For production applications, you must verify purchases on your backend server and handle Real-Time Developer Notifications (RTDN) to keep your entitlement records synchronized with Google Play.

One important detail for Subscription with Add-ons: the subscriptionId field is not provided in RTDN messages for multi-item purchases because there are multiple subscriptions involved. Instead, you should use the purchaseToken from the notification to query the Google Play Developer API and retrieve the full list of entitled items.

The lineItems list in the API response contains details for each subscription item, including its product ID, expiration time, and renewal status. This allows you to track entitlements for each component of the subscription bundle independently.

Handling edge cases

Several edge cases require special attention when implementing Subscription with Add-ons.

Grace periods and account holds apply to the entire subscription bundle. If a renewal payment fails, all items enter the recovery period together, regardless of which specific items were involved in the failed renewal. The grace period duration is determined by the item with the minimum grace period setting among all active items.

Refunds and revocation, interestingly, can be handled at the item level. Using the Google Play Developer API, you can revoke individual items without affecting the entire subscription. This is useful if a user requests a refund for a specific add-on while wanting to keep their base subscription.

Price changes follow similar rules as single-item subscriptions, but with additional complexity when multiple items have pending price increases. All outstanding opt-in price increases must result in the same renewal time with the new price. If an item has a pending opt-in price increase that the user has not confirmed, new price increases for other items in the bundle may be ignored unless they align.

Simplifying Implementation with RevenueCat

While implementing Subscription with Add-ons directly with the Play Billing Library gives you complete control, it also requires managing significant complexity, and time resources (this is a thing) as well. You need to handle billing client lifecycle, query caching, purchase verification, entitlement management, real-time notifications, and all the edge cases we discussed. This is where RevenueCat provides substantial value.

RevenueCat abstracts away the complexities of the Play Billing Library and provides a unified API for managing subscriptions across platforms. For Subscription with Add-ons specifically, RevenueCat handles the intricacies of multi-item purchases, entitlement tracking, and server-side verification automatically.

Configuring Products in RevenueCat

In RevenueCat, you configure your subscription products in the dashboard by creating Products and organizing them into Offerings. Each Google Play subscription product ID maps to a RevenueCat Product, and you can group related products into Offerings that represent your subscription tiers or bundles.

For Subscription with Add-ons, you would create separate products for your base subscription and each add-on. RevenueCat’s entitlement system then allows you to map these products to specific features in your app. When a user makes a purchase, RevenueCat automatically tracks which entitlements they have based on their active subscriptions.

Simplified Purchase Flow

With RevenueCat, launching a purchase and handling the result is significantly simpler. The SDK manages the billing client connection, purchase verification, and entitlement updates.

That’s all! Sounds easy? RevenueCat’s CustomerInfo object provides a real-time view of the user’s active entitlements across all their purchases. You do not need to manually track which products map to which features or handle the complexity of multi-item purchases. The SDK and RevenueCat’s backend handle purchase verification, receipt validation, and entitlement calculation automatically.

Cross-platform consistency

One of RevenueCat’s strongest advantages is providing a consistent API across Android, iOS, and other platforms. If your application is available on multiple platforms, RevenueCat ensures that users have a unified subscription experience. A user who subscribes on Android and later switches to iOS will have their entitlements recognized automatically.

Analytics and Insights

RevenueCat’s dashboard provides detailed analytics about your subscription performance, including metrics specific to subscription bundles. You can track which add-on combinations are most popular, monitor conversion rates for different offerings, and identify opportunities to optimize your pricing strategy.

Webhooks and server integration

For applications that need server-side awareness of subscription status, RevenueCat provides webhooks that notify your server of subscription events. These webhooks are simpler to work with than Google Play’s RTDN because RevenueCat normalizes the data and handles the complexity of multi-item purchases.For detailed implementation guidance, refer to the RevenueCat documentation for Google Play products and the subscription management guide.

Wrapping up

Subscription with add-ons gives us values in how Android developers can structure their subscription offerings. By enabling multi-item purchases with synchronized billing, Google has opened new possibilities for flexible, user-friendly monetization strategies. Whether you choose to offer modular subscriptions where users customize their plan, use add-ons as an upgrade path for engaged users, or create attractive bundles that increase average revenue per user, this feature provides the tools to implement your vision.

Implementing this feature directly with the Play Billing Library requires careful attention to product configuration, purchase flow management, and edge case handling. The code examples in this article provide a foundation, but production implementations will need additional error handling, retry logic, and thorough testing.

For teams that want to move faster or need cross-platform support, RevenueCat offers a compelling alternative that abstracts away much of this complexity while providing additional benefits like unified analytics and simplified server integration.

As you plan your implementation, start by clearly defining your monetization strategy. Understand which features should be in your base subscription versus add-ons, ensure your billing periods align, and consider how you will communicate the value of each option to users. With thoughtful planning and solid implementation, Subscription with Add-ons can help you create a subscription experience that serves both your users and your business goals.For the complete official documentation on this feature, visit the Android Developers guide for Subscription with Add-ons, and RevenueCat Offerings.

How Shotsy became the go-to app for GLP-1 tracking

Wed, 03 Dec 2025 14:05:28 GMT

Before building one of the most trusted tools for people on GLP-1 medications, Aja Beckett was navigating a string of indie app experiments. Each had promise, but none found traction until she started building for herself. As she began taking GLP-1s, the need for a better tracking tool became impossible to ignore.

On this episode of Launched, Aja shares how a personal need sparked a product that quickly became a movement within one of the fastest-growing health categories on the App Store.

Authenticity before anything else

Unlike past projects, Shotsy didn’t chase trends or solve a generic need. Aja built the app as a direct response to her own health experience, which meant she understood what mattered. Tracking doses, navigating side effects, and making better decisions with her doctor were non-negotiables. “All the important stuff is free,” she says, reflecting a values-first approach that still drives the roadmap.

The result was a product that users shared, screenshotted, and asked for by name. And so, there was an apparent demand.

Start small, stay smart

Even before launch, traction showed up in the form of spreadsheet threads, subreddit buzz, and beta testers who filled up in minutes. Instead of raising money right away or launching everywhere at once, Aja focused on building what people needed most. That included refining her ASO strategy, staying focused on App Store search, and delivering value from day one.

Her seventh app, Shotsy, became the one that stuck, not because it was the flashiest but because it met people exactly where they were. Users weren’t looking for a “weight loss app.”

They were seeking support for a profoundly personal journey.

Building trust, not virality

Aja didn’t set out to build a social loop, but her users made one anyway. Screenshots of Shotsy’s colorful charts began showing up across communities, sparking word-of-mouth growth. She hasn’t spent a dollar on ads. Instead, she’s reinvested in features that help users feel supported and stay consistent. “You can use it for free forever,” she explains, with premium features designed more as thank-you bonuses than locked essentials.

Later, Aja raised a small pre-seed round to protect what she’d already built. As competitors emerged, her goal was to keep the most trusted app in the hands of those who needed it most.

Conclusion

From a solo side project to a breakout health product, Shotsy’s story is a masterclass in building with empathy. If you’re working on something personal, this episode is a reminder of what can happen when you listen closely, stay real, and let your users lead the way.

UGC ads aren’t dead, they just evolved (and your app’s LTV depends on it)

Tue, 02 Dec 2025 14:34:09 GMT

Old-school user-generated content (UGC) just isn’t hitting like it used to. Those scripted testimonials, faux-enthusiasm demos and influencer ads that used to do wonders for referrals? Users now see right through them. But what’s replacing them isn’t some glossy brand campaign; it’s a new wave of performance creative that actually feels authentic.

I’m talking UGC-style performance creative: content that actually fits into people’s feeds, entertains or teaches first, and builds real trust.

Apps that nail this UGC-style approach aren’t just getting clicks, they’re building a trusting community that compounds results: lower acquisition costs, better subscribers, and way longer retention.

When ‘authentic’ UGC stopped working

In the last year, many subscription apps saw their ‘authentic’ testimonials tank. Those ring-light videos with polished lines that used to crush? We watched as cost-per-trial skyrocketed, and trial-to-paid conversions fell off a cliff. Formats that absolutely killed it in 2020–2021 were now destroying unit economics. So what’s changed?

When UGC first blew up around 2019, it worked because it felt different: shaky iPhone footage, unscripted testimonials, real experiences. It was raw and caught you off guard. But success breeds copycats. Pretty soon, the testimonial format became a formula:

Ring-light testimonials: “I literally can’t live without this app”
Robotic feature walkthroughs with forced enthusiasm
Influencers clearly reading off a script

The data tells the story: AppsFlyer’s 2025 Creative Optimization Report analyzed 1.1 million creative variations across $2.4B in ad spend, and found a massive gap between what gets funded and what actually performs.

For example, when advertising for social media apps, creatives like tutorials and app reviews generate 45% higher IPM (installs per thousand impressions) and 17% better day seven retention compared to testimonials, yet testimonials still capture the majority of budgets.

Why the disconnect? Because most teams are still funding yesterday’s playbook. Testimonials are familiar, easy to produce, and historically worked. But user behavior has shifted, and creative fatigue is real. Today, they see right through those testimonials.

People learned to scroll right past, conversions dropped, churn spiked, and the impact on our metrics was brutal. This version of UGC wasn’t just ineffective, it was actively killing our unit economics.

The shift from ‘fake UGC’ to authenticity

The smartest growth teams didn’t ditch UGC altogether. They asked a better question:

What if the problem isn’t user-generated content itself, but content that FEELS generated (staged, formulaic, lifeless) instead of genuinely useful?

That’s what led us to focus on UGC-style performance creative. This approach prioritizes value for users first, and selling second. It’s simple: if users feel like they’re being sold to, they scroll. If they see genuinely useful or interesting content that features an app, they click. Our UGC-style creative doesn’t announce itself as an ad. It blends into the feed, entertains, educates, or surprises, while naturally showing what the product does.

Old UGC = interruption marketing disguised as authenticity
Our approach = value-first content that earns attention

Think of it like the difference between a jingle you skip and a Netflix scene you actually want to rewatch.

Why this economic model compounds

Old UGC optimized for one metric: the click. This new approach optimizes for the entire journey, creating two compounding loops:

1. The paid performance loop (how views convert to LTV)

This starts by earning the view. An ad that feels authentic and adds value isn’t skipped. This builds trust before the click, leading to a higher-quality click and better install conversion on the App Store.

This immediately lowers the cost-per-trial/customer acquisition cost (CAC). And because the ad set clear expectations, the user sticks around, leading directly to higher trial-to-paid conversion and longer-term retention and lifetime value (LTV).

2. The organic trust loop (‘non-paid’ value)

When the content is genuinely good (by being entertaining or educational), it also gets organic shares, saves, and comments. This builds social proof and brand trust at no extra cost. This organic loop then feeds back into the paid loop, making all our ads perform better and lowering our blended CAC even further.

In short, the economics improve across the entire funnel, not just at the top.

When old (aka formulaic) UGC still works

Traditional testimonial-style UGC isn’t completely dead. Users don’t have creator fatigue, they have format fatigue. The perfectly-filmed, polished editing, scripted-with-keywords format can still work when that format is what conveys most value to the user.

This format can still work for:

Utility apps with instant value (parking, weather)
Emerging categories where education isn’t needed yet
Viral features that genuinely surprise users

But honestly? These cases are getting rare. For most subscription apps, this new, authentic approach is now table stakes.

Four performance formats that actually move metrics

So, we know outdated UGC isn’t converting. But what does this new UGC-style performance creative actually look like?

Well, from thousands of creatives tested across subscription apps in 2023–2025, these are the formats we’ve found that consistently outperform traditional testimonials. What do they have in common? They educate, entertain, or build curiosity first, rather than just saying “trust me, this app is great”.

1: Expert commentary: the ‘podcast clip’

For apps that require trust or behavior change, this format mimics a ‘hot take’ from a podcast. It feels like high-value advice, not a sales pitch.

Example: Jumpspeak, a language learning app
Creative: Visually, it looks exactly like a clip from a high-production podcast (mics, studio lighting, multiple angles). An authoritative ‘expert’ guest argues that popular language learning apps are just ‘passive learning’ that make you feel productive but fail in real life situations.
The pitch: The ‘expert’ anchors the value of Jumpspeak against a $60/hour private tutor, and positions it as a scientifically-backed alternative, stating: “Immersion activates 85% more neural pathways”.
Why it works: It appeals to logic and authority. By citing the National Training Labs and using specific stats, it bypasses the user’s ‘sales filter’ and builds trust.

Source: Jumpspeak Meta Ads Library

2: Scenario-based skits: sell problems, not features

Instead of stiff testimonials, skits dramatize relatable struggles and show the app as the natural solution.

Example: Mojo, a video editing app
The creative: It dramatizes the frustration of slow, manual editing software, then uses a second character to mock this old way before revealing the app’s ‘Auto Edit’ feature as the magical solution.
Why it works: People don’t buy features. They buy scenarios they recognize themselves in and the emotion that comes with a solved problem.

3: Viral surprise: the ‘pattern interrupt’

This format relies on a plot twist. It starts as a piece of viral entertainment (a fight, a public moment, a POV) and surprises the viewer by pivoting into the product.

Example: Muzz, a Muslim dating app
The creative: A POV-style video with subtitles: ‘POV: A hijabi hit your car’. It opens with high tension: a man getting out of his car after an accident to confront another driver (the POV), before starting to flirt with her, attempting to turn the car crash into a meet-cute. She shuts him down, but…
The twist: The person recording breaks the tension by saying, “Listen, if you want to get married so bad, just download Muzz”, then dropping social proof: “more than 600k couples met on Muzz”.
Why it works: It captures attention and catches the viewer off guard. They watch because they want to see the outcome of the car crash (the drama), then the brand message arrives as a plot twist rather than a sales pitch.

Source: Muzz Meta Ads Library

4: Street interview: the credibility hook

This format isn’t just about ‘asking strangers questions’, it’s about confrontation. It creates a micro-moment of truth where the participant (and the viewer) admits to a struggle, creating the perfect opening for the product.

Example: Gronda, a cooking app
The creative: The interviewer approaches strangers with a simple challenge: “Rate your cooking level from 1 to 10”. Interviewees admit the truth, one girl says “3”, another admits he’s a “toast chef”. This builds instant relatability.
The pitch: The interviewer doesn’t just talk about the app; he shows the phone screen with Gronda’s masterclass in plating. We see the interviewees go from self-doubting to impressed: “Wait, that makes it look so easy”.
Why it works: It capitalizes on relatability, social proof, and anchors the viewer in their current state (bad cook) then uses the app to bridge the gap to their desired state (pro chef). It validates the viewer’s insecurity and immediately solves it.

Which creative format should you use for each platform?

Which format you go for depends on the social channel you’re using. AppsFlyer’s report emphasizes the need to diversify creatives per media type, as the same creative concept can deliver completely different results depending on the media type.

My rule of thumb is that the more your content feels like it belongs, the better it performs. Look at what content does well on the platform you want to target, and go for that. If in doubt, these are my general suggestions:

TikTok and Instagram Reels: skits dominate – hook in three seconds or less, and use humor and relatability to win
YouTube Shorts: expert commentary performs best – longer clips, higher intent
Facebook and Instagram feed: focus on discovery and post captions; carousels showing processes also work well
LinkedIn: process documentation thrives, posts about productivity hacks feel natural in this space

This also means that trying to re-use the same creative across different platforms is a recipe for failure. Each platform demands its own native format. Pick one platform, invest in creative testing, and focus on nailing that channel before you expand.

6-Point checklist for authentic performance

It’s all too easy to get ahead of yourself and click ‘publish’, but bad UGC can do more harm than no UGC. Before you launch, test every creative against this checklist:

App-channel fit: does your app’s core purpose (e.g. a wedding app) naturally fit the platform’s audience (e.g. Pinterest)?
Platform-native format: does the video itself feel native to the platform, or does it feel like an ad?
Authentic voice: does the creator sound believable?
Trust building: does it educate and build credibility, not just hype?
Creating intention: does it inspire actually trying the app?
Expectation setting: will users feel the app matches what they were told? Do they know what success looks like?

Common pitfalls with UGC

Even solid ideas can tank. Here’s what to watch out for:

Pivot problem: your video has a great start, followed by an awkward, scripted sales pitch
Perfect life trap: unrealistic instant results – think before and after clips, perfectly-arranged backgrounds, and model-looking actors
Feature laundry list: avoid overwhelming people with many benefits crammed in; keep it anchored on the core job-to-be-done (JTBD)
Platform mismatch: there’s nothing that screams ad more than a TikTok-style video dumped on LinkedIn
The one-shot myth: don’t expect your first creative to boom, performance is a numbers game; you have to test many concepts to find a winner

To solve most of these problems, the solution is simple: keep performances natural, keep the creators and information credible, and make sure the video doesn’t feel out of place.

Three creative experiments for 2026

To move beyond stale UGC and capitalize on the shift to authentic performance, here’s three quick experiments you plan today and share tomorrow:

1. Skits vs. testimonials (problem-first vs. product-first)

Take your current best-performing testimonial and turn it into a scenario-based skit:

Same core promise, but framed as a real-life situation instead of a monologue
Run a clean A/B test on testimonial vs. skit: same audience, same budget

What to look at: CTR, IPM, cost-per-trial, and trial-to-paid

If your experience matches what we’ve seen across subscription apps, the skit will attract fewer curious clicks, but more qualified ones, improving down-funnel metrics.

2. Method-first vs. product-first hook

For one of your hero features, create two versions of the same ad:

Version A (product-first): introduce the app in the first three seconds
Version B (method-first): spend 15–20 seconds selling the method (the ‘how’ and ‘why’) before ever naming the app, like the Jumpspeak example

What to look at: trial-start rate, trial-to-paid, and early retention (day one–seven)

In most cases, method-first creatives generate slightly lower CTR, but much higher intent and LTV.

3. One concept, three native variants (platform fit)

Pick a single creative concept (e.g. frustration with the current solution) and adapt it natively for three platforms:

TikTok and Instagram Reels: fast skit, jump cuts, creator-led
YouTube Shorts: more structured explanation and/or commentary
Instagram feed: shortened cut + supporting carousel or strong caption

Keep the core narrative identical, but adapt the format, pacing, and framing to each platform.

What to look at: IPM, cost-per-trial, and view time per platform

This will show you where your narrative travels well as-is, and where you need a truly platform-native editorial approach.

Evolution, not revolution

The core insight of UGC was always right: people trust people more than brands. But execution matters.

‘Authentic’ doesn’t need to mean amateur, and ‘user-generated’ shouldn’t mean without strategy. The best performance creative keeps what made UGC powerful (relatability and a human voice) while moving past what made it ineffective (the stale, inauthentic formulas). Apps stuck on testimonials will keep burning budgets, while apps embracing this authentic performance model will build durable growth, stronger retention, and compounding LTV.

As we head into 2026, authenticity isn’t a style; it’s its own UGC strategy.

Android SDK lifecycle management with Hilt dependency injection

Wed, 26 Nov 2025 23:20:08 GMT

Android applications integrate numerous third-party SDKs for payment processing, analytics, and subscription services, each with its own initialization requirements and clean up procedures. Managing these lifecycles manually leads to memory leaks, resource exhaustion, and subtle bugs when SDKs outlive their usefulness. Hilt’s component scoping and lifecycle hooks provide a solution, but understanding how to properly leverage them requires knowledge of the internal mechanisms that make lifecycle management possible.

Let’s dive into SDK lifecycle management with Hilt, including:

Exploring the modern dependency injection library
How Hilt’s component hierarchy maps to Android lifecycles
How lifecycle callbacks enable automatic clean-up
How scoping determines SDK lifetime
Why proper lifecycle management prevents resource leaks.

Using RevenueCat’s Purchases SDK as an example, you’ll see how different scoping strategies affect SDK initialization and disposal, when clean-up is necessary versus premature, and the performance implications of each approach. This isn’t a guide on integrating SDKs. It’s an exploration of the lifecycle machinery that makes proper resource management possible.

The fundamental problem: SDK lifecycle mismatches

Third-party SDKs often have explicit lifecycle requirements:

The challenge: when is “later”? If you initialize in Application.onCreate() and never call close(), the SDK holds resources (connections, caches, listeners) for the entire app lifetime. If you initialize in Activity.onCreate() and call close() in onDestroy(), you might prematurely dispose of resources during configuration changes.

The naive approach is manual lifecycle tracking:

This works but is brittle. You must remember to call close() in every activity that uses the SDK, and you must correctly distinguish configuration changes from true destruction. Hilt’s scoping and lifecycle mechanisms automate this pattern.

Hilt’s component hierarchy: Mapping to Android lifecycles

Hilt provides a predefined component tree that aligns with Android’s lifecycle:

Each component has an associated scope annotation and lifecycle:

The SingletonComponent with @Singleton scope lives from application creation to application destruction
The ActivityRetainedComponent with @ActivityRetainedScoped scope lives from activity creation to activity finish, surviving rotation
The ActivityComponent with @ActivityScoped scope lives from activity creation to activity destruction, getting destroyed on rotation
The ViewModelComponent with @ViewModelScoped scope lives from ViewModel creation to ViewModel cleared
The FragmentComponent with @FragmentScoped scope lives from fragment creation to fragment destruction

Understanding this hierarchy is critical for SDK lifecycle management. The component you choose determines when initialization and clean-up occur.

The lifecycle callback mechanism: RetainedLifecycle internals

Hilt provides lifecycle hooks through the RetainedLifecycle interface:

This interface is implemented by ActivityRetainedLifecycle and ViewModelLifecycle, providing clean-up callbacks for retained components.

RetainedLifecycleImpl: the implementation

The internal implementation reveals important constraints:

All lifecycle operations must happen on the main thread. This is enforced via ThreadUtil.ensureMainThread(), preventing concurrent access issues. Listeners are stored in a HashSet, not a thread-safe collection. The main thread requirement eliminates the need for synchronization overhead.

The onClearedDispatched flag ensures clean-up happens exactly once. Attempting to add listeners after clean-up throws an exception. The exception message explicitly describes the race condition scenario, making debugging easier.

This implementation prioritizes simplicity and performance over flexibility. Lifecycle callbacks are strictly single-threaded and one-way.

The ViewModel bridge: how clean-up is triggered

The lifecycle callback is triggered through Android’s ViewModel.onCleared():

This is elegant. Hilt doesn’t reimplement lifecycle tracking. Instead, it piggybacks on Android’s existing ViewModel retention mechanism. The ActivityRetainedComponent is stored inside ActivityRetainedComponentViewModel. Android’s ViewModelStore retains the ViewModel across configuration changes, and when the Activity finishes (not just rotates), ViewModelStore clears the ViewModel. Then ViewModel.onCleared() is called, which dispatches Hilt’s lifecycle callbacks.This design means Hilt’s lifecycle hooks have the same semantics as ViewModel.onCleared(). They fire when the Activity is finishing, not during configuration changes.

SDK lifecycle patterns: three scoping strategies

Let’s examine three different approaches to managing RevenueCat’s Purchases SDK, each with different lifecycle implications.

Pattern 1: Singleton scope (application lifetime)

The simplest approach is application-scoped initialization:

The SDK initializes on first injection, typically during Application creation. It never gets disposed of. The SDK lives for the entire app lifetime.

The Google Play Billing connection is maintained throughout app lifetime with approximately a few KB overhead. The subscription cache stays in memory, typically less than 100 KB for most apps. Network listeners remain active for the app lifetime.

This approach makes sense when subscription features are core to the app, like subscription-based apps where user subscription status is checked frequently across many screens. The overhead is acceptable given usage patterns.

This approach should be avoided when subscription features are rarely used, like a one-time tip jar in settings. It’s also not ideal when the app is resource-constrained and runs on low-end devices, or when the Billing SDK conflicts with other payment integrations.

Pattern 2: ActivityRetainedScoped (survives configuration changes)

For feature-scoped usage, tie the SDK to a specific section:

The SDK initializes on first injection within the Activity’s component graph. It gets disposed of when the Activity finishes, after isFinishing becomes true.

When the screen rotates, the SDK instance is retained with no reinitialization. The same ActivityRetainedComponent is reused during activity recreation. When the activity finishes, lifecycle.onCleared() fires and purchases.close() is called.

Let’s trace the complete lifecycle:

This is the sweet spot for feature-scoped SDKs. You get configuration change resilience without app-wide overhead.

Pattern 3: ViewModelScoped (per-ViewModel instances)

For ViewModel-specific SDK instances:

The SDK initializes when the ViewModel is created. It gets disposed of when the ViewModel is cleared, which happens when the Activity or Fragment is destroyed. Each ViewModel gets its own SDK instance, providing complete isolation.

This pattern works well when you have multiple independent purchase flows with separate state, when testing requires isolated SDK instances, or when different ViewModels need different SDK configurations.

Creating multiple SDK instances means multiple Google Play Billing connections. A SubscriptionViewModel instance creates Purchases instance #1 with Google Play Billing connection #1. An UpgradeViewModel instance creates Purchases instance #2 with Google Play Billing connection #2. Each connection has overhead of approximately 200 to 500ms initialization time and a few KB memory. For most apps, a single shared instance is more efficient.

Configure debug & release SDK initialization

For example when developing with RevenueCat, you can set different SDK configurations for debug builds to enable testing without real purchases. Since RevenueCat’s StoreKit Testing (Test Store) allows you to simplify subscription testing flows without connecting to real App Store servers. For release mode, you can set the real private key, and allow your users to purchases the products.

Different build variants need different SDK configurations:

Hilt processes each variant separately, so debug and release modules don’t conflict. The debug module configures the SDK with verbose logging and manual sync control, making it easier to test subscription flows with Test Store. The release module uses production configuration with automatic sync enabled.

The Test Store integration allows you to test subscription scenarios locally without making real purchases. You can verify that your SDK lifecycle management works correctly across different subscription states, test upgrade and downgrade flows, and validate that clean-up happens properly when users cancel subscriptions. This is particularly valuable when testing ActivityRetainedScoped SDKs because you can simulate the complete lifecycle from subscription purchase through activity rotation to final clean-up.

RevenueCat’s singleton protection: a special case

Before diving into why clean-up matters, it’s important to understand that RevenueCat’s Purchases SDK has built-in singleton protection that prevents accidental instance duplication. Look at the implementation:

When you call Purchases.configure() with the same configuration multiple times, RevenueCat returns the existing singleton instance instead of creating a new one. This means the ActivityRetainedScoped and ViewModelScoped patterns described earlier won’t actually create multiple SDK instances if you’re using the same API key and configuration.

However, if you call configure() with different configurations (different API keys, different user IDs, different settings), RevenueCat will create a new instance and replace the singleton. The old instance still exists in memory until you explicitly call close() on it.

This singleton protection is specific to RevenueCat. Many other SDKs don’t have this safeguard and will happily create multiple instances if you call their initialization methods repeatedly. Examples include Firebase Analytics, Amplitude, Mixpanel, and many payment SDKs. For these SDKs, the resource leak scenarios described below are real concerns.

The key takeaway: even though RevenueCat protects against duplicate instances with the same configuration, the lifecycle management patterns with Hilt still matter because they ensure proper clean-up when you’re done with the SDK, handle configuration changes correctly, and establish patterns that work across all SDKs, not just RevenueCat.

Why clean-up matters: Resource leak analysis

Let’s analyze what happens without proper clean-up, both for RevenueCat and for SDKs without singleton protection.

Memory leak scenario: Singleton without scoping

The Google Play Billing Service connection is maintained indefinitely. Service binding holds Context reference and prevents garbage collection of associated objects. The subscription state cache grows over time with cached offerings, products, and purchase history. There’s no eviction policy without close(). Network listeners stay active throughout app lifetime, including webhook listeners for subscription changes and background sync operations.

For a singleton SDK in a subscription app, this is acceptable. The resources are used throughout the app lifetime. The ‘leak’ is intentional.

Resource exhaustion scenario: Activity scope without clean-up

For RevenueCat specifically, thanks to the singleton protection, calling configure() with the same configuration repeatedly just returns the existing instance. You won’t create 10 separate instances. However, you still have a problem: you’re holding references to the singleton in multiple Activity instances, and you never call close() to clean up when you’re truly done with subscriptions.

More importantly, this pattern becomes a real problem with SDKs that don’t have singleton protection. Consider an analytics SDK without this safeguard:

When the user visits AnalyticsActivity for the first time, AnalyticsSDK instance #1 is created with its own event buffer and network queue. When the user navigates away and returns, AnalyticsActivity instance #2 is created, AnalyticsSDK instance #2 is created with another event buffer and network queue. But AnalyticsSDK instance #1 still exists because it was never cleaned up. After 10 visits, you have 10 AnalyticsSDK instances, 10 event buffers, 10 network queues, and a cumulative memory leak.

Eventually, the app will hit resource limits through either memory exhaustion or connection limits.

The isFinishing() pitfall: configuration changes vs. destruction

Manual clean-up often looks like this:

This works but is fragile. Every Activity using the SDK must implement this pattern, which is easy to forget. Unit tests must mock isFinishing correctly, adding testing complexity. Edge cases emerge, like when finish() is called from onCreate() or during programmatic recreation.Hilt’s ActivityRetainedLifecycle eliminates these concerns. The callback fires exactly when the Activity is finishing, with no manual checks needed.

Advanced pattern: Conditional SDK initialization

Sometimes SDKs should only be initialized under certain conditions:

Nullable injection handles the conditional initialization:

This pattern prevents unnecessary SDK initialization for users who can’t use it.

Performance profiling: measuring SDK lifecycle impact

To understand the performance implications, let’s measure RevenueCat initialization and disposal.

Initialization cost

Cold start typically takes 50 to 100ms (depending on your machines), which includes Google Play Billing connection. Warm start typically takes 10 to 20ms when the Billing Service is already bound. Configuration blocks the calling thread, creating main thread impact.

You can optimize by initializing on a background thread:

Using Lazy defers initialization until first access. If that access is from a co-routine on a background dispatcher, initialization happens off the main thread.

Clean-up cost

Clean-up duration typically takes 10 to 50ms. Operations include disconnecting from Billing Service, canceling pending queries, and clearing caches.

Clean-up happens in ViewModel.onCleared(), which is synchronous. Long clean-up blocks the main thread during Activity finish.

You can optimize expensive clean-up by moving to a background thread:

However, be cautious. If clean-up must happen before the process terminates, background clean-up might not complete.

Memory profiling: comparing scoping strategies

Using Android Studio’s Memory Profiler, we can measure SDK memory overhead. With singleton scope, initial allocation is approximately 500 KB. After visiting 10 screens, memory usage remains at approximately 500 KB because the same instance is reused. Memory growth is zero.

With ActivityRetainedScoped while visiting 10 different screens, screen 1 adds 500 KB during initialization. When screen 1 finishes, 500 KB is freed during clean-up. Screen 2 adds 500 KB during initialization. When screen 2 finishes, 500 KB is freed. This pattern continues, maintaining a steady state of approximately 500 KB with one instance at a time.

Without clean-up while visiting 10 screens, screen 1 adds 500 KB, screen 2 adds another 500 KB, screen 3 adds another 500 KB, continuing until screen 10 adds another 500 KB. The total accumulates to approximately 5 MB from 10 instances leaked.

The measurements show that proper clean-up is critical for activity-scoped SDKs.

Testing SDK lifecycle management

Hilt’s lifecycle integration requires special consideration in tests.

Unit testing: mocking lifecycle callbacks

This test verifies that the module registers a clean-up callback and that the callback calls close().

Integration testing: verifying clean-up happens

This test verifies the full lifecycle from initialization on activity creation to clean-up on activity finish.

Replacing SDKs in tests

For tests that don’t need the real SDK:

The @TestInstallIn annotation replaces the production module with a fake, avoiding real SDK initialization in tests.

Real-world case study: multi-SDK coordination

Many apps integrate multiple SDKs with interdependent lifecycles:

Dagger’s dependency graph ensures Purchases is initialized before Analytics because Analytics depends on it. This initialization order is automatic based on the dependency graph.

Clean-up callbacks fire in registration order. If you need specific ordering, you can register multiple callbacks, but relying on callback order is fragile. A better approach is to handle dependencies explicitly:

This coordinator pattern makes clean-up order explicit and testable.

Recap

SDK lifecycle management with Hilt leverages the framework’s component hierarchy and lifecycle callback mechanisms to automate initialization and clean-up. The component scoping determines SDK lifetime. Use @Singleton for application-wide SDKs, @ActivityRetainedScoped for feature-scoped SDKs that survive configuration changes, and @ViewModelScoped for ViewModel-specific instances. The RetainedLifecycle interface provides clean-up hooks that fire when components are destroyed, implemented through Android’s ViewModel.onCleared() mechanism.

The internal implementation reveals important constraints. Lifecycle callbacks are strictly main-thread operations enforced through ThreadUtil.ensureMainThread(). Clean-up is one-time-only with explicit race condition detection. The ViewModel bridge ensures clean-up happens when Activities finish rather than during configuration changes. Performance profiling shows that proper clean-up prevents memory leaks by avoiding cumulative SDK instances while scoping determines initialization cost, balancing application-wide overhead against feature-scoped deferred initialization.

Ready to tidy up your SDK?

Understanding these internals helps you make better architectural decisions:

Choose appropriate scoping based on SDK usage patterns
Register clean-up callbacks to prevent resource leaks
Measure initialization and clean-up costs to optimize performance
Coordinate multiple interdependent SDKs through explicit dependency management

While RevenueCat’s Purchases SDK has built-in singleton protection that prevents duplicate instances with the same configuration, many other SDKs lack this safeguard. The lifecycle management patterns demonstrated here work universally across all SDKs, ensuring proper resource management regardless of the SDK’s internal implementation.

Whether you’re integrating subscription services like RevenueCat, analytics platforms, or payment processors, Hilt’s lifecycle mechanisms provide a declarative, type-safe solution to the SDK lifecycle problem.

Start here: Black Friday, holiday sales, and promotional offers

Wed, 26 Nov 2025 16:28:18 GMT

Seasonal offers and holiday sales can boost conversion, retention, and long-term revenue — but only when paired with the right strategy. This study guide brings together everything you need to plan, build and launch effective promotional campaigns across iOS, Android, and the web.

Whether you’re running your first Black Friday sale or optimizing a multi-region holiday strategy, start here.

Promotional offers: essential reading

Starting off with the fundamentals of why seasonal offers work, how pricing affects behavior, and what to test before you launch.

Link	Format	Includes
Maximizing subscription app revenue with holiday discounts and promotions	Webinar	How to plan, run, and evaluate seasonal promotions, ft. examples of effective discount structures and campaign timing
How to re-engage churned users — Caroline Walthall, Quizlet	Podcast episode	Real-world insights on how social proof, flexible plans, and targeted discounts can help re-activate churned users
Smart discounting strategies: When, why, and how to offer deals	Blog	Techniques for building discount logic and choosing offer types to maximize conversion, while protecting long-term revenue

Choosing the right promotional offer

Use these resources to decide which type of promotional offer will create the most lift for your app, from introductory discounts to win-backs and targeted plans.

Link	Format	Includes
Unlocking growth: How to supercharge your paywalls with offers	Blog	Guidance on layering offers into paywalls, increasing paywall relevance, and using incentives to improve view-to-trial conversion
Introductory offers: a key lever for growth	Blog	How introductory offers influence behavior, and when to deploy them for maximum impact
A guide to lifetime subscriptions: are they right for your app?	Blog	The pros and cons of discounted lifetime subscriptions, and when to use them
Introductory offers for RevenueCat Web Billing: convert more users with the right first price	Blog	Instructions to set up web-based introductory offers in RevenueCat
The beginner’s guide to Apple win-back offers	Blog	How-to for Apple’s win-back offers, and how to use them to re-engage churned iOS subscribers
When is the best time to send a win-back offer?	Blog	Understanding churn patterns and when to launch win-back offers, based on user behaviour and subscription lifecycle
How to win back lost customers: Proven strategies for re-engagement	Webinar	Real app examples for designing win-back campaigns, including offer types and targeted segmentation

Running seasonal campaigns across channels (+ RevenueCat tutorials)

Whether you’re building on iOS, Android, or web, these resources walk through the exact steps to implement promo pricing, offer codes, and signed subscription offers.

Link	Format	Includes	Platform
How to run a holiday sale in App Store Connect for iOS subscription apps	Blog + video tutorial	Steps to configure discounted pricing and schedule holiday campaigns in the App Store	iOS
How to run a holiday sale in Play Console for Android subscription apps	Blog	Instructions for setting up price changes, configuring promotional pricing, and scheduling discounted periods in Google Play	Android
How to run a Black Friday campaign for your app on the web	Blog	Best practices for web-based promotions, including landing page setup, messaging, and syncing web offers to in-app pricing	Web
Configuring Apple Promotional Offers for Customer Center	Developer documentation	How to setup and manage Apple promotional offers directly inside Customer Center	iOS
Create and track offer codes for your iOS app	Blog	How to generate, distribute, and monitor promotional codes in RevenueCat for iOS	iOS
Implementing iOS Subscription Offers with Purchases SDK	Developer documentation	Technical guidance for setting up and managing subscription offers, including handling eligibility and redeeming promotions	iOS
Signing iOS Subscription Offers	Blog	How to use RevenueCat to show a retention subscription offer to a recently-cancelled user	iOS
Setting up your offers in Google Play Console	Developer documentation	Setup and management for subscription offers in Google Play Console, and how to link them to your RevenueCat configuration	Android
Configuring Google Play promo offers in Customer Center	Developer documentation	How to display and manage Google Play promo offers via Customer Center in RevenueCat	Android
Supporting Offers in RevenueCat Paywalls	Developer documentation	How to surface seasonal promotions directly inside RevenueCat Paywalls with targeting and A/B testing	iOS, Android, Web

Seasonal campaigns work best when supported by strong paywalls, clear pricing, and continuous testing. Whether you’re preparing for a recurring seasonal sale or running a one-off regional promotion, start with one improvement, measure its impact, and iterate.

Your next steps:

Pick one promotional lever to test: a new intro offer, an annual-plan discount, or a targeted win-back
Benchmark your numbers with the RevenueCat App Health Score to understand where offers can improve performance
Keep experimenting — offers are most effective when they evolve with your audience

When pricing becomes product strategy

Wed, 26 Nov 2025 14:02:21 GMT

Ravi Mehta knows the consumer monetization business better than most. During his time as Chief Product Officer at Tinder, he helped shape the multi-tier subscription system that redefined how consumer apps grow and earn. Now he works with startups as a hands-on advisor, helping them fine-tune pricing, onboarding, and product strategy.

This week on the Sub Club podcast, we talked with Ravi about why subscriptions and consumables work better together, how to design pricing that meets users where they are, and why your onboarding might need to get longer (or shorter).

Filling the demand curve

Ravi’s “famous chart” from his time at Tinder has become a benchmark for understanding consumer willingness to pay. By layering multiple subscription tiers with à la carte purchases, Tinder found ways to serve users across the full demand curve, from casual free users to high-value “whales.” The lesson: there’s money left on both sides of a single-tier subscription.

Free to play, not free to fail

Tinder’s biggest breakthrough was the decision to go free. Opening access built the network effects that make the product work, while consumables and premium tiers monetized the subset of users who wanted more. As Ravi explains, “subscription tiers are force multipliers for microtransactions.”

Long or short onboarding?

Working with healthcare startup Sesame Care, Ravi found that expanding a three-step signup to twenty-five steps increased conversion by 40%. But the same rule doesn’t apply everywhere. Tinder’s success came from stripping onboarding down to seconds. The key is knowing when friction builds confidence and when it kills it.

Narratives over numbers

Ravi also shared his framework for goal setting, NCTs (Narratives, Commitments, and Tasks), a simple alternative to OKRs that keeps teams focused on the why, what, and how of their work. And when it comes to growth, his advice is clear: don’t chase vanity metrics; build systems that create lasting value and predictable revenue.

Conclusion

These are just a few of the topics we covered in our conversation with Ravi. To hear more on monetization strategy, onboarding psychology, and how to build products users love to pay for, check out this week’s episode of the Sub Club podcast.

The definitive guide to video paywalls

Tue, 25 Nov 2025 12:20:18 GMT

Back in the day, ‘video paywalls’ simply meant a video locked behind a paywall, like a content creator selling access to their course. These days, the term has evolved into something more exciting: embedding video on your paywall. Say goodbye to boring, static paywalls and hello to interactive experiences that capture attention and communicate value in seconds.

Videos are a powerful way to boost paywall performance and convey your value clearly. While there’s limited data on testing videos specifically on paywalls, we know video as a medium works: it communicates quickly and enhances emotional recall. For example, Fitness AI shared at an App Promotion Summit that adding a video to their paywall resulted in roughly an 80% revenue increase, and they still use a video on their paywall today.

If you’ve read my article on weird paywalls, you’ll know I have a soft spot for quirky, offbeat designs. One of my favorite examples is Water Llama, a water-tracking app that uses a playful feature video to bring its paywall to life by showing the adorable llama water tracker filling up right on the screen.

While adding a llama to your paywall might be a step too far, adding a video is a move worth considering, whether on your paywall or during onboarding.

So, read on for who should (and shouldn’t) consider a video paywall, as well as how to test and implement one effectively to set yourself up for success.

Quickfire: Pros and cons of adding video to your paywall

While videos are more common for certain app categories and audiences, that shouldn’t stop you from considering them. Ultimately, video paywalls can help you achieve four key goals — these should be the drivers of whether you use videos on your paywalls, rather than the app’s category. But, there are a few drawbacks to consider as well.

Pros

Cons

Convey emotion: videos can do this far more effectively than static images or text

Visually explain your app: perfect for photo, video, health, and wellness apps, or any app where showing functionality beyond the paywall helps users understand value

Build trust and show transformation: demonstrate the impact of using your app and reassure users that it will deliver results

Capture attention: slow the user down to capture their focus and convey your message

Increased load time can hurt performance

Potential distraction or overwhelm, especially if users expect a quick, functional experience

High-quality asset requirements demand extra time, skill, and budget

Testing complexity, with so many variables at play, can make it difficult to pinpoint why a video isn’t improving conversions

At the end of the day, whether a video paywall is right for your app depends on your audience, category, and goals, but it’s always worth testing before making a final call. Read on to dive deeper into whether video paywalls are right for your app.

When should you add video to your paywall?

My own experience has shown testing videos in your onboarding and paywall can improve not only the number of trials started, but also the trial-to-paid conversion rate — especially with how-to videos that help your audience understand the real value of your app.

A great video can elevate your paywall and improve conversion, but the wrong one can slow it down or muddy the message. Here’s how to tell when your app may benefit from a video-first paywall.

1. When emotion drives conversion

Apps in the fitness, wellness, or habit space often sell a feeling, and video is perfect for capturing that. Take Cardi Mate, a heart-tracking app, for example. Their paywall uses a full-screen background video showing the app in action while clearly conveying both the app’s value and the feeling of calm and control over your heart health.

It’s layered with minimum copy and a subtle overlay at the bottom that conveys:

Social proof (number of subscribers)
Trial/payment setup
A brief description of the app

This combination helps users feel the value of the app immediately, boosting their likelihood to convert. Clicking ‘Continue’ takes you straight to payment with no extra screens and no friction.Another great example is Loóna, a sleep app. The onboarding features relaxing music, instantly fostering a sense of zen. The video on the paywall is simple but soothing, perfectly capturing the state that Loóna helps users achieve (though their dark UX way of reporting pricing definitely isn’t as chill).

2. When visuals explain the value faster than words

If a picture’s worth a thousand words, a video’s worth more than Jeff Bezos’s portfolio. Let’s get the obvious out of the way: photo and video apps. Any app that relies heavily on visual content naturally benefits from a more visual way of showcasing its features.

Take CapCut, an AI-powered video and image editor owned by ByteDance (TikTok’s parent company). Like Water Llama, CapCut uses video on its paywall to highlight key features, automatically displaying them one by one with short clips that show exactly how each feature works.

Videos are invaluable when used to demonstrate how an app works, or to walk users through key features right after download.

3. When transformation or trust needs to be proven

Now, for a more unusual example from my exploration of video paywalls. I downloaded 50+ apps to test their paywalls — partly because it’s hard to confirm whether an app shows a video upfront, and partly because my memory isn’t perfect. (Shockingly, I don’t remember every paywall I’ve ever seen.)

One app I tested out, which I came across through Jacob Rushfinn’s newsletter, is Dr Kegal. At first, I thought nothing of it and was simply excited to try out the app he recommended. But this app did something unexpected: it forced users to watch a 30+ second video before even showing the paywall. A major faux pas in the video world.

Here’s the kicker: I now have an app on my phone, as a woman, that helps with erection duration… It’s a topic that many users might feel uncomfortable discussing, or unsure whether exercises will actually help. The paywall video shows multiple men who have benefited from the app, establishing trust and credibility. Once it finishes, the video remains at the top of the paywall, reinforcing the social proof and value before users decide to subscribe.

A secondary video on the scrollable paywall then dives into the science behind the app and explains more about how it works.

In situations where users may be skeptical of an app — or uneasy about its topic — a video on the paywall can help build trust at that critical moment. Another excellent use case is in a competitive market; by building trust that you offer something different.

4. When attention is scarce (and video helps capture it)

Your audience type can influence whether you prioritize video. Data suggests that younger audiences prefer video explanations over text, making video paywalls worth testing for these groups. With older generations spending less time on social media, we’re seeing apps mimic social platforms more and more — not just with short-form video, but also with Instagram-style story swipes and bite-sized content. Let’s be honest: most of us don’t read thoroughly anymore.

While this guide focuses on using video on the paywall, you can also use it in onboarding or even create a two-step paywall (video → paywall with trial/payment info) to capture attention and understanding before the payment screen.

Sylvain Gauchet, Growth Consultant and author of the Growth Gems newsletter, recently highlighted the growing trend of paywall-onboarding blurring:

“I’ve been seeing multiscreen paywalls more and more, especially for free trials, where instead of showing the bleakest timeline, they actually break it down in multiple screens…it blurs the line between what’s onboarding and what’s a paywall. It’s like if you have a screen before the paywall, is that part of the onboarding? Is that part of the paywall? But, it gives you that possibility to show benefits, explain better the actual transactional aspect, and a last-minute pitch or recap to push people over the edge.”

I’m currently testing this approach for a Gen Z app. We’re swapping the four rapid-fire feature screens (image + text) with video + text feature screens, leading into the paywall to ensure users fully understand the app before being asked to pay.

When should apps avoid using a video on their paywall?

It’s important to note that video requires more effort than other types of paywall — specifically, it’s more effort to test and validate. My recommendation is to only introduce video (and test it) after you’ve validated your messaging and identified which features drive users to pay. You can then test your paywall, and know it’s specifically the video driving any changes. If you skip straight to adding a video it often results in slower, less effective testing and lower success rates than if you optimize your copy and core features first.

So if you’re yet to find product-market fit, or identify whether users are really willing to pay, you may want to hold off before adding videos. There are a few other cases where video may be less relevant:

1. If your audience has lower bandwidth or limited data

Even if you optimize video size for faster loading (RevenueCat’s Paywall Builder does this automatically), videos still impact load time. If your users have slower internet speeds, limited data, or unreliable wifi, a video paywall could create friction.

You may be thinking “But Daphne, how do I know what my users’ internet speed is?”, but that’s not quite what I mean. Consider what your app does and when it’s most-used. Apps users look to when hiking or camping, for example, need to function with minimal service. If you know your audience is older, then perhaps their internet won’t be as fast as if you’re targeting Gen Z gamers who rely on lightning fibre connections. Likewise, if the markets you’re selling to are in more rural areas, or countries whose internet infrastructure is slower — these are all elements to consider.

2. If your app’s USP is being simple and functional

For straightforward utility apps, a video paywall can actually get in the way. If speed is the user’s priority, a video may distract them from their end goal. For example, if someone just wants to quickly scan and upload a passport copy, the last thing they want is to sit through a video first; it could just frustrate them. You need to weigh up whether a video will actually help your user convert — or if you just think it will. This is also where testing comes in (stay tuned for that)…

3. If you don’t have (or can’t get) high-quality videos

While AI has made video production easier, creating effective videos still requires time and investment. Whether animated or live-action, you can’t cut corners on quality. A low-quality video on your paywall can do more harm than good.

You’ll also need to test different formats to find what resonates with your audience, so be mindful of the time and resources required before committing.

Testing and implementing a video paywall

Okay, you’ve got your messaging airtight, you know users want the product, and video seems the right fit for your paywall. How do you go about testing and launching a video paywall?

1. Define your goal for testing video

We’ve covered the main reasons why apps might use video on their paywall:

Convey emotion
Visually explain features
Communicate transformation and build trust
Capture attention

Clarifying your goal will help determine what format and setup you should test, e.g. if you’re focused on explaining your app better, you probably want to test a feature carousel or a full video background.

2. Decide on the video format

Next, identify which format best supports your goal. As you’ve seen from the examples, there are several effective ways to integrate video into your paywall:

At the top of the paywall: showcase your app in action and immediately engage users
As a background: add motion and depth to make your paywall feel more dynamic
A block within a longer landing page: ideal for premium apps that need to explain features or value propositions in more detail, keeping users engaged across a scrollable paywall
In a carousel: demonstrate multiple features in short, digestible clips
First screen of your paywall: capture attention and understanding before moving into pricing or trial details

You can also combine formats, as seen with Dr. Kegal, which blends multiple videos across its paywall. Another great example is Reface, the AI-powered face swap app, which uses a carousel that doubles as a looping background video, creating a lively, interactive experience.

For apps that want to showcase an animation, a video can also be used, especially if you are using a paywall builder that doesn’t support animation. Animations are a great way to boost engagement. For example, Duolingo, the language learning app, uses a little animation of Duo, their owl, on their paywall.

While apps like Reface likely use code to implement this, a quick way to test a similar effect — especially if your paywall builder doesn’t support animation — is by using a short, looped video or GIF. That said, it’s worth noting that animations implemented directly with code will generally load faster than videos.

Your goal and chosen format will also help determine where to test the video. Some apps, like CapCut, use the same video across all paywalls because the features showcased remain universally relevant. But if your goal is to help new users understand the app’s value, you might choose to test it only on the initial paywall.

For example: FitOn, a fitness app with an intense paywall video, features upbeat music, flashing visuals, and full-screen energy. It’s highly effective for new users, giving instant context and excitement about what the app offers. But forcing returning users to watch that same video every time could be more irritating than inspiring.

When I returned to their app, the paywall I saw after that was a simpler feature carousel instead:

3. What content to include in the video (and the rest of your paywall)

When it comes to your video content, keep these best practices in mind:

Keep the video short: in most cases, no more than 15–30 seconds
Ensure it works without sound: most users won’t have sound on — all of the examples we’ve discussed work silently; only Dr. Kegal uses a voiceover (and even then, they include subtitles)
Start with a strong visual hook: at the start of the video, especially if the video is used to communicate the value of the app

Keep in mind, cognitive load can quickly become overwhelming when combining video, copy, and calls to action. Simplicity almost always wins. You’ll notice in the examples that the more detailed or dynamic the video, the simpler and more minimal the supporting copy tends to be.

If you’re unsure what kind of video to test, a great starting point is a simple walkthrough that highlights how your app works, showcasing the key benefits and features in a clear, engaging way.

4. Setting up the video

When setting up your video paywall, there are a few key considerations:

Loop vs. play once: most paywall videos tend to loop – users may read the text first or miss the beginning, especially if they’re multitasking (or, like me, have ADHD).
Autoplay vs. click-to-play: should your video play automatically, or only when tapped? Autoplay is the standard, as it immediately captures attention. But click-to-play can work well for optional content, like user testimonials or deeper feature explanations, keeping the paywall cleaner and less distracting.
Mute vs. sound on: as mentioned above, many users will have sound off when using an app, and may even get frustrated if the sound suddenly goes on (or off) or they can’t understand what is going on in the video. My advice: Keep it muted by default. If there is dialogue in your video, I beg you to use captions. It will improve engagement, accessibility, and the user experience.

Of course, there are exceptions. Let’s return to the example of FitOn. Their high-energy, full-screen video doesn’t loop or auto-mute because it’s designed to immerse users completely. As the video ends, it fades out smoothly to direct attention toward the ‘Subscribe’ button, creating a natural flow rather than a jarring stop. Since the video is longer and highly dynamic, muting it wouldn’t make sense in this context, and looping it would be overwhelming.

Additionally, make sure to optimize your video for load time. While load time matters less in an app than on web, it still impacts performance and user experience.

If you’re using RevenueCat’s paywall builder, the good news is that it automatically optimizes the video following the best practices:

Initial load: the video thumbnail appears immediately
Progressive load: a lower-resolution version plays first for speed, then transitions to high quality
Local caching: the video is stored locally for faster playback on subsequent views
Bandwidth optimization: data usage is minimized for a smoother experience

If you’re implementing this on a native paywall, that’s the moment to smile sweetly at your developer and beg for help… it’s their time to shine.

Your testing roadmap

You’re testing a video for a good reason (I hope). So please don’t test one video, and if it flops, swear off video forever. Then two years later, when a bright-eyed new Product Manager suggests, “Hey, maybe we could try a video on the paywall…,” you immediately cut them off: “No, we tested that two years ago. Video doesn’t work for us.”

One test doesn’t prove that video paywalls don’t work, it just means that version didn’t.

Based on your goal, focus your testing on three main elements:

Content: what the video covers, how it starts, and how long it is
Placement: where the video sits on your paywall (and if you have a multi-step paywall, on which screen)
Setup: the various technical and behavioral setup options we discussed earlier

That’s also the order I recommend testing in. For most apps, especially single-screen paywalls, content will have the biggest impact.

Here’s what your high-level testing plan might look like:

Baseline: start with your current static paywall and record conversion and engagement metrics
Experiment 1: swap the hero image for a short looping video (keeping copy the same). Measure the lift
Experiment 2: test different video types, e.g. a feature demo vs. an emotional story, to see which drives better conversions
Experiment 3–X: combine your top-performing video with tweaks to hooks, placement, or length for further optimization

Does video deserve a spot on your paywall?

Your paywall is your make-or-break moment. In that split second, users decide whether your app feels worth it. A video gives you another dimension to make that decision easier, to help users feel the outcome, see the transformation, and stay just a little longer.

Not every app needs a video, but many should at least test it, especially with tools like RevenueCat Paywalls, which make it easier than ever to level up your paywall experience.

When done well, video can boost conversions, strengthen your brand, and make your paywall stand out in a sea of sameness.

So whether it’s an animation of a llama getting hydrated or a user unlocking their fitness potential, don’t be afraid to bring your paywall to life with a video that adds real value.

October product updates: Paywall videos, smarter support, and a big step onto the web

Tue, 25 Nov 2025 11:50:33 GMT

If your growth playbook includes “iterate faster” and “meet customers where they are,” this release is for you. RevenueCat’s October product releases focus on exactly that.

You can now take Paywalls beyond the app and into the browser, make them richer with video and new layout tools, and give support teams instant subscription context right where they work. Plus a handful of quieter upgrades that make daily life smoother.

Here’s what’s new.

Meet the RevenueCat changelog

Now you can track every release in one place. The changelog lists new features, improvements, and fixes so you always know what’s been shipped. It’s the easiest way to stay current and share updates across your team.

If you want to keep an eye on what’s landing week to week, start there. View the changelog ↗

Introducing Paywalls on the web

RevenueCat Paywalls now work in the browser, not just inside iOS, Android or other mobile apps.

That means you can:

Design the same high-performing paywalls you already use on mobile.
Drop them into landing pages, ads, newsletters, or any link-based flow with web purchase links or the Web SDK.
Update instantly without shipping new code or waiting for an app release.

Web paywalls give you a clean path from “someone clicked a link” to “someone subscribed,” while keeping all your testing and targeting in one place.

Web Purchase Links already give you a fast path to sell on the web; Paywalls on the web make those pages customizable, testable, and far easier to optimize.

Check out the docs ↗

Paywalls get videos, plan sheets, and text gradients

Once Paywalls moved to the web, we wanted them to feel even more like your product and less like a template. Three new tools help with that:

Videos on Paywalls
Add a product demo, a quick walkthrough, or a customer testimonial right in the paywall. It’s a simple way to answer “what do I get?” without adding clutter.

“View all plans” sheets
You can now tuck extra pricing options behind a button that opens a plan sheet. Keep the main paywall focused, while still giving power users the full menu.

Gradient text
For headlines that need a little punch, gradient text lets you highlight key value props without redesigning the whole page.

Together, these updates help you build paywalls that look custom and convert better, with zero extra engineering.

Check out the docs ↗

Unity support for Paywalls and Customer Center

If you ship in Unity, monetization and subscription management should feel just as native as they do on iOS and Android.

With the latest SDK, Paywalls and Customer Center now work in Unity apps. You can present native paywalls, let users manage subscriptions in-app, and control offers and entitlements from the same RevenueCat dashboard you already use elsewhere.

So Unity teams get the full RevenueCat experience, end to end.

Check out the release notes ↗

Support gets smarter with Zendesk and Intercom integrations

Support teams don’t want to chase billing breadcrumbs. They want to solve the problem in front of them.

The new Zendesk and Intercom integrations bring subscription data straight into your support sidebar, including:

Customer history
Revenue contribution
Active entitlements
Subscription status

Agents can auto-match customers when possible, or search manually when they need to. Either way, they get the full picture without switching tools. Support is quicker and easier.

Intercom integration ↗

Zendesk integration ↗

A new home for web monetization

We also rolled out a dedicated RevenueCat Web hub. Think of it as mission control for anything web-based:

Web Billing
Purchase links
Paywall performance insights
Real-time revenue tracking

The goal is simple: you should be able to go from setup to optimization without bouncing between pages or hunting for the right dashboard.

If web revenue is becoming a bigger piece of your mix, this is where you’ll want to live.

Learn more ↗

More improvements worth knowing about

A few smaller upgrades that still matter:

AppsFlyer integration with Paddle support
You can now track Paddle transaction events in AppsFlyer, so attribution stays unified across web and mobile purchases.
Preview Customer Center colors
See color changes instantly before publishing on iOS, which makes design tweaks faster and less guess-and-check.

If you want to take any of these for a spin, everything is live in the dashboard now. Start with Paywalls on the web if you’re already using Purchase Links; the upgrade is immediate, and it opens up a lot more room for testing and iteration. And as always, keep the feedback coming. The fastest way we improve the product is by hearing what you’re trying to build next.

Why are React Native apps monetizing better?

Mon, 24 Nov 2025 11:48:03 GMT

If you look at the cross-platform charts at the end of 2026 State of subscription apps (SOSA) you will notice a peculiarity: React Native apps seem to be making more money in almost every possible way.

Since RevenueCat has access to all the subscription related information; e.g. how much was the subscription price, did it have free trial, was this a returning customer, and what technology the app is built with (ease to determine by just checking which RevenueCat SDK is sending the aforementioned data); our data set is possibly the most comprehensive when it comes to in-app purchases. Well if Apple and Google are not counted, but that data is not, and most likely will never be public.

So React Native apps make more money, but why, and how? In this article I’m going to look at what SOSA tells us about monetization on cross-platform frameworks, and explore what characteristics of these frameworks could explain the data we are seeing.

Where does this data come from

Data collected by RevenueCat comes from the SDK installed on apps by developers themselves. RevenueCat only measures in-app purchase revenue, some types of monetization (paid apps, web-only subscriptions, physical goods, or custom billing systems) fall outside this dataset. Despite that limitation, the sample is broad: it spans solo developers, venture-funded companies, and apps across every major category on iOS and Android.

Evan Bacon’s Who’s using Expo in 2025 adds important context to the amount of React Native apps, showing 2,200 apps in the App Store using Expo SDK or React Navigation, both very often used with React Native, in production. Since the list is collected from trending and top downloaded charts, it provides a look at apps that people are actually using, and many of those happen to be React Native apps.

Despite all of this, the data collected by RevenueCat is extensive as it includes all major platforms, all major development frameworks, and apps made by both solo developers and large VC funded companies.

Understanding the data and visualizations

Before diving into what the numbers tell us about React Native, Flutter, and native apps, it’s important to understand the structure of the SOSA dataset and how its visualizations work. The report uses box-and-whisker (candlestick) charts throughout.

Each chart breaks the distribution into four key points:

Bottom quartile (Q1 / lower whisker) – The lowest-performing 25% of apps
Median (Q2 / lower edge of the box) – The “middle” app in the dataset
Upper quartile (Q3 / upper edge of the box) – The top 25% of apps
P90 (upper whisker) – The threshold the top 10% of apps exceed

This structure gives a more realistic picture of how apps perform in the real world. The “box” shows where most apps cluster, while the whiskers show the spread between weaker and exceptional performers. When we talk about React Native outperforming other frameworks, we’re referring to these distribution points — not isolated outliers.

React Native converts better than Flutter and native

When we look at download-to-paid performance in the SOSA dataset, one pattern stands out immediately: React Native apps convert a higher share of their users into paying subscribers than apps built with Flutter or fully native technologies such as Swift and Kotlin.

The box-plot above shows React Native’s median conversion rate at 2.2%, compared to 1.8% in Flutter and 1.9% in native apps. But where React Native really pulls away is at the high end: the 90th percentile hits 11.2%, while Flutter reaches 8.8%, and native apps peak at 7.7%. In practise, this means that when comparing two apps with similar audiences, similar categories, and similar subscription models:

The average React Native app turns more of its downloaders into paying customers.
The best React Native apps outperform the best apps built natively.

Put another way: if you took two teams of equal skill and resources, one building an app in Swift/Kotlin, the other building it in React Native, the React Native team is more likely to produce an app that successfully converts users. React Native apps are more likely to reach the conversion rates that turn a good idea into a sustainable business.

First key learning: deliver as fast as possible

One of the main benefits of React Native is that you can share much of the code between multiple platforms, most commonly those being Android and iOS. A capable developer, or a team of developers, can realize a complex React Native app in 3-6 months (with exceptions, but higher than that and you lose the benefits), and release it to both app stores around the same time.

Shopify went all-in on React Native in 2002,

Shopify went all-in on React Native five years ago. Just this week, the company reflected on how it went, sharing:

– More productivity: thanks to one codebase powering iOS and Android, and working across both apps

– Performance and reliability: all pages have sub-500ms loads and crash-free rates are above 99.9%. Both are impressive numbers!

– TypeScript for the win: using TypeScript makes it easy for devs to transfer between React and React Native.

– There are downsides: debugging is worse than for native apps, and updating to new React Native versions can be painful.

In mobile apps the market is divided between iOS and Android. Any serious app business will eventually have to target both. React Native allows you to technically do that from day one. This gives competitive advantage by allowing developers to experiment with pricing and monetization methods earlier on both platforms. This is particularly important on Android where users are more price sensitive, due to having cheaper devices and lower standards of living.

Don’t Flutter apps have a smaller time to market as well?

The multi-platform aspect is being solved by other technologies as well. Kotlin multiplatform is trying to get Android developers to ship their apps to iOS, and there are some solutions for Swift to do the opposite. What comes closest to React Native is Flutter, which also targets multiple platforms. It’s loved by developers due to the comfortable syntax of Dart, but businesses show less love towards Flutter, mainly because Dart as a language is not as common, as is mainly just used in Flutter apps. React Native instead makes use of JavaScript, a language that most businesses already hire because of the existing web app based products as well.

React Native apps generate more revenue per install

In the revenue per install (RPI) chart in native and Flutter apps look similar at the median (around $0.18–$0.19), with Flutter pulling slightly ahead at the top end ($1.55 vs. $1.11 for native).

Once again React Native seems to be operating on a different curve entirely:

Median RPI: $0.30 (roughly 50% higher than native/Flutter)
90th percentile: $2.48 (more than double native’s top performers)

In plain words, the best React Native apps seem to generate significantly more money per install. Coming back to the example of two equally skilled teams, if each acquired 100,000 users, the strong React Native app could earn $248k, versus $111k for a strong native app.

Feedback loop of faster time to market

Building great products is all about getting the products in the hands of your customers as fast as possible. The main reason for aiming for this is to learn from the customers: what they want, what features they are willing to pay for, and how much they are willing to pay for them, etc. The faster you’re at the market doing this, the more likely you are to beat your competition by having the things customers want.

The pattern matches what we see in conversion data: React Native teams tend to optimize harder and iterate faster

React Native pulls further ahead by day 60

Link

By Day 60, the revenue patterns sharpen: React Native not only starts ahead — it keeps widening the gap. This chart isn’t just about how much money apps make early; it shows how well they monetize over time.

Here’s what the data really tells us:

React Native apps keep compounding revenue better than any other framework

A median RPI of $0.44 and a 90th percentile of $3.54 means RN apps don’t just convert early — they continue generating value from users weeks after install. Whatever advantages RN teams have (iteration speed, better testing velocity, product-focus), they keep paying off long after launch.

Flutter apps outperform native at the high end

The median is similar ($0.26 vs $0.27), but Flutter’s 90th percentile ($2.29) and upper quartile both exceed native. This suggests that while the average Flutter app behaves like a native app, the best Flutter teams drive significantly higher long-term revenue.

Native apps stay steady but fall behind

Native tops out at $1.53 for the 90th percentile — solid, but noticeably behind both Flutter and React Native. At D60, this makes native apps look like the “safe baseline”: consistent median performance, but fewer breakout successes.

Other frameworks are extremely uneven

The median ($0.29) is low, but the 90th percentile hits $2.94, nearly matching Flutter. This means some “Other” apps (Unity, Cordova, etc.) can monetize extremely well — but the outcomes are far more unpredictable.

What Day 60 Really Means

D60 revenue is a proxy for retention, pricing power, upsell behavior, and the maturity of the monetization model. The fact that React Native continues to outperform tells us:

Users acquired by RN apps stick around longer
Those users keep buying (renewals, upgrades, add-ons)
RN teams iterate faster, pushing improvements before revenue decay sets in
RN apps likely adopt monetization best practices more aggressively

Year-1 Retention by Plan Type Shows Only Modest Differences Across Frameworks

Here’s the real story of this chart:

Retention at one year barely differs between Native, Flutter, React Native, or any other framework.

That means React Native’s massive lead in conversion and revenue cannot be explained by better long-term retention. Users don’t stay subscribed longer in RN apps. They stay about the same.

And that is the interesting part — because it tells us exactly where the advantage must be coming from:

React Native apps convert more users earlier
React Native apps extract more revenue per install
But when it comes to keeping customers for a year, all frameworks perform similarly

In other words: React Native wins by front-loading value, not by keeping users longer.

Now the quick breakdown by plan type (supporting, not leading):

Weekly plans:

All frameworks are nearly identical (median ~2–4%). No technology advantage.

Monthly plans:

Native and “Other” frameworks retain a few percentage points higher at the median (≈9–10% vs. ≈7–8% for Flutter/RN).

The gap is small — not enough to matter strategically.

Annual plans:

All frameworks cluster tightly in the high 20s to low 30s at the median.

Even the top performers are scattered evenly across frameworks.

The native feel dilemma

One of the early arguments against React Native, that still persists today, is that it is not “native enough”. Non-native feel has meant:

Slower apps, with RN apps both taking longer to start up, but also navigating and other interactions having more jank than native apps
Wrong feeling animations, with noticeable framerate drops, wrong easings
UI not following the platform specifications

Every year since its launch, React Native has been working towards making this statement less and less true. To understand those efforts

What Year-1 Retention Really Means

Retention is a downstream outcome of value — if an app reliably solves a recurring problem, users stay subscribed. In that sense, this chart reinforces an important point:

React Native’s monetization advantage does not come from retaining customers better, but from converting more customers and monetizing them more effectively.

Retention stabilizes across frameworks

React Native delivers the highest LTV per paying user — by a wide margin

Link

If you want to know which apps make the most money from each paying subscriber over their first year, this chart answers it clearly: React Native is in its own tier.

React Native apps show:

Median LTV: $22.80 (higher than all other frameworks)
P90 LTV: $85.26 (dramatically higher than native, Flutter, or “Other”)

That means React Native apps don’t just convert better and earn more per install — their paying users are also worth more over time. The framework draws a straight line through the whole monetization funnel.

Flutter vs. Native
Flutter sits below native at the median ($13.81 vs. $16.15), but once you move into the upper quartile and top performers, Flutter pulls ahead.

This suggests Flutter has a longer tail of “misses,” but when a Flutter app hits, it hits hard.

“Other” frameworks
While inconsistent at the median ($16.38), the 90th percentile reaches $70.90, meaning some apps built with alternative stacks monetize extremely well — but the distribution is much more volatile.

Conclusion

Product is the key, not the technology

React Native doesn’t just produce more payers — it produces payers who stick around and spend more.

This is the final reinforcement of the monetization pattern visible across every chart:

React Native teams iterate faster, test pricing more aggressively, ship more improvements, and ultimately capture more lifetime value from their best users.

Convert Figma designs to paywalls instantly with the new RevenueCat Figma plugin

Thu, 20 Nov 2025 17:27:17 GMT

Designing high-converting paywalls usually starts in Figma, where your design team already lives, experiments, and iterates. Our Paywalls Editor is built to make rebuilding those Figma designs fast and easy, but why not skip that step entirely?

Today, we’re making that happen.

You can now access the RevenueCat Figma plugin, a new way to go from design to live paywall instantly. With a single export, the plugin converts your Auto Layout–based Figma frames directly into fully editable paywalls in RevenueCat.

From Figma frame to RevenueCat Paywall

Once installed, the plugin lets you:

Export one or multiple paywalls from a single Figma file: perfect for rapid iteration or preparing a batch of A/B test variations

Preserve your exact layout and styling: text becomes text, images become images, frames become stacks – all mapped automatically

Automatically detect key components: layer names like Button, Purchase Button, or Package are translated into their corresponding RevenueCat Paywall components

Send designs straight into the Paywall Editor: your growth or CX team can then tweak copy, swap products, localize text, or spin up experiments – all without needing more design or engineering support

This workflow empowers designers to craft rich, on-brand paywalls that feel native to the app, while giving product teams the flexibility to iterate quickly inside RevenueCat.

Why this matters

For most teams, paywalls start in Figma. Designers define layout, visual hierarchy, branding, and conversion-driven variations long before engineering or growth gets involved. But historically, getting those designs into a live paywall required manually recreating them in the Paywall Editor.

The new plugin eliminates that step entirely.

Now designers can build paywalls exactly where they prefer to work, and every variation, from small copy tweaks to full redesigns, can be exported in seconds. Meanwhile, PMs and growth teams can immediately turn those designs into experiments, compare performance, and publish updates without needing new design files.

It’s a faster, cleaner, more collaborative approach to paywall iteration.

Watch the full tutorial and read the docs

If you want to see the full flow end-to-end, we’ve put together a complete walkthrough:

Full Video Tutorial

Documentation
https://www.revenuecat.com/docs/tools/paywalls/creating-paywalls#importing-from-figma

Get the Figma Plugin
https://www.figma.com/community/plugin/1571207414894772119

The fastest way to build high-quality, on-brand paywalls is now the one your designers were already using. Try the plugin, experiment with multiple variations, and start shipping paywalls faster than ever.

Grow ARPU by adding value for existing subscribers: tactics + real app examples

Thu, 20 Nov 2025 16:20:13 GMT

Growth often slows for more established subscription apps from acquisition channels mature and conversion funnels are optimized. So how do you continue to scale?

The next stage of growth doesn’t come from finding more users, it comes from creating more value for the users you already have (and monetizing that value, of course).

Expanding product value helps in two key ways:

Retention: by solving more problems and staying relevant in your user’s daily life, you reduce churn and increase subscriber lifetime value (LTV)
ARPU: once new value is proven and desired, it can be tiered, bundled, or monetized — increasing average revenue per users (ARPU)

In practice, the line between retention and ARPU is thin. Value expansion often starts as a retention initiative, then evolves into a revenue driver once engagement and perceived value grow.

Before we dive into identifying opportunities to expand value for your existing subscribers, let’s take a look at examples from five leading subscription apps whose added value paid off.

5 app examples for expanding core product value

These mini case studies show how mature brands have extended their core product to unlock both retention and revenue growth, primarily through:

Capitalizing on adjacent use cases and jobs-to-be-done
Finding new audiences through new use cases
Expanding frequency of relevance in users’ daily lives
Adding new core value that can be monetized as premium

Read on for more detail, and some inspiration!

1. Headspace: from meditation to whole-person wellbeing

Headspace began as a meditation app but gradually broadened its focus to include sleepcasts, focus music, workouts, and therapy content. This shift positioned the brand as an entire, holistic wellbeing platform rather than a single-purpose meditation tool.

The expansion worked by extending Headspace’s relevance (and potentially deepened engagement) across more daily moments: sleep, exercise, focus, and stress management.

Over time, the company also introduced higher-priced tiers and enterprise partnerships, reflecting how a wider value proposition can support stronger monetization. For example, Headspace’s blog and press releases indicate that by 2023-24 the company was offering enterprise clients a single app integrating mindfulness, coaching, therapy and psychiatry, as well as launching direct-to-consumer mental health coaching.

Lesson: expanding into enterprise and higher-value, direct-to-consumer tiers is a clear route to widen value proposition, and can create the justification for stronger monetization.

Headspace’s App Store page emphasizes the breadth of features and life areas it can help users with

2. ClassPass: from fitness access to lifestyle membership

ClassPass initially grew its subscriber base with access to boutique fitness-studios and classes. Today, the platform has shifted into selling far more than workouts; offering a broader lifestyle subscription covering wellness and self-care.

On its website, ClassPass now describes itself as “one app for all things fitness, wellness & beauty” and states that credits can be used for bookings at gyms, studios, salons and spas.

A 2018 article noted the addition of “an assortment of new wellness experiences including massages, facials, cryotherapy, float spas, infrared saunas”. Since then, wellness and beauty bookings reportedly became a major part of the business — at one point in 2021, non-fitness venues made up 55% of all listings in New York for ClassPass; massages in particular “became the most popular wellness activity”.

ClassPass is a great example of how a subscription service can expand into adjacent motivations to reach a new audience (e.g. from solely gym-goers to also self-care and beauty lovers) and increase usage frequency. By widening the scope of what can be booked with credits, ClassPass not only found new users, but increased the relevance of its membership across more parts of existing users’ weekly life.

Lesson: supporting higher engagement (more usage occasions) and deeper value for members will ultimately result in stronger retention, LTV, and new monetization paths (through premium plans, more credits, higher-value bookings).

ClassPass quickly demonstrates its wide relevance, from the app name and subtitle to app preview images

3. Airbnb: from budget stays to curated experiences

Airbnb rose to success as a peer-to-peer marketplace for spare rooms. Since its launch in 2008, the platform has expanded beyond accommodation into categories such as curated online ‘Experiences’, luxury home rentals, and bespoke services allowing users to book chefs, trainers, massage therapists and more at their rentals.

In 2025 Airbnb announced a relaunch of its Experiences and introduced Airbnb ‘Services’. The evolution suggests the company is not simply scaling by adding more listings or new types of accommodation, but broadening what a “trip with Airbnb” can mean, making the brand relevant to more moments, more identities of traveller, and ultimately enabling higher-value bookings over time.

Lesson: broaden your offering around related use-cases to not only deepen engagement and relevance, but also open the door to increasing transaction size and revenue potential.

Airbnb’s subtitle and app previews directly call out each use case for the app’s expanded value

4. Duolingo: from language learning to the learning habit

Duolingo built its reputation on gamified, bite-sized lessons designed for language learning. Over time, however, the company broadened its scope: it introduced longer courses in subjects like maths and music, and more recently launched a chess course that uses puzzles and interactive matches.

This expansion appears to have been aimed at turning a language-learning habit into a more generalised learning habit. Rather than simply charging more up front, Duolingo has focused on increasing daily engagement and habit strength across multiple subjects first, then positioned itself to monetise this broader surface area of learning via upgraded subscription tiers and premium features.

The broader curriculum appears consistent with the strong financial momentum the company is reporting: 41% revenue growth, and rising paid subscriptions in 2025. Analyst commentary further suggests this adjacent-subject expansion is a key lever for driving higher ARPU.

Lesson: expand your habit loop into adjacent domains (from languages to maths, music, and chess) to boost retention first, then create the platform for increased ARPU once the concept is proven.

While Duolingo’s App Store name still indicates language-learning as its primary use case, the subtitle and screenshots quickly showcase the variety of topics users can learn

5. OpenAI: from chat to a daily co-pilot across work and life

ChatGPT launched in late 2022 as a conversational AI that people used for questions, ideas and simple creative tasks. With rapid expansion, the platform has broadened into a much wider set of everyday and professional use cases. ChatGPT is now being used across writing, coding, studying, analysis and business workflows.

OpenAI’s own product announcements reflect this widening scope. For example, ChatGPT can now generate and analyse files, troubleshoot code, create images, support team collaboration, and run custom agents built by users.

ChatGPT’s use now spans students, marketers, engineers, SMBs and enterprise teams. In many cases under the same Plus or Team subscription.

By expanding into more real-world contexts, ChatGPT appears to have evolved from a curiosity into a utility product, which helps support premium plans. Reporting shows that ChatGPT Plus reached around two million subscribers by early 2024 as use cases broadened.

Lesson: when a product expands into more daily use cases, occasional usage can turn into habit — and habitual use creates the foundation for stronger retention and pricing power.

ChatGPT differs from the other examples’ App Store listings, not calling out use cases in the name or subtitle, and focusing on aspirational motivations rather than feature callouts

Identifying your subscription app’s value expansion opportunities

Once a product reaches maturity, the question shifts from “how do we get more subscribers?” to “how do we create more reasons for existing subscribers to stay and pay more?”. The answer is pretty simple: make your app worth more. Give subscribers new features, new use cases, and new motivations to use the app.

Value expansion isn’t guesswork; the most successful companies, like the examples above, follow a recognisable pattern. Here’s four steps to identify your app’s next shift:

Start by mapping core and adjacent jobs-to-be-done

Every subscription product solves a primary job for users, but most users have several related needs surrounding that core job. For example, Headspace began by helping users target anxiety and relaxation — the next natural step was tackling sleep.

You can start by observing what people try to accomplish before, during, and after they use your product to reveal natural places to expand. These adjacent jobs usually become the clearest starting points for broadening value.

Alternately, look to competitors and the rest of the market. Duolingo was already the market leader for language-learning, but the ‘Education’ category of the App Store still showed other general learning apps. So it made sense for them to expand to other subjects beyond language.

Validate with behavioural and survey data

Not every adjacent idea is worth pursuing. The strongest signals come from your most retained users: what else do they repeatedly do, search for, or pair with your product?

Behavioral analysis often uncovers complementary apps, repeat patterns, or clusters of similar feature requests. Review mining can also be a valuable technique to identify new areas for expansion that you already know users are interested in. Surveys and interviews help confirm whether those patterns represent real unmet needs rather than edge cases.

Test expansion ideas through lightweight prototypes

Value expansion rarely begins with a full feature build. Many companies start with small, reversible bets: content pilots, limited betas, basic integrations or partnerships. These early experiments reveal whether users recognise the added value and whether it increases engagement.

If the signal is strong, the surface area can be expanded with more confidence, and you can consider putting monetization strategies in place (see below!).

Monetize only once the value is established

Most companies introduce expanded value as a retention lever before treating it as a revenue lever. While it’s tempting to put new features or use cases behind a paywall, hold off until users consistently engage with the new behaviour or app areas. Proven value supports pricing power; unproven value does not.

Once you have this proof, higher-tier plans, add-ons, or bundles feel far more natural to users, and far less risky to your retention..

Ready to expand your app’s value?

For established apps, expanding value is a natural next step once the core product and funnel have matured. It’s a retention lever first and an ARPU lever second.

There’s many ways to expand the value of your app and drive increased revenue per user; the examples and guidance in this article are just a handful of options at your disposal. But there is a general consistency among the apps that expand successfully: thoughtful expansion into adjacent use cases and audiences, backed by user research or interest, rather than a rapid reach in a new direction.

The longer users stay and the more needs you meet, the easier it becomes to justify premium pricing or new product lines later on.

In short: earn engagement, then monetize it. That’s how established subscription businesses turn retention improvements into sustainable ARPU growth.

How to run a Black Friday campaign for your app on the web

Wed, 19 Nov 2025 14:39:27 GMT

Black Friday is a perfect moment to sell on the web. Your audience finds you through newsletters, ads, podcasts, and social links; you bring them to a checkout you control, shorten the subscription flow and keep more of the revenue.

If you’re panicking that it’s too late to cash in on Black Friday sales, relax 😎

RevenueCat Web Billing lets you launch fast, convert easily, and measure end-to-end. Read on for how to build a simple, effective campaign in hours.

Why the web for Black Friday

Better acquisition: the web is where top‑of‑funnel happens; email, paid social, search, influencers, and affiliates all link out to web, so one click takes people straight to your offer
Quicker to build & easier to optimize: update copy, pricing, or creative in minutes, no review cycles, just test and learn while traffic is hot
Lower costs: keep the margin you’d lose to app store fees, seasonal discounts pay off more when you keep the upside

Example: Justin Guitar’s quick and easy Black Friday campaign

To see Black Friday sales via Web Billing in action, here’s how Justin Guitar set up their Black Friday campaign on the web.

Justin Guitar added a simple banner to the homepage promoting 40% off the first year of their annual plan. The banner linked directly to a RevenueCat Web Purchase Link, a hosted checkout page connected to their existing products. No extra code or web app changes needed.

They also used a Redemption Link so buyers could unlock new in‑app features right after paying, without creating or logging into an account first.

Why this works

Low friction: visitors go from homepage to checkout in one click
High intent: the audience is already familiar with the brand through email and social channels
Better economics: by selling on the web, they keep the revenue share that would’ve gone to the app stores

You can build this same setup in an hour, add your offer, link it to checkout, drop the banner or email link, and start tracking results.

How to build a Black Friday web campaign in RevenueCat:

Now you know what a solid web campaign looks like, here’s what you need to build yours:

A promo landing page that matches your offer and brand
A hosted checkout that works anywhere a link fits
A redemption step that connects the purchase to your app without a login
Clear tracking from the first click to in‑app activation

The flow at a glance looks like this: Ad or email → web paywall or promo page → hosted checkout → success page → redeem in app

You can run this with no code if you want speed. Use Web Purchase Links for checkout and Redemption Links to connect the purchase to a user. If you have time for more control, add a Paywall to design a richer pitch and test variants.

What you need before you start

A RevenueCat project with a mobile app, products and prices set up
An offer to promote, including any intro discount and renewal details
Redemption Links set up in RevenueCat (or enough time to go through app review)
A place to link from: email, landing page, homepage banner, or all three
Optional: a simple visual for your campaign flow, and a branded hero image

With the basics ready, it’s time to build the offer and connect the purchase flow.

Step 1: Create your Black Friday product, offering and intro offer

Start by creating a new product for your Black Friday deal — this keeps the discount separate from your regular plans and gives you clean reporting when the campaign ends.

Set up the product with the exact duration and price you want for the promotion. Then create an entitlement that grants the same premium access your standard plans unlock. Linking the new product to this entitlement ensures buyers get the full experience in your app without changing anything in your existing setup. This structure also lets you pair the product with a dedicated offering so your intro offer, checkout link, and paywall all pull from the same source.

Now use Intro Offers in RevenueCat to set up a limited-time discount. This is perfect for Black Friday: offer X% off the first year, or a short discounted trial that rolls into a full plan later. You can also define custom renewal cycles or durations, which gives you more flexibility than App Store or Play Store billing.

Black Friday brings a surge of high-intent traffic, so think about how you want that traffic to behave. A free trial captures more people during those peak days, while an intro offer gives you healthier LTV because buyers commit with an upfront payment.

Step 2: Set up your checkout link

Next, create a Web Purchase Link. It’s a hosted checkout page, no code needed. You can share it in emails, ads, or your homepage banner. It automatically displays your available packages and handles payment securely.

If you only have one offer, skip the package selection and link straight to checkout. That removes friction and boosts conversion.

To create your link:

Go to your RevenueCat project dashboard
Open the Web section
Create a Purchase Link for your Black Friday product or package
Customize the branding and copy of your Purchase Link
Copy the URL to use in your campaign

When you create the offer:

Pick a clear, time-bound promotion (for example, “X% off your first month/year”)
Add urgency in your marketing copy (“Ends Cyber Monday”)

Step 3: Set up purchase redemption

After purchase, use a Redemption Link so buyers can unlock access in your app without logging in first. It’s a simple way to bridge web-to-app purchases while keeping conversion high. When a user redeems, RevenueCat connects that transaction to their user ID automatically.

You need redemption links set up in RevenueCat before this step works. That includes adding redemption support in your mobile SDK configuration and shipping an app update with that change. Once the updated app is live, buyers can redeem their purchase in one tap and RevenueCat will connect the transaction to their user ID automatically. If you haven’t set this up yet, follow the Redemption Links Docs guide for the SDK steps and project settings you need to enable.

Here’s how to add Redemption Links to your purchase experience:

Open your Web Purchase Link in the RevenueCat dashboard and go to its settings
Check the option to show download and redemption instructions
Add your App Store and Play Store URLs so the link can display the correct download buttons

It will add the redemption step:

On a success page that thanks them for the purchase
In your post-purchase email

Step 4: Preview and test the flow

Use the sandbox URL to test the full purchase flow before you go live. Open the sandbox version of your Web Purchase Link, run through a checkout with a test credit card, and make sure the pricing and copy look right. After the purchase succeeds, test redemption in your mobile app with the SDK configured so you can confirm that the transaction attaches to the correct user and unlocks the entitlement instantly.

Click through your full campaign once from start to finish:

Does the ad or email link open the right paywall or checkout?
Is the pricing and copy correct?
Does the redemption link work cleanly from desktop and mobile?

Once it’s smooth, you’re ready to go live.

And that’s it! You’ve got a working Black Friday campaign with a production URL you can use in any email, ad or social media post.

Adding branded Paywalls to your Black Friday campaign

Now, if you’ve got a little more time, you can increase engagement and bring your campaign to life with a branded Paywall. Branding your paywall takes slightly longer, but will lead to significantly higher conversion.

Step 1: Build your paywall

Open the Paywalls editor in RevenueCat. When you create a new paywall, make sure to use the same offering you previously created for your Black Friday campaign.

Start from a template or a blank layout, then add the pieces that sell your offer, headline, subhead, image or carousel, and product list. Keep the copy short and visual. Focus on the value of your deal, not the discount math.

Good paywalls:

Lead with one clear message (for example, “Get X% off your first month/year of premium”)
Use social proof if you have it, testimonials or logos add trust fast
Add urgency (for example, “Offer ends Cyber Monday”)
Match your brand colors and fonts to make the promo feel native

Step 2: Connect the flow

Once your paywall looks right, replace the paywall of your Web Purchase Link. Go to your purchase link settings and change the radio button to the custom paywall setting. Double-check that the path flows cleanly:

Promo email or ad → paywall
Paywall → checkout
Checkout → redemption

Everything should feel fast and friction-free.

Step 3: Publish and monitor

Go live and keep an eye on the numbers. Adjust copy, layout, or pricing mid-campaign if you need to. The benefit of web is that you can ship changes instantly.

Time to get started!

Running a Black Friday campaign on the web is simple when you use the right tools. You control the offer, the checkout, and the customer data, all without app store limits. The web lets you move fast, test ideas, and keep more of your revenue.

Here’s a quick recap:

Use Intro Offers to set up flexible discounts
Create a Web Purchase Link for a no-code checkout
Add a Redemption Link to connect the purchase to your app
Build a Paywall if you want full control of branding and testing

Together, these pieces make it easy to launch a polished, high-converting campaign in a day. Your audience is already on the web. Bring them to a checkout that’s yours.

How Flighty grows by obsessing over product, not ad campaigns

Wed, 19 Nov 2025 13:27:39 GMT

When most teams think about growing a top-ranked app, the instinct is to reach for paid acquisition. But for Ryan Jones and the team behind Flighty – the meticulously crafted flight-tracking app – growth has come from a different place. Instead of ramping up ad campaigns, they’ve leaned into product, shareability, and craft.

This week on Launched, we sat down with Ryan to unpack how Flighty became one of the most beloved travel apps in the world by focusing almost entirely on the product experience.

Product is the growth engine

Flighty’s philosophy is clear: build great features, and growth follows. Whenever the team has experimented with more conventional tactics, the trade-offs were obvious. As Ryan recalls, “Every time we focused on product, we would’ve gotten basically more growth or free growth.”

The opposite was equally true: “Every time we chased marketing tactics, we stalled.”

Over the years, Flighty has tried three separate attempts to spin up performance marketing. Each time, it diverted the team’s attention and delivered little in return. As Ryan puts it, “It takes a significant amount of our attention away from building product… and at the end of the day… it kind of breaks even.”

That pattern reinforced a simple operating principle: “We just need to stay at the stuff that we’re great at.”

Focus on shareability, not scale

Some of Flighty’s strongest growth has come from features that weren’t even designed for growth. The digital passport – an automatically updated, beautifully rendered flight log – quickly became one of the app’s biggest organic drivers. According to Ryan, “The passport itself… if it’s not our number one growth driver, it’s top three.”

The team spent months refining small touches, including a now-iconic black-light effect. “One of the things that we haven’t mentioned yet… on the original one, a black light button… that was a huge part of it.”

Not every experiment landed. Their first attempt at a “year in review” flopped: “For some reason it just didn’t really catch on.” But revisiting the idea through the lens of craft, storytelling, and visual delight produced a completely different outcome: “It took us a while, but we figured out that… it’s gone crazy.”

Other features quietly fuel the same organic loops. Flighty’s live flight-sharing links, for instance, solve a familiar problem for travelers and introduce new users in the process. Ryan summed up the intention: “We’re looking for things that we can do in Flighty that help the user… and help someone else come into the ecosystem.”

A deliberate approach to acquisition

Flighty doesn’t run Facebook ads, TikTok campaigns, or performance UA. The only paid channel it invests in is Apple Search Ads (ASA).

“The one thing we do do is App Store Optimization or ASA,” Ryan explains. And it matters: “That’s probably 20 or 30% of our new users… come through ASA.”

But even here, the team is cautious. Running ASA without expertise is a quick way to burn money. As Ryan puts it plainly: “If you’re doing the basic version of ASA, you’re probably losing money.” The solution, he says, is simple: “You have to have… a specialist.”

Growth from delight

Flighty’s reputation has also benefited from embracing new iOS capabilities like Live Activities and Dynamic Island on day one. These moments led to App Store features and Apple mentions, but the real value came from how seamlessly they improved the experience for travelers.

Above everything else, the team relies on a simple north star: would we want this ourselves? That consistent focus on usefulness, clarity, and delight has helped Flighty grow on its own terms – without chasing the typical tactics.

Conclusion

From the viral passport to disciplined ASO, this episode offers a clear blueprint for product-led growth. Whether you’re building a travel app or scaling without traditional ad campaigns, Ryan Jones shows how far a team can go by focusing deeply on what they do best and letting users spread the word.

How to run a holiday sale in Play Console for Android subscription apps

Wed, 19 Nov 2025 09:27:43 GMT

Holiday season is one of the most powerful times of year to attract new subscribers, re-engage lapsed customers, and strengthen the relationship with your existing audience. Between Black Friday, Cyber Monday, Christmas shopping and New Year Sales, consumers are on the hunt for deals. If you’re an Android developer with a subscription-based app, you can use Google Play’s offer tools to create a compelling holiday promotion that boosts conversions and lifetime value (LTV).

This guide walks you through every step of creating, launching, and analyzing a holiday subscription offer using the Google Play Console and RevenueCat.

Overview of Google Play subscriptions

Let’s first refresh our minds on how subscriptions work in Google Play Store.

In Google Play Store, every subscription can have multiple base plans, which in turn can have multiple offers. Base plans define the subscription billing period (monthly, yearly), renewal type (auto-renewing, prepaid), and the price. Offers define the discount available to users matching the eligibility criteria. Offers can only be configured for auto-renewing offers.

Each subscription in Google Play Store can create a combined total of 250 base plans and offers, with a maximum of 50 being active at the same time.

Two ways to run a sale on Google Play

Before diving deeper, it’s important to understand that Google Play provides two primary mechanisms for running discounted subscription promotions:

1. Offer phases

Use the standard offer system inside Google Play subscriptions. Each offer can include up to two phases (free trial, introductory pricing, discounted billing cycles). These are best for broad, paywall-visible sales where your goal is to drive conversions directly through the subscription product configuration.

Codes that unlock a free trial or access to a subscription. Promo codes are redeemed manually by the user. They’re best for targeted, limited-quantity, partner-driven, or community-driven campaigns where you want tight control over who can redeem the offer.

Planning your holiday offer

A strong campaign begins with clear goals and a defined audience. Before you touch Google Play Console, decide what success looks like for your app.

Defining your goals

Ask yourself what you’re trying to accomplish. Do you want to acquire new users? Reactivate past subscribers? Reward loyal customers? Each goal requires a different setup. For example, acquisition offers target users who have not subscribed before, while developer-determined offers can re-engage lapsed ones.

Holiday timing also matters. Some apps see their biggest lift during Black Friday weekend, while others benefit from the post-Christmas days when people are setting up new devices. Map out a timeline and plan your offers around it, whether that’s install-to-trial conversion, first renewal rate, or total recurring revenue.

If your goal is maximum conversion from new users during a big holiday event (e.g., Black Friday), then use Offer phases. These appear directly on your paywall and require no code entry. They scale well for large-volume campaigns.
If your goal is targeted reactivation, gifting, influencer partnerships, or limited-edition holiday bonuses, then Promo codes may be the better tool. They give you full control over distribution, but require more user effort and don’t automatically appear on the paywall.

Promo codes and offer phases can coexist in the same campaign, but most apps will rely on offer phases as the default mechanism for holiday sales.

Segmenting your audience using eligibility criteria

Eligibility rules apply specifically to subscription offers created using Offer Phases. They determine which users will see a given offer inside the subscription options returned by Play Billing and RevenueCat. Promo codes bypass eligibility checks because the user explicitly redeems them.

New customer acquisition: With this eligibility criterion, Google Play determines if a customer is eligible to receive the offer. You can configure this to check for customers who have never had this particular subscription to your app, or customers who have never had any subscription to your app. If Google Play determines a customer is not eligible, the offer will not show up in the subscriptionOptions of the StoreProduct in the SDK at all.

Upgrade: This eligibility criterion is the inverse of the previous one. Customers are only eligible if they currently have another subscription of your product, and you can configure in detail what products this offer applies to. Again, if Google Play determines a customer is not eligible, the offer will not show up in the subscriptionOptions of the StoreProduct in the SDK at all.

Developer determined: Offers with this eligibility criterion will always show up in the subscriptionOptions of the StoreProduct in the SDK, and you are responsible for determining whether or not to apply the offer to a customer. If you are relying on the RevenueCat SDK automatically applying free trials and introductory periods and you do not want a developer determined offer to be automatically selected, apply the tag rc-ignore-offer to the offer.

Offer phases

Offer phases are one of the two main tools for running a Google Play sale. They let you create up to two sequential discounted billing periods, such as a free trial followed by introductory pricing before the subscription resumes its normal base plan price. Offer phases are ideal for large seasonal sales because they appear automatically on your paywall and scale effortlessly to all eligible users.

Decide whether your holiday deal will be a short-term discount or a longer phased pricing plan. A big one month discount can drive conversions, but a phased offer plan may improve retention.

Play console also allows developers to create codes that are redeemable for one-time products or as trials to subscriptions. There are two types of promo codes.

One-time codes are unique, auto-generated by the Google Play console, and limited to a single-use
Custom codes are codes created by the developer which are redeemable as many times as the developer allows

Setting up a holiday offer in Google Play Console

Once your goals and audience are clear, the next step is to create the offer in Google Play Console. The entire configuration happens there, and once you are familiar with the workflow, each new offer only takes a few minutes to create.

Step 1: Configure your base plan

Every subscription offer must belong to a base plan. A base plan defines the underlying product ID, billing period, and standard pricing that your offer will temporarily override.

In Play Console, open Monetization → Subscriptions, choose your subscription product, and verify that your base plan is active in all regions where you intend to run the holiday promotion.

If you want to isolate campaign results, consider creating a separate base plan named something like premium-holiday2025. This lets you switch back to your standard base plan later without affecting other configurations.

Step 2: Create a new offer

Under your chosen base plan, click Add offer. Give the offer a descriptive and human-readable ID such as holiday-2025-blackfriday or holiday-2025-reactivation. Clear naming matters because you will see this ID in RevenueCat dashboards, cohort exports, and logs.

Once created, the offer lives under that base plan and can be toggled on or off without deleting it, allowing easy reuse for future events.

Step 3: Define eligibility

As mentioned in the planning section, Google Play provides three core eligibility rules, which control who can redeem your offer:

New customer acquisition: only users who have never subscribed to this product can redeem it — perfect for first-time installs during your holiday user-acquisition blitz
Upgrade: for customers moving from a lower tier or a legacy subscription to a higher-value plan
Developer determined: you decide in-app who qualifies — this is ideal for re-engaging churned subscribers or rewarding loyal users

For holiday campaigns, ‘New customer acquisition’ often performs best for growth, while ‘Developer determined’ gives maximum flexibility for reactivation deals. To enforce developer-determined eligibility, your app checks conditions through the Play Billing Library before showing the discounted SKU. E.g., if a user canceled more than 60 days ago, you can programmatically make them eligible for the holiday-2025-reactivate offer.

Step 4: Set pricing phases

A single offer can include up to two pricing phases, letting you script how the price changes over time. For example:

Phase one might be a one month free trial
Phase two can ease the user back toward the standard price, e.g. 50% off for January, before auto-transitioning to the base plan price in February

These phases make it possible to reward early adopters without locking in low pricing permanently.

When editing a phase, specify both the price and duration (in billing cycles). Remember that each phase must be at least one billing period long. Preview the total charge sequence in the summary view before publishing.

Step 5: Add tags and metadata

Tags are optional but highly recommended. They allow you to track performance later in RevenueCat and the Play Console reports. Use concise, consistent tags like holiday-sale, black-friday, or q4-2025.

Within RevenueCat, you will see these tags alongside each transaction, making it easy to filter cohorts or compare, e.g. black-friday versus standard-offer revenue.

Step 7: Integrate and test with RevenueCat

Finally, ensure your app recognizes the new offer. In your RevenueCat setup, reference it through the SDK’s subscriptionOptions so that the correct price and offer period appear on the paywall.

Use test accounts in the Play Console’s license testing section to confirm eligibility logic, pricing-phase transitions, and analytics tagging before launch.

RevenueCat’s sandbox environment mirrors the offer structure, so you can verify that events like “Initial Purchase” and “Renewal – Offer Phase 2” appear as expected.

Once everything checks out, publish the offer and sync your paywall assets so users see the new holiday pricing immediately.

Marketing your introductory offer

Once you have your offers set up, users will begin seeing your discounted price or free trial at the scheduled time, but they won’t have any indication there’s a sale. You can, of course, run external marketing campaigns to message out the discounted price, but your best bet is to message about the sale in the app using a custom paywall.

If you use RevenueCat Paywalls, you can easily build a custom paywall for your sale and switch the default offering to the offering with your custom paywall to immediately start showing it within the app. If you were already using RevenueCat Paywalls for your presale offerings then setting up this sale requires no code changes at all.

When using RevenueCat’s SDK with a custom paywall, Offering Metadata is the perfect solution for you. Simply add a field to your metadata JSON to specify which paywall you want to be shown, and then in your app check that metadata property to decide which paywall to render. To start and stop your sale paywall, you simply need to change this one JSON property in your Offering Metadata.

Wrapping up 🎁

Holiday promotions on Google Play are one of the easiest and most effective ways to grow subscription revenue when consumer attention is at its peak. Planning early, defining clear goals, and using Google Play’s offer tools together with RevenueCat’s analytics, you can turn a seasonal discount into long-term subscribers. Make the offer simple to understand, run it during a defined window, and track every result.

When done well, a holiday campaign not only boosts year-end numbers but also sets a foundation for stronger retention and smarter promotions all year round.

Stop chasing growth hacks — fix your funnel first

Mon, 17 Nov 2025 15:52:08 GMT

There are some stories I keep coming back to, because they surprise people every single time.

They don’t start with a viral campaign or a million-dollar experiment.

They start with something quieter — a spreadsheet, a late-night analysis, and one stubborn data point that rewired the way I thought about growth forever.

This story begins (improbably enough) with onboarding.

The spreadsheet that changed everything

Back in 2018, I was sitting at my desk, convinced I already understood how users behave, until the numbers quietly dismantled everything I thought I knew.

I was mapping conversion windows for an app, tracking the exact moment people decided to pay.

It was slow, manual work: scribbling timestamps on paper, transferring data cell by cell, building the story line by line. The kind of task that feels like punishment when you start, but is so satisfying when you finish because you’ve built something solid with your own hands.

I expected the numbers to confirm a story I’d told myself for years: users arrive, explore, find their aha! moment, and only then decide to subscribe.

The truth? They didn’t.

Over 80% of all subscriptions happened within two minutes of download. Not day two. Not three hours in. Two minutes.

That’s before they’d even experienced the product. Before any of the features we obsessed over had the chance to matter.

They downloaded, flowed through onboarding, hit the paywall, and made a decision. No feature use. No deep exploration. Just a feeling, a pitch, and a choice.

And it turns out, this wasn’t an anomaly.

Fast-forward to 2025: RevenueCat’s State of Subscription Apps report shows the same pattern at scale: across all categories, 82% of subscription app trial starts still happen on day zero.

Download to trial, by access

In other words, for most subscription products, your window to convert someone has never been smaller.

The illusion of the aha! moment in app marketing

Realising that those first two minutes decide the fate of almost every subscription app, I couldn’t stop thinking about what that really meant.

If people were committing before they’d even experienced the product, what did that say about everything we’d built to be discovered later?

The gradual build-up. The elegant flow toward the aha! moment. The free-will discovery we imagined users would stumble into somewhere in the middle of the journey.

What if that moment wasn’t waiting in the middle at all, but right there at the start?

Masterminds of audience engagement love the grand story arc, what many refer to as the Hero’s Journey: curiosity, exploration, enlightenment, decision. App marketers often borrow this structure for user funnels — the gradual build-up, the carefully sequenced onboarding, the climactic aha! moment that supposedly arrives once the user has explored enough.

But unfortunately, human behavior doesn’t always follow that script.

In reality, it’s shorter, sharper, and far more primal. People don’t wait to fall in love with your app; they make up their minds almost instantly.

We often treat onboarding as if it were the trailer before the movie. But for most users, onboarding is the movie. The opening scene IS the decision.

If you haven’t earned their hearts within the first few screens, you’ve already lost them.

There’s also what psychologists call the perception–experience lag: users don’t judge what the product is; they judge what it feels like it will be. That lag lasts only a few seconds, but in that brief window, your brand equity is either born or it dies.

A beautifully coded feature that solves a real pain point means nothing if the promise of that value doesn’t land first.

Humans are story-driven, not spec-driven.

They buy the narrative of progress long before they ever touch the proof. Once you truly understand what happens in those first two minutes, you stop treating onboarding as maintenance and start treating it as one of your most powerful growth levers.

Why funnel work beats retention work

Shifting from seeing onboarding as a supporting act to treating it as the stage itself changes everything. It reframes how you think about growth entirely; and where leverage truly lives.

In every growth meeting I’ve ever sat through, someone eventually says:

“If we can just improve 30-day retention by 5%…”

Yes, retention compounds, and that matters. But as we’ve already seen, about 80% of conversions still happen in the first session, regardless of your overall rate. The concentration doesn’t move; only the size of the pool does. That means the better your funnel performs, the more that 80% pays off.

A five-point improvement in onboarding can therefore create a far greater impact than the same lift in retention, because funnel gains apply to every new user you attract, while retention gains only benefit the ones you’ve already won.

This is the math most teams overlook.

They chase loyalty before they’ve earned belief. They optimise for longevity before they’ve secured commitment.

When you shift focus to the first touchpoint, the moment where intent crystallises or evaporates, you’re no longer just fixing drop-off. You’re compounding every dollar of acquisition that follows.

So when teams ask, “Where can we do the most impactful work?”, the answer is almost always the same: look at the very first touchpoint.

Example: Flo’s use of commitment psychology

If the first touchpoint is where growth truly lives, few companies embody that truth better than Flo, the period-tracking app. Without overstating it, it’s safe to say Flo turned its first two minutes of use into one of the most profitable pieces of real estate in the subscription economy. Here’s how…

Flo launched in 2015 as a simple period-tracking app and has since evolved into a full-scale health platform. Today, it reaches over 420 million users worldwide, and what’s most impressive isn’t the scale but how that scale was built.

When I interviewed Dmitry Gurski, co-founder of Flo, at an Aperture Sessions event in London, I asked him about experimentation at Flo. He explained that Flo doesn’t leave first impressions to chance. At the time, they were running more than 15,000 tests a year, not focused on adding shiny new features but on refining how people feel in those first two minutes.

Dmitry told me that when Flo first launched, monetisation wasn’t a focus. For years, they grew without it through millions of installs and steady chart positions driven almost entirely by word of mouth and the gravitational pull of late-2010s App Store feature spots (remember those days?).

By the time they decided to switch on monetisation, their data team modelled what ‘good’ might look like for a subscription app. The target was ambitious yet achievable.
And then they blew past it by multiples.

Flo now monetises around 25% of its US audience. Read that again: roughly one-in-four American users chooses to pay. That’s wild.

One of the subtle levers that helped get them there, which sits quietly inside the onboarding flow, was the commitment screen.

Flo’s commitment prompt just before the paywall

I’ve loved this tactic for years, and Flo’s execution is almost textbook. Before users see the paywall, they’re asked to affirm intent: a soft, psychologically-charged moment that converts self-reflection into micro-commitment.

They’re not alone. Headway uses it. Duolingo uses it. Many others follow the pattern.
The interface differs: Hold down your thumb. I’m committing. Sign your name. Answer a pledge question.

The design changes, but the psychology doesn’t.

Here’s how Headway and Duolingo do this, just before their paywall

Even something as trivial as tapping a button can trigger that deep, almost irrational human need to stay consistent with what we’ve already declared.

As Robert Cialdini explains in his classic book Influence, the psychology of commitment is one of the most reliable forces in human behavior: once people take even a small stand, they feel compelled to stay consistent with it.

Before you ever see Flo’s paywall, you’ve already said to yourself: I’m ready. The decision shifts from ‘should I buy this?’ to ‘should I stop what I’ve already committed to?’

I’ve seen the same pattern play out firsthand in smaller products too.

A couple of years ago, I worked with a sustainability app that struggled with the same problem Flo solved on a much larger stage: high installs, low follow-through.
Users loved the idea but weren’t sticking around long enough to turn good intentions into habits.

So we tried something simple. We added a single commitment request screen during onboarding that asked users to confirm: “I’m committing to reducing my carbon footprint this month.”

One tap. No feature redesign. No new UX patterns. Just a moment of micro-ownership.

The result? Day-30 retention doubled. Not because of design, because of psychology.

Flo has a big team running 15,000 tests a year. This little sustainability app had a humble-sized team of five people.

Different scale, same instinct: action creates identity.

4 psychological levers behind the commitment tactics

What makes Flo’s onboarding powerful is the psychology behind it. The tap, the pledge, the quiet ‘I’m ready’ moment that reaches deeper than the interface. They capture the instant when interest turns into intent.

Across the best onboarding flows, Flo’s thumbprint pledge, Headway’s commitment pact, Duolingo’s playful badge, the same idea appears. Each uses subtle cues that guide people from curiosity to commitment.

1. Self-identification: this is who I am.
People don’t just use products; they use them to express something about themselves. Every small action, from pressing ‘yes’ to choosing a path or setting a goal, comes from a sense of self-identifying, and a quiet declaration of belonging.

2. Goal priming: this is what I want.
Good onboarding creates direction. It helps users look ahead and imagine who they’ll become by engaging, making progress feel personal rather than transactional.

3. Effort justification: I’ve already started, I can’t stop now.
Each tap or choice builds invisible momentum. The more people invest, the more they value the journey itself. Curiosity turns into ownership.

4. Consistency bias: I want to follow through.
As Robert Cialdini explains in Influence, once people take a stand, they feel an inner pull to stay true to it. A single decision can quietly evolve into a pattern of loyalty.

Beneath all of this lies a deeper mechanism called the self-perception theory. Psychologist Daryl Bem proposed that people infer who they are by observing what they do. Behaviour comes first, then identity follows.

An illustration of the loop connecting your thoughts, emotions, and actions (Source: becomingbetter.org)

When someone taps ‘I’m committed’, they’re not just acknowledging intent but rewriting their self-story: I’m the kind of person who follows through.

That’s why the sustainability app’s simple button worked and why Flo’s ‘I’m ready’ screen converts at scale. Both turn small actions into identity shifts. No one thinks, ‘I’m forming a contract with myself’, but that’s exactly what happens. It’s the same instinct that drives New Year’s resolutions, gym sign-ups, or finishing a half-read book: once we start, we want to follow through.

The best onboarding teams understand this and design moments that make users choose commitment, without feeling pushed into it.

When the funnel leak is at the start

For every app that masters the first two minutes, countless others never get around to fixing them. Not because they don’t see the leak, but because they underestimate where, and what, is dripping away.

I’ve seen this pattern again and again… brilliant products, talented teams, the right mission, all pointing in the right direction. And yet the growth never comes.

Earlier this year, we worked with one of those teams. We loved their product. We believed in their vision. We did what any disciplined growth partner would do: tightened targeting, ran creative tests, and found new efficiencies. We cut CPIs by over 80%. It’s the kind of result that usually unlocks the next phase of scale.

But it didn’t.

Because the app simply wouldn’t convert.

A year earlier, we’d already run an audit of their onboarding flow. We’d identified friction, mapped better sequencing, and outlined the fixes. The playbook was sitting there, ready. But new features, deadlines, competing priorities took over, and the everyday gravity that pulls teams toward what’s visible instead of what’s vital took hold.

In the end, all that cheaper traffic just flowed in instead — and flowed straight back out.

Better targeting couldn’t fix it. Better creatives couldn’t fix it. Better acquisition efficiency couldn’t fix it.

When the pipe leaks at the source, no amount of volume or pressure will ever fill the system. It will only waste more water. This is why app teams must fix their funnel and start from the first user moment then work forward.

Why teams still ignore the obvious

Stories like that stay with you. Once you’ve seen a great product leak at the start, you start spotting the same pattern everywhere.

From the outside, it’s baffling. You can literally see the cliff on the chart — the sharp drop-off right after signup. You can run the math and know exactly what a five-point lift in activation would mean for revenue, retention, even runway.

And still, most teams don’t move.

It’s not that they don’t care. It’s that the system rewards the wrong kind of motion.

Firstly, retention has better PR. It sounds noble; loyalty, community, long-term love. It photographs well in strategy decks.

Activation, on the other hand, doesn’t have the same reputation. The industry has turned it into a greedy checklist of forms, buttons, and paywalls. It’s seen as a process to complete rather than a moment to inspire.

So the story that sounds inspiring gets funded, while the one that could actually change an app’s fate gets ignored.

Then comes the aha! myth. I’m not saying this doesn’t exist at all in some form, but the way we think about aha! moments isn’t accurate. It’s an illusion: the idea that users will fall in love once they’ve seen enough. This magic moment doesn’t happen, because most never make it that far.

As Simon Sinek reminds us: people don’t buy what you do; they buy why you do it. That’s the core truth behind activation. You don’t sell the proof; you sell the promise. You don’t sell products; you sell stories. And if the story fails to land early, the proof never gets its chance.

And finally, bias builds that sends app teams the wrong signals.

Shipping something new feels like momentum. It wins applause. Iterating on something old feels like housekeeping. It doesn’t make headlines, even when it moves the needle more than a new feature ever will.

But every single customer you’ve ever won (and every one you’ve lost) has passed through that same onboarding flow.

So why wouldn’t you perfect the one experience everyone shares?

The revenue math most teams never do

Let’s make it tangible.

Say you bring in 100,000 installs each month. Around 10% of them start a trial. Of those, about 25% convert to paying users. That gives you roughly 2,500 paying users.

Now increase trial starts by just five points, from 10 to 15%. That small list adds 5,000 more trials. At the same 25% conversion rate, that’s 1,250 additional paying users — without increasing ad spend or changing the app itself.

This is the math most teams never do: the quiet compounding effect of fixing the front door instead of buying more visitors to walk through it.

On paper, everyone agrees this early conversion matters, but in practice, no one truly owns it. Product teams see it as a marketing problem. Marketing teams assume it’s a product issue. UX calls it ‘flow’ and moves on to the next sprint.

And while the org chart debates semantics, revenue quietly leaks away through the very first experience every customer has.

What great onboarding actually does

Once you’ve seen how much growth quietly leaks through the first two minutes, one question inevitably follows: what does great onboarding do that the rest doesn’t?

For a talk I gave last year, I asked ChatGPT a simple question: What makes a great first date?

It answered:

Clear communication: be open about intentions
Learn about each other: share, ask, listen
Tailor the experience: make it feel personal
Create reliability: be honest and consistent
Keep it interesting: maintain spark and momentum

It was, surprisingly, a perfect description of great onboarding.

The best onboarding flows don’t just explain features. Instead, they sell the future while building trust in the present. They distil the entire value proposition into a few moments that feel natural and earned.

Like a great first date, you’re not listing achievements but sharing a laugh, a small truth, a hint of what’s ahead. When it works, it feels effortless: the conversation flows, trust builds, and commitment starts to feel inevitable.

Did you catch it? There it is again — the same pattern of voluntary commitment I mentioned earlier, playing out once more.

The same quiet force behind Flo’s ‘I’m ready’ screen also drives QUITTR, a habit-breaking app created by Alex Slater, who scaled it to over $3m ARR within its first year.

That’s the genius of great onboarding. It doesn’t push people to commit, but makes them want to commit. Instead of overwhelming users with information, it sets the emotional tone, building a sense of safety and excitement that pulls them in naturally.

Apps like Flo, Duolingo, Headway, and Calm all understand this rhythm:

Flo makes you feel understood
Duolingo makes you laugh
Headway makes you feel productive
Calm makes you exhale

Each of them builds what’s called anticipatory trust — the feeling that this product really understands you. And that feeling, more than any feature or design trick, is what makes people pay and stay.

When I spoke with Alex Slater about QUITTR’s growth, he explained the same principle from another angle:

“The longer users spend during onboarding,” he said, “the higher the likelihood they are to convert. People want something back for the time they invest. It’s like the gamblers’ philosophy. They want a return for the time they spent losing.”

QUITTR’s onboarding screen examples

That insight shaped some of QUITTR’s best-performing flows. Rather than focusing on features, they invited users to see onboarding as an investment in themselves. One screen even asked people to sign their name as a personal promise — a simple gesture that taps into our instinct to stay true to what we’ve already chosen.

Every great product I’ve studied strikes the same balance: expectation, emotion, trust, a bit of friction, and momentum. When one is missing, the experience breaks. When they align, the first two minutes build belief.

Great teams treat onboarding as an ongoing habit rather than a finished project. They keep it on the roadmap, continuously testing sharper messages, subtle variations, and stronger emotional cues.

They know every user passes through this flow, making it the most powerful place to improve. When onboarding becomes a living system instead of a one-time launch, conversion grows and learning compounds.

That’s what separates an app that’s merely tested from one that’s truly trusted. Great onboarding defines the relationship with the user and keeps it growing.

What great onboarding doesn’t do: 4 mistakes to watch for

When onboarding falls flat, it’s rarely from neglect. More often, teams try too hard in the wrong places and lose commitment little by little.

Burying the paywall: Hiding your core value behind too many steps drains energy. If users have to search for what matters, momentum is already gone
Information overload: Too often, teams rush to show features when users are really searching for outcomes. They fall in love with what it does for them, not with what a product does
Overuse of brand language: Teams sometimes rely too heavily on branded terms or feature names that mean little to new users. What feels distinctive internally can rather sound confusing or hollow to someone encountering the app for the first time.
Skipping the emotion: Onboarding is a pitch. It should stir a sense of urgency, aspiration, or even the faint fear of missing out. Without that spark, it’s just another set of screens to swipe through.

Earlier this year, Aperture partnered with Mob, the UK App Store’s leading Food & Drink app, on a series of creatives, ads, and onboarding projects that all shared the same goal: making every interaction feel personal and human.

Some of Mob’s onboarding screens

Rather than overwhelming new users with features, the onboarding was redesigned to show why Mob matters before showing what it does. A series of questions was introduced, turning onboarding into a dialogue to get to know the users. This meant that by the time users reached the paywall, they already felt a connection.

Mob ranked #1 in the UK food & Drink Category (August 2025)

The results spoke for themselves: Mob became the #1 Food & Drink app in the UK, reached #3 overall in Australia, and saw trial opt-ins surge.

Want to start fixing your funnel? Start here

If you only do three things, start here:

Audit your onboarding flow: Look at it with fresh eyes. Better yet, watch new users go through it in real time. Notice where they hesitate, where they drop off, and where they light up. The answers are usually right in front of you.
Test one change a month: It doesn’t have to be huge. Reorder the steps. Rewrite the headline on the paywall. Try adding a commitment device. One controlled improvement every month is enough to build steady momentum.
Measure aggressively: Track install-to-trial and trial-to-paid rates separately, and break them down by platform. Make your success metric the number of new paying users, not just percentage lifts that look good in slides but hide real performance.

Attention is expensive. Privacy shifts, higher CPIs, ad fatigue, and shorter patience make the first two minutes the most valuable space you own. You won’t outspend a leaky entry point or out-retain a weak first impression; your real advantage is how well you learn from that opening moment.

Most teams overlook where that learning lives: the small window between install and intent.

When I think back to those 2018 spreadsheets, I remember what they taught me — a great onboarding isn’t a trick or a tactic; it’s seeing what actually moves people forward.

We can ship all the features we want, but if most users never reach them, those features never do their job. The fastest progress comes from making the first two minutes impossible to abandon.

Fix the front door, and everything else you build finally starts to matter.

Apple’s App Store Mini Apps Partner Program: what app teams need to know

Mon, 17 Nov 2025 11:17:27 GMT

Apple doesn’t drop many surprises these days, but this one genuinely caught us off guard. With the new Mini Apps Partner Program, Apple is officially opening the door for apps that host third-party mini apps to access a reduced 15% fee on qualifying in-app purchases.

It’s a niche change, but an important one. If you’re building anything that resembles a platform, marketplace, or ecosystem, this is Apple giving you a clearer rulebook — and a financial incentive — to do it on their terms.

What Apple means by a “mini app”

Apple defines a mini app as a self-contained HTML5/JavaScript experience that’s downloaded after install and runs inside a native host app. The key requirement: it must be developed by a separate third party, not a feature your team built and wrapped in a webview.

That definition narrows the field dramatically. Apple isn’t trying to reclassify everyday app features. They’re targeting the types of HTML-based micro experiences popularized in ecosystems like WeChat and Alipay.

For those products, Apple is now offering a structured, compliant way to operate on iOS.

The 15% headline: when it applies

If your app qualifies and you implement the required APIs, you keep 85% of eligible purchases made inside a mini app, including:

consumables
non-consumables
auto-renewing subscriptions
non-renewing subscriptions

But purchases must:

occur inside a qualifying mini app, and
use the Advanced Commerce API — Apple does not allow classic App Store Connect products for these flows.

There are guardrails too. For example, consumables must be scoped to the mini app that sold them, not shared across multiple experiences.

What joining the program requires

Apple ties the lower fee to a set of newer App Store technologies. To participate, host apps must support:

Advanced Commerce API for configuring products and handling purchases
Declared Age Range API to ensure content is served appropriately
StoreKit IAP as the payment system
Refund consumption reporting via the App Store Server API
Mini-app manifests with detailed metadata for each hosted mini app

This is Apple formalizing a model that previously sat in a grey zone. Now there are rules, APIs, and predictable review expectations, but with more work required from the host.

Why platform-style apps should pay attention

If your product already resembles a platform, this update is meaningful.

Mini apps become first-class economic units

Each mini app has its own SKUs, entitlements, and refund logic. This lets platforms handle commerce cleanly without forcing everything through a single global product catalog.

Better economics

A 15% fee makes the model more attractive for hosts and for third-party developers building mini experiences inside your app.

Clearer compliance

Guideline 4.7 has been shaping this space for years. The Mini Apps Partner Program adds structure and removes some of the ambiguity around what Apple allows.

If you’re not a platform, this likely isn’t for you

If your app doesn’t host external developers, creators, or partners — and you don’t plan to — this program won’t affect your roadmap. Apple isn’t creating a shortcut to lower fees; it’s creating a compliant framework for a specific app pattern.

That said, it’s still worth watching. Apple is making space for “apps inside apps” in a more formal way, and that has long-term implications for how mobile software might evolve.

Early signals from the announcement

A few themes stood out as we dug into the details:

Apple is cleaning up a longstanding grey zone. Mini-app ecosystems have been allowed but messy. This adds rules, structure, and expectations.
This aligns with global super-app patterns. Markets with strong mini-app cultures now have a clearer path on iOS.
Advanced Commerce API is now central. The lower fee is directly tied to adopting Apple’s modern commerce stack — a sign of where future features may go.
This could open the door for JS-based app-building tools. There’s early interest from “vibecoding” platforms: the tools that let users or creators build lightweight, JS-powered mini experiences inside a host app. If they can align with Apple’s definition of a mini app (third-party, HTML/JS, downloaded after install), this program could become a natural fit for their emerging marketplace models.

How to decide if this matters for your team

A simple litmus test:

Do you host (or want to host) third-party micro-apps or tools?
Are those experiences built with HTML5/JS, or could they be?
Does your product strategy lean toward a platform or marketplace model?
Are you prepared to integrate Advanced Commerce, Declared Age Range, and structured mini-app metadata?

If the answer isn’t a confident “yes,” you can safely treat this as strategic context rather than something you need to act on.

But if you are building toward a platform, this is one of the clearest signals Apple has ever sent — lower fees, more structure, and a defined path to hosting mini apps at scale.

Flex + RevenueCat: Accept HSA/FSA payments for in-app subscriptions

Fri, 14 Nov 2025 10:03:12 GMT

We’re excited to announce a new integration with Flex, enabling developers to accept HSA (health spending account) and FSA (flexible spending account) payments for in-app subscriptions for the very first time.

This update lets health and wellness apps offer compliant, tax-advantaged payment options, managed through RevenueCat and powered by Flex’s HSA/FSA technology.

Together, we’re unlocking a new, compliant revenue stream for developers and a smoother checkout experience for users eager to use their pre-tax dollars on eligible digital health products.

Why this matters

Until recently, Apple’s in-app purchase (IAP) requirements limited developers to billing systems that didn’t support HSA or FSA cards.

For digital health apps, that created friction on both sides:

Users couldn’t apply their pre-tax benefits to eligible subscriptions.
Developers lost conversions or forced users into manual reimbursement flows.

Now, with Apple supporting external billing in the US, developers using RevenueCat + Flex can securely accept HSA/FSA payments while maintaining all the benefits of RevenueCat’s cross-platform subscription management, analytics, and entitlements.

The result: more compliant payment flexibility, better user experience, and higher conversion from a previously untapped payment channel.

How it works

The integration connects Flex’s HSA/FSA payment processing with RevenueCat’s subscription infrastructure.

Developers can activate it in just two steps inside the RevenueCat dashboard — no major engineering lift required.

Once enabled:

Flex ensures every transaction meets IRS and plan requirements.
RevenueCat handles subscription renewals, trials, analytics, and entitlements across all platforms.

That means developers can launch new payment options fast — while keeping everything in sync with their existing billing systems (like Stripe or IAP).

What developers are seeing

Early adopters like Ladder, the strength training app, have already seen measurable impact:

“The Flex integration through RevenueCat made it simple for Ladder to offer subscriptions via HSA and FSA cards — a major unlock for our users and an effective new growth lever.

We launched an email campaign educating potential customers about HSA/FSA eligibility using Flex’s marketing guide, and within a few weeks saw over 500 annual subscribers check out using their benefits.

From a technical standpoint, Flex’s seamless, native integration with RevenueCat functions just like our Stripe and IAP integrations — keeping our data and entitlements consistent while enabling a smooth experience across all of our purchase channels.” — Ryan Mott, VP of Data Product at Ladder

For developers, this opens access to over $100 billion in annual U.S. HSA/FSA spending — and makes it possible to capture that demand directly from their apps.

Available now

The Flex + RevenueCat integration is available today for all Flex and RevenueCat customers.

👉 Get started here and start accepting HSA/FSA payments in-app in minutes.

A guide to lifetime subscriptions: are they right for your app?

Wed, 12 Nov 2025 14:56:31 GMT

I bought a lifetime of Calm.

The app, not the feeling, although I’d definitely pay a lot for actual calmness in my life.

After a few years of bouncing between Calm and Headspace, meditating off and on, I saw an offer that felt impossible to refuse: lifelong access to Calm. No monthly payments, no annual renewal, just one payment, forever.

It sounded perfect. Wouldn’t I meditate more if I knew I’d already invested? Wouldn’t it feel amazing to never have to think about my subscription again? One less thing on the mental load. So, after some deliberation, I did it. My first-ever lifetime subscription. My second one came earlier this year when I married my now-husband.

Years later, Calm is still on my phone. Still updated, still upgraded, still going strong. But that raises a bigger question: if a giant like Calm is offering lifetime subscriptions at scale… should your app?

Like with my other deep dives into subscription models (from the pros and cons of annual subscriptions to whether weekly subscriptions make sense), you’ll know it’s never as simple as yes or no“yes, do it” or “no, don’t touch it.” There are advantages and disadvantages for both your customer and your brand. And it doesn’t suit every industry.

So today, we’re diving into lifetime subscriptions. We’ll consider:

How common lifetime offers actually are across industries
The benefits (and risks) for both your customers and your business
Who should consider lifetime subscriptions, and who shouldn’t
How to structure a lifetime offer for success

While you’re probably reading this from a business perspective, I always start with the customers, too. You need to understand their perception and hesitation if you want to test lifetime subscriptions. A lifetime subscription almost always favors either the customer or the brand — rarely both. I can feel like I got an unbeatable deal with Calm, or Calm can feel like they maximized my value. But not both at the same time.

Are many apps really offering lifetime subscriptions?

I turn to my trusty data source, my favorite nerdy nighttime read: the State of Subscription Apps 2025 Report. (Yes, all 262 pages of it, and yes, it delivers every time.)

For most app categories, offering a combination of subscription and lifetime subscription is the second most popular form of monetization. On top of that, a small share of apps also layer in consumables:

Where are lifetime subscriptions most common? Photo & Video apps lead the way, where the model is often framed less as ‘forever access’ and more as a one-off upgrade. They’re also popular in Education and Travel, where users see clear long-term value.

For most other categories, adoption hovers around 18–24% of apps offering both subscription and lifetime options, with consumables sprinkled in.

The big outlier? Business apps. Here, lifetime access makes far less sense — ongoing per-user costs are high, and products evolve too quickly. Especially in the B2B space, lifetime subscriptions rarely align with reality.

The benefits of lifetime subscriptions

So why would you consider moving from a monthly or annual subscription model to lifetime one-off? Let’s look at both sides.

From the customer side

People are tired of subscriptions. Everything from TV to toothbrushes now wants a monthly fee. It’s hard to keep track of them, and everything feels like a subscription these days. Heck, there are literally apps to track your subscription apps. If that’s not subscription fatigue, I don’t know what is.

That’s where lifetime subscriptions come in. They’re appealing:

No more subscription creep: instead of adding one more bill to the pile, users can pay once and forget about it
A way to take a bet: lifetime offers let people back a new app they like, even if it’s still early — many startups price lifetime deals more attractively than their annual plan to encourage this “I’m in for the ride” mindset
The long-game win: stick with the app beyond the breakeven point, and it feels like you’ve unlocked an amazing deal

From the brand and business side

There’s several main business benefits to offering lifetime subscriptions:

Upfront revenue
Boosted retention
Early cashflow
Attracting committed users
Referral benefits
Stand out against competitors

Lifetime subscriptions give you at least five years’ worth of revenue upfront — sometimes more. And if a customer would have churned earlier? Even better. You’ve locked in value you might have lost down the line.

Offering it early, when your app is just getting started, can also boost retention. Those initial lifetime subscribers give you more data to refine your retention strategy, while providing an early revenue boost.

This upfront cash is particularly helpful for content-heavy brands. Think Calm: new meditations, celebrity narrators, music, partnerships — all require continuous investment. A surge of lifetime subscription revenue can fund growth, or even help bootstrapped apps expand without raising capital.

Lifetime subscriptions can also be timed strategically, such as during specific periods where people expect an offer, like holiday discounts and seasonal promotions. In my experience, discount-driven users tend to engage less and churn faster — and Airship’s research on Black Friday subscribers confirms this. But a lifetime deal lets you attract committed users while discouraging bargain hunters.

There’s also a more niche benefit: referrals. Take Origin, a finance app, which rewards lifetime access to users who refer three friends. They cleverly frame it: “Refer two friends to cover one year of Origin, refer one more friend and earn a lifetime membership.” The offer is far more compelling than a free month or year, turning referrals into a powerful growth engine.

Finally, in a competitive industry, lifetime subscriptions can be a smart way to stand out against the giants, most of whom don’t offer them (Calm being the rare exception). Take Jumpspeak, a language app trying to compete with Duolingo: in my experience, they push lifetime subscriptions heavily to differentiate themselves and attract committed users.

When I tried Jumpspeak, it wasn’t quite right for me, but I could see how someone really enjoying the app might opt for the lifetime subscription. That locks them into Jumpspeak for life (hopefully), rather than just testing it and returning to Duolingo. Compared to Calm, where the lifetime offer is roughly 5x the annual price, Jumpspeak prices it at just 3.6x annual, making it a notably aggressive strategy.

The downsides of lifetime subscriptions

Okay, now what’s the catch?

For the customer

When I bought Calm lifetime, I didn’t read the fine print as carefully as I should have (the cost was about a third of what they charge now). Some lifetime subscriptions are limited to certain features, and ‘lifetime’ usually means the lifetime of the product, aka as long as the company stays in business. That’s a gamble, especially with new apps.

If you buy a lifetime from a small startup and they fold a year later, your ‘lifetime’ ends far sooner than expected. With Calm, I didn’t worry as they were already established, but with a newer app like Jumpspeak, which I hadn’t tested extensively, I was more hesitant. Was it worth it?

Another consideration: trials are harder to offer. Since lifetime subscriptions aren’t technically subscriptions under App Store rules, you can’t provide an app trial. This might force users to pay for a few months or a year first before upgrading to lifetime, which can limit adoption.

For the brand and business

Here’s where it gets tricky. Lifetime subscriptions are often priced at 5–12x the annual subscription, designed to sit just above your expected lifetime value (LTV). But averages can be misleading, and lifetime subscriptions don’t take into account price increases.

Take me, for example: I’d already been subscribing to Calm for a few years and likely would have continued for many more. In that case, they probably earned less from me by offering lifetime access. That’s why pricing lifetime subscriptions is always a bit of a tug-of-war.

For reference, I got my Calm lifetime subscription for £119.99.

Back then, Calm was much cheaper — my faulty memory says around $29.99 per year — but now they charge $399 for a lifetime subscription (and $79.99 for an annual subscription). So they could have made significantly more from me as a recurring annual subscriber, especially after the price increase.

You can’t predict inflation, market changes and competitor pricing shifts, or future features which hike up the cost of running the app (e.g. AI features). Meaning your lifetime subscription cost could go from being a safe financial bet one year, to significantly undervaluing your app a couple of years later.

Another downside: upsells. It’s much harder to upsell someone who’s already on lifetime. Sure, you can highlight new premium tiers that aren’t included, but it’s messy. Moving a customer from lifetime to a subscription later is basically impossible. If tier upgrades are central to your monetization strategy, lifetime subscriptions may not be the right fit.

There’s also the mechanics to consider. Switching from a subscription to a lifetime plan usually requires customers to cancel their existing subscription manually before purchasing the lifetime plan. This can be confusing, sometimes leading to accidental double payments, refund requests, support headaches, and unhappy loyal customers.

There’s also the aforementioned important technical detail: in the app stores, lifetime isn’t technically a subscription. It’s classified as a non-consumable in-app purchase, which comes with a few implications:

No subscription features: you can’t offer free trials or the usual subscription upgrade paths.
Manual migration required: customers can’t simply tap ‘upgrade’ from monthly to lifetime, they must cancel first then repurchase. Some apps handle this for the user, others explain it clearly. Miscommunication here is often what leads to double charges, refunds, and support challenges.

There are also future product headaches to consider. Pushing lifetime subscribers to a new premium version can require maintaining an extra product version, and makes it hard to get them to pay again. Matt Ronge, CEO of Astropad, learned this the hard way: ongoing costs were high, making it difficult to support lifetime users while building new features.

He shared on Sub Club that if he could go back, he’d have been even more generous to early customers. His advice: don’t rely on the stick; build something so good that customers want to upgrade voluntarily.

From an investor perspective, lifetime revenue is a one-off hit, whereas subscriptions are predictable and recurring. Predictable revenue compounds over time and increases company valuation. Leaning too heavily on lifetime offers can drag down valuation, which is why you rarely see lifetime subscriptions in B2B SaaS, where running costs are high and recurring revenue multipliers drive growth.

Lifetime subscriptions at a glance

We’ve covered a lot, so before diving deeper, let’s summarize the key benefits and downsides of lifetime subscriptions:

Lifetime subscriptions at a glance

Perspective	Benefits	Downsides
Customer	No ongoing subscription fatigueOne-and-done paymentCan back a new app earlyA great deal if used long-term	Risk if the company folds‘Lifetime’ = lifetime of the productNo trials possible (App Store treats it as non-consumable)Feature exclusions in the fine print
Brand	Upfront cashLocks in value from would-be churnersFunds content or runway (esp. bootstrapped)Works well as promo (Black Friday, New Year)Can be used for referrals / tackling big competitors	Can cannibalize loyal high-LTV customersHarder to upsell or tier laterMessy mechanics (manual cancel + rebuy)Support headaches (double charges, refunds)Ongoing costs may outpace lifetime revenueLess attractive to investors (MRR > upfront cash)

Should you offer lifetime subscriptions?

To make this easy, I’ve created a simple quiz. The more ‘yes’ answers, the stronger the case for lifetime subscriptions. The more ‘no’ answers, the more carefully you should evaluate before testing a lifetime offer.

Are your ongoing costs per user low? High ongoing costs (e.g., many AI apps) make lifetime subscriptions less attractive.
Is valuation a lower priority right now? If you’re not gearing up for investors or an exit, lifetime can be a smart move. If valuation is key, investors tend to value recurring revenue over front-loaded cash.
Do you need the upfront cash to fund future improvements or improve your runway? Lifetime subscriptions can provide a significant cash boost to fund development or growth.
Is retention weak or uncertain? If customers churn early, lifetime offers can lock in value upfront while you work on improving retention, and give you a larger user base to learn from.
Do you have a segment asking for lifetime subscriptions? If users continue to request a lifetime option (especially older or potentially subscription-fatigued cohorts), that’s a sign it could be worth testing.
Are lifetime subscriptions common in your industry or sector? Not saying you should copy others, but if it’s rare, there may be a good reason why.
Are upsells and higher tiers not a big part of your model? Lifetime subscriptions can block future growth, as users are less likely to upgrade or pay extra after buying lifetime access.

Don’t dash off just yet! If you decide to move forward with lifetime subscriptions, there are still a few important considerations to plan for.

Considerations when planning lifetime subscriptions

Even if you answered ‘yes’ to all the quiz questions, it’s still important to carefully consider a few key factors before rolling out lifetime subscriptions:

1. How to price your lifetime subscriptions

Pricing is crucial: set it too low, and you risk eroding your MRR; set it too high, and you may scare off potential customers. Lifetime subscription pricing varies widely across apps, from 2x annual pricing to nearly 12x annual pricing, depending on the product and market.

Just look at how different apps approach it (note: prices regularly change and vary by country; these examples are based on current pricing in one market):

App name	Annual price	Lifetime price	Lifetime price x annual
Calm	$79	$399	5.0x
Jumpspeak	$69	$249	3.6x
Moonly	$28.98	$59.98	2.1x
Fiit	£119.99	£375 (£299 on offer)	3.1x (2.5x on offer)
Placify	$14.99	$49.99	3.3x
Waking Up	$129.99	$1500	11.5x

To determine where your lifetime subscription should sit within that range, consider:

Annual pricing
Annual churn
Gross margin
Your category and retention patterns

Strong retention and low margins generally allow for higher pricing. It’s also worth examining your LTV by cohort, not just the average:

How are recent customers retaining?
How do the most active customers retain, and what is their LTV?

This approach helps ensure you don’t cannibalize your own revenue by pricing too low.

If in doubt, I’d always recommend going higher rather than lower, like Waking Up, the meditation app, does. I struggled to find their lifetime subscription offer (more on why that is a good thing later), but the Wall Street Journal reported that they charged $1,500 for their Lifetime Subscription — more than 11x their annual price. This ensures it only convinces the most loyal of customers. and is worth it for Waking Up.

2. Which audience to target and where you’ll promote it

Your target audience is closely tied to pricing strategy. My hypothesis: Waking Up aims to convert its most loyal customers, while Calm uses lifetime subscriptions more as a churn-reduction or holiday offer, pricing it lower at about 5x their annual subscription.

Knowing your target also helps determine where to promote the offer. Most lifetime offers aren’t prominently featured on the app’s paywall. Instead, they are often sent via email or promoted as a one-off opportunity.

In some cases, apps consciously offer lifetime subscriptions to all users as part of their strategy. This is common for utility-style apps, like Placify, a personal mapping app:

And Moonly, a moon phases and calendar app. For apps where pricing is relatively low or usage fluctuates month-to-month, lifetime subscriptions can be a standard part of the offering, rather than a limited-time promotion.

In reality, the most Lifetime Offers I’ve seen and received have been through email, like Fiit, the fitness app:

In this case, it felt like a win-back attempt, as I had just canceled my subscription. Overall, I’d recommend testing your lifetime offer first via owned channels — email, push, or in-app notifications — before promoting it more broadly. Of course, the approach will depend on which audience you plan to target.

3. Your terms and conditions

Not the most exciting part, but absolutely critical to prevent lifetime subscriptions from backfiring. (Quick disclaimer: this is not legal advice! This is where you get legal involved.)

It’s important to think through considerations like:

Which plan do they receive (if you have multiple tiers)
Whether it can be combined with other discounts (I’d advise against it)
How major future changes to the app are handled
How does the transition work from subscription to lifetime

The second point is especially important. For example, if you offer family plans on lifetime subscriptions, users could end up getting far more value than you intended, cutting into your revenue.

4. Determine your test strategy

By now, you should have a good sense of your initial lifetime subscription test strategy:

How to price it: don’t be afraid to A/B test different multipliers (5x vs. 8x vs. 12x annual) and track not just conversions, but who converts

Who sees it: start by targeting lapsed users or segments with low retention rates
When to show it: test seasonal promotions (Black Friday, New Year’s Day etc.) before deciding whether to make it evergreen

However, there is still one key final part to work out: how can you measure its success?

It’s nearly impossible to know what those customers would have spent otherwise, and you’re likely working off a predicted LTV for the cohorts you’re comparing it to.

Instead, you want to be looking at:

Conversion rate: how does it convert compared to other offers, and which segments are converting?
ARPU vs similar cohorts: are you earning more or less than you would have with traditional subscriptions?

It’s also worth monitoring:

Engagement of lifetime subscribers: paid users who don’t engage are less likely to advocate for your app
Refunds and customer support load: watch for double payment issues and keep an eye on refund requests and support volume
Mix of revenue: track the percentage of revenue from lifetime vs. subscription — too high a share of lifetime revenue could compromise compounding MRR in exchange for short-term cash

Finally, start testing through your owned channels and keep it smaller or temporary. This allows you to fine-tune, learn from early data, and optimize before a full rollout.

So, was my Calm lifetime subscription worth it?

For me, yes. Buying Calm for life removed the mental load of one more subscription, and even years later, I still feel like I got a bargain. But that’s the key: lifetime subscriptions usually feel like a win for the customer, not necessarily the brand.

If Calm had kept me on an annual plan, they’d likely have earned significantly more from me by now. Instead, they traded long-term revenue for upfront cash, which may have made sense at the time to fund new features, celebrity narrators, and all the content they’ve since built.

That’s the trade-off every app faces. Lifetime subscriptions can unlock cash when you need it, build loyalty, or help smaller apps stand out against bigger players. But they can also cannibalize your most valuable customers, limit upsell opportunities, and create operational headaches that last for years.

If you’re considering lifetime subscriptions, run the numbers, test carefully, and know who you’re really building it for. Because when your customer is thinking, “What a deal!”, you need to be absolutely sure you’re thinking the same on your side.