How to pre-sell app subscriptions on the web before launch

TL;DR: Selling your subscription on the web before your iOS or Android app hits the stores let’s you (1) keep the 15-30% that Apple and Google normally take, (2) convert your audience faster — no app install friction, and (3) validate demand (and fund development) with real money in the bank.

Below is a step-by-step playbook with examples, rules, and an MVP flow using RevenueCat redemption links — so you can do it too

Why bother pre-selling subscriptions to your app?

A lot of apps are built for an owned audience: Big brands launch new apps for their existing fanbase, popular newsletters build an app for their subscribers, influencers launch something to engage the audience they built on YouTube, Instagram, or TikTok, you build something for a popular Reddit community. In a lot of those cases, pre-selling subscriptions for their app — during, or even before development — has substantial benefits

Save on platform fees

When a customer buys through a web checkout you pay little more than a standard card-processing fee — usually around three per cent — rather than the 15-to-30 per cent commission Apple and Google collect on in-app purchases. Over twelve months that difference compounds into real runway: a $99 annual plan sold on the web nets about $96, whereas the same plan sold exclusively in-app can drop as low as $69 after store fees

Higher first-touch conversion

Every extra step — App Store click, download, first-launch sign-up, in-app paywall — leaks prospective customers. A web landing page with a single “Subscribe now” button lets interested visitors complete the transaction immediately, then install the app later as part of onboarding. By separating “purchase” from “install,” teams routinely see higher paid-conversion rates from the same ad spend or email blast

Early validation and cash-flow

Pre-selling turns a hypothesis into a balance-sheet line item. Revenue arrives while the product is still in beta, providing both direct capital for continued development and concrete evidence that the market values what you’re building. Early subscribers often become a feedback community as well, giving you real usage insights before the wider App Store launch. Additionally, Stripe, Paddle, Adyen and the likes tend to pay out faster, and at a higher frequency than the app stores do, leading to money in your pocket, faster

🚨 A quick note on Apple’s latest rule changes

There’s been a lot of noise lately around Apple now allowing external payment links inside U.S. iOS apps. That’s a big deal for live apps, but not really the point of this post. What we’re talking about here — using the web to sell subscriptions before your app is live on the App Store or Google Play — has always been allowed. No new rules required. This approach works globally, it’s fully compliant, and it can give you confidence (and early revenue) long before you’re live in any app store.

Examples of successful web-based pre-sales for subscription apps

The Pump

Shippy-winner The Pump is a fitness app by Arnold Schwarzenegger, tying into his popular Pump Club newsletter and community. The app’s closed beta was limited to 5,000 founding annual subscribers (at $99.99 a year), which sold out within 72 hours for total sales of half a million dollars, before the app launched. The spots vanished so fast, the team was forced to post an apology newsletter titled “The app sold out – what’s next”

Marvel Move

The fitness-via-storytelling company behind Zombies, Run! Partnered with Marvel on their Marvel Move app: An app that makes your runs part of the Marvel universe. Weeks before the app would actually launch, they offered a limited Founders Club: $99 up front bought you two full years of subscription (something Apple’s annual-only IAP can’t do), plus private live-streams with the writers. This feels like a deal compared to the $74.99 / year in-app price, though — as discussed at length in this year’s State of Subscription Apps report — less than half of your annual subscribers will actually renew

Fluent Forever

Almost half a million Kickstarter dollars for subscriptions in a language-learning app that didn’t exist yet. Thousands of backers supported Gabriel Wyner’s project on its Kickstarter campaign page, and two years later they redeemed their perks inside the launched app. In this case, the pre-sale functioned as both a seed round and a waitlist

Countless fitness influencers…

Building an audience on Instagram, starting a mailing list, sending workout PDFs, maybe opening a webshop with supplements and drop-shipped workout gear, before launching an app is such a tried and true playbook that there are whole agencies dedicated to building just fitness influencer apps. Increasingly, these influencers pre-sell these apps during development, often by bundling with some of their other initiatives: Pre-subscribe to the upcoming app, and we’ll send you these 5 PDF’s usually priced at $9.99 each, or buy this ‘Founder Bundle’ from my webshop and get some gear along with your early access to the app

When does pre-selling app subscriptions on the web make sense (and when doesn’t it)?

Good fit

• You already have a fanbase, email list, community, or influencer following
• Your value prop is easy to understand without a demo (workout plans, meditation content, fiction writing, streaming video, etc)

Probably skip

• Casual games or impulse-buy utilities, where users expect instant gratification in-app
• Apps aimed purely at organic store discovery with no off-store funnel
• Apps where Family Sharing is central to UX (those only work with IAP)

App Store and Google Play compliance in 2025

The short version: whatever your app does, selling on the web is always allowed; advertising that purchase path inside the app is where the guard-rails appear

Apple App Store

Apple’s rule-of-thumb is simple: if the app itself sells “digital goods or services,” you must use In-App Purchase (Guideline 3.1.1). Two long-standing carve-outs make web pre-sales workable:

• Reader-app or SaaS companion — Under Guideline 3.1.3 (f) a free iOS build that merely lets users sign in to content or functionality paid for elsewhere is allowed. Think Dropbox, Slack, or Netflix: login screens are acceptable; on-device checkout buttons are not
  
• External Link Account Entitlement — Reader apps (books, video, music, and a few other categories) can now include one “Manage or create account” link that opens Safari. Apple still prohibits price mentions or persuasive language (“Save 30 % on the web!”), and the entitlement disqualifies you from offering any IAP products in the same app

Apps using either exception must avoid “steering” users toward web payment. In practice that means the first screen is a neutral login (optionally a limited free preview), and any wording about how to subscribe lives on your website, in email, or paid marketing — not inside the app bundle. Apple reviewers will also look for minimal baseline functionality; an app that is 100 % blank without a paid account risks rejection, so consider including read-only content, a demo workout, or similar

Note that per May of ’25, Apple had to drop their anti-steering provisions for US-based users, so for your customers that access your app from the US App Store front, you’re able to add a web purchase button to your paywalls

Google Play

Google’s policy mirrors Apple’s in spirit: digital subscriptions sold inside an Android app must go through Google Play Billing. Since 2023, however, two programmes give developers limited flexibility:

• User Choice Billing pilot — selected global partners (e.g., Spotify, Bumble) can present their own checkout alongside Google’s. Participation is invitation-only for now
  
• External Offers programme (EEA) — to comply with the EU Digital Markets Act, developers serving European users may display a clearly labelled link that navigates out to a web purchase flow, provided they follow Google’s mandated disclosure screen and agree to a reduced service fee

Everywhere else, the safest pattern mirrors iOS: release a login-only build, let marketing channels drive customers to the web, and keep the apk free of overt calls to pay outside Play Billing

Practical takeaway

At the time of writing (April 2025) neither platform forbids you from pre-selling subscriptions on the web before launch, nor from honouring those subscriptions inside the app. The restrictions apply only to how prominently the app itself can direct users to external payment pages. Ship a companion build that:

1. Lets existing subscribers authenticate
2. Offers some basic, non-pay-walled functionality
3. Saves all pricing and purchase CTAs for the browser or email

…and you’ll clear review on both stores while retaining the revenue margin earned on the web

(Policies evolve; review the latest App Store Review Guidelines and Google Play Payments Policy before each release. This is definitely not legal advice)

Implement and launch pre-sold app subscriptions in minutes with RevenueCat redemption links

When you don’t offer a web-based app experience (folks can’t log into a website to access their content), redemption links are a quick way to pre-sell subscriptions that avoid building a bunch of backend logic from scratch. All you have to do is:

1. Configure products in RevenueCat and connect Stripe
2. Embed the web SDK on your marketing site to enable inline purchases OR use a RevenueCat-hosted web paywall link (no user account is required at purchase time for either)
3. We’ll email a redemption link immediately after payment
4. Handle the deep link in the app with minimal code and the RevenueCat SDK: the link binds the purchase to the anonymous app_user_id and unlocks entitlements on first launch

The engineering efforts involved are a few lines of JavaScript on the web (if you’re hosting the page yourself), one deep-ink listener in Swift/Kotlin (that comes with the SDK), and minimal UI to confirm premium status. Account creation can remain optional; many teams prompt for email-and-password only after the entitlement is active. If you want to have it available from day one, you simply save app_user_id <> email after first open (you can send the email address to RevenueCat and we’ll store that association for you)

Technically, you can start selling subscriptions using web paywall links with nothing more than a RevenueCat and Stripe account. No app or self-hosted website necessary

Do note that if you pre-sell a recurring subscription through this method, the subscription starts the moment the user completes the purchase, rather than when they open the app

Implement and launch pre-sold app subscriptions yourself (without RevenueCat)

A custom Stripe or Paddle stack requires:

• A secure backend that maps purchases to user IDs;
• Webhook handling for renewals, cancellations, and charge failures;
• An entitlement API that the app calls on every launch;
• Ongoing compliance (VAT, dunning, pro-rates)

Pro: zero RevenueCat fees, total flexibility. Con: 2-4 weeks of engineering and ongoing maintenance

In practice, the engineering time and maintenance overhead is reason to at least start with a managed solution and revisit the “build vs. buy” conversation later

Closing thoughts

I’m bullish on the app stores as a way to discover and pay for content. It’s low friction, hundreds of millions have been conditioned to trust the process, and — as a frequent customer myself — it’s transparent and controllable. I like pre-selling on the web because it doesn’t replace Play or App Store distribution: It complements it. By capturing revenue early, you validate demand, fund development, and arrive in the stores with a paying community instead of an empty funnel. Whether you use RevenueCat’s redemption links or a custom Stripe build, the playbook is proven. The opportunity now is to decide where those first subscription dollars land: in your Stripe dashboard or in a platform commission report. If you’re leaning toward the former, the best time to start is before the next line of code — your future users are already waiting to pay