How to build a subscription paywall that converts (without feeling sleazy)

Why most paywalls fail

The typical indie app paywall appears on the second or third screen after install. The user has been in your app for maybe fifteen seconds. They haven't done anything yet. They don't know what your app does in practice, only what your App Store screenshots promised. And now you're asking for $4.99 per month.

From the user's perspective, this is like walking into a restaurant, sitting down, and being asked to pay before seeing the menu. It doesn't matter how good the food is. The timing is wrong.

The apps with high-converting paywalls do something different. They let you use the app first. They let you create something, or save something, or get attached to something. Then they ask you to pay to keep it. The difference in conversion rate is usually 3-5x.

When to show it matters more than how it looks

There are really only three moments where a paywall makes sense:

After a small win. The user just completed their first workout, created their first document, tracked their first expense. They've gotten value. Now you can say "want more of this?" This is the highest-converting placement for most apps.

When they hit a real limit. Not an artificial gate on the third screen, but a genuine boundary. They've used all five free entries this month. They want to export their data. They need the feature that only makes sense for power users. This feels fair because the limit is connected to real usage.

During onboarding, but only if your free trial is genuinely free. Some apps (fitness, meditation, language learning) show the paywall early because the trial gives full access with no commitment. If your "free trial" requires a credit card upfront, you're not really offering a trial. You're gambling that people will forget to cancel. Apple has been cracking down on this pattern, and users have learned to distrust it.

What goes on the paywall screen

Once you've picked the right moment, the actual paywall screen needs to do three things: remind them what they're getting, make the price feel reasonable, and make it easy to say yes.

Lead with what they've already done. If someone just tracked three days of meals, your paywall should say "Keep tracking your nutrition" not "Unlock Premium Features." The best paywalls reference the user's own data. "You've logged 12 workouts this month" is more persuasive than any feature list because it reminds them they're already invested.

Three benefits, not fifteen features. Nobody reads a feature checklist on a paywall. They glance at it for two seconds. Pick three things that matter most and describe them in terms of outcomes, not capabilities. "See which foods affect your energy" beats "Advanced nutrition analytics dashboard."

Show the daily price. "Less than a cup of coffee per week" is a cliche, but the underlying idea works. A $49.99/year subscription sounds expensive. $0.96/week sounds like nothing. RevenueCat and most paywall SDKs let you display this automatically. The annual plan should always show the per-week or per-month breakdown next to the total.

How to lay out your pricing options

Most apps offer two or three tiers on the paywall: monthly, annual, and sometimes a lifetime option. The layout matters more than people think.

Default to annual. Pre-select the annual plan. Most users will go with whatever's pre-selected, and annual subscribers churn at roughly half the rate of monthly ones. If you only show the monthly price prominently, you're leaving money on the table and setting yourself up for higher churn.

Show the savings on annual. "Save 40%" or "2 months free" next to the annual plan works. People need a reason to commit for a year, and the discount gives them one. The exact percentage depends on your pricing strategy, but somewhere between 30-50% off monthly is standard.

Lifetime purchases are complicated. They attract your most passionate users but kill your recurring revenue. If you offer lifetime, price it at 3-4x the annual price. Anyone willing to pay that much was going to subscribe for years anyway. Too cheap and you're giving away your best customers' future payments. Many successful indie apps skip lifetime entirely and do fine.

Two options usually beat three. Unless you have a clear reason for three tiers (like a lightweight free tier, a standard tier, and a pro tier with distinct audiences), just show monthly and annual. Decision fatigue is real on a paywall. The user is already deciding whether to pay at all. Don't also make them figure out which plan.

Free trials: what actually works

Free trials increase conversion rates when they're structured correctly. The problem is most aren't.

Seven days is usually right. Three days isn't enough for most apps to demonstrate value. Thirty days is too long because people forget why they installed it. Seven days gives enough time to form a habit without enough time to lose interest. Fitness and productivity apps sometimes do well with 14 days because the results take longer to show.

No credit card upfront if you can manage it. Apple allows both models. Requiring a card upfront gets you more trial starts (because they see "Start Free Trial" instead of a price) but also more angry users and more involuntary churn from people who forgot to cancel. The reputation cost is real too. Your App Store reviews will include "they charged me after the trial" complaints, and those reviews affect conversion for everyone who reads them.

Send a reminder before the trial ends. This sounds counterproductive, like you're reminding people to cancel. In practice, it builds trust. Users who feel respected are more likely to convert. A push notification on day 5 saying "Your trial ends in 2 days. Here's what you'll keep with Premium" converts better than silence followed by a surprise charge.

Show what they'll lose. On the last day of the trial, your paywall should reference what they've built. "You've created 8 projects during your trial. Subscribe to keep access." Loss aversion is a stronger motivator than feature lists.

Stop showing the paywall to everyone

One thing that surprised me looking at app data across markets: the highest-converting apps don't show the same paywall to every user. They segment.

A user who opened the app once and never came back doesn't need a paywall. They need a better onboarding experience. Showing them a paywall is wasted effort and creates a negative impression.

A user who's been active for a week and uses the app daily is much more likely to convert. They've already decided the app is useful. The paywall just needs to formalize that decision.

The simplest version of this: don't show any paywall until the user has completed at least one core action. Track this with a boolean flag. If they haven't done the thing your app is for, they're not ready to pay for it.

More sophisticated apps use engagement scoring to decide when to show the paywall. Users with 3+ sessions get the full paywall with annual pre-selected. Users with 1 session get a softer prompt with a free trial offer. Users who came from a specific ad campaign might see different pricing. This requires some analytics work, but even a basic version (new vs. returning) makes a meaningful difference.

Design details that move the number

After timing and copy, the actual visual design of your paywall has a smaller impact than most people assume. But a few details consistently matter.

Make the close button visible. If users feel trapped, they leave the app entirely. A clear X in the corner or a "Not now" link at the bottom reduces anxiety. Apple will reject apps that make it hard to dismiss the paywall anyway, so don't fight this.

Match your app's design language. A paywall that looks like it was dropped in from a template (and many are) feels disconnected. Use your colors, your fonts, your visual style. The paywall is part of your product, not an interruption from it.

Put the CTA button where thumbs go. On phones, the bottom third of the screen is where people tap most comfortably. Put your subscribe button there. This sounds basic, but I've seen indie apps with the subscribe button halfway up the screen, above the fold of a scrollable feature list that most people never scroll through.

Use social proof sparingly. "Join 10,000 subscribers" works if you have 10,000 subscribers. Making up numbers or inflating them destroys trust with exactly the kind of careful user who checks. If you're early stage, skip social proof on the paywall and use it on your App Store listing instead, where review counts provide natural credibility.

Implementation: RevenueCat vs. rolling your own

If you're building your first subscription app, use RevenueCat. The free tier handles up to $2,500/month in tracked revenue, which is more than enough for most indie apps at launch. The alternative is implementing StoreKit 2 or Google Play Billing directly, handling receipt validation, managing subscription states across platforms, and building your own analytics. I've seen solo developers spend weeks on this. It's not where you want to spend time as covered in our tech stack guide.

RevenueCat also gives you remote paywall configuration, which means you can change pricing, trial length, and layout without shipping an app update. This matters because paywall optimization is iterative. You'll want to test different approaches, and waiting for App Store review each time kills your iteration speed.

One thing to watch: RevenueCat's Paywalls feature (their pre-built paywall UI) is convenient but limited in customization. For your first version, using their SDK for purchase handling but building your own paywall UI gives you more control. You can always switch to their templated paywalls later if you want to run faster A/B tests.

What to test (and what not to bother testing)

A/B testing paywalls is where most indie developers either go overboard or don't bother at all. Here's what actually moves conversion:

Test paywall placement first. After onboarding vs. after first value moment. This single change has the biggest impact on conversion. If your current rate is under 3%, test moving the paywall later in the flow before changing anything on the paywall itself.

Test trial length second. Seven days vs. fourteen days vs. no trial. This is the second biggest lever. Some apps discover that no trial with a lower price converts better than a trial with a higher price. You won't know without testing.

Test pricing third. The common fear is "what if my price is too high?" More often, indie developers price too low. Try testing a higher price point. If conversion drops 10% but revenue per user goes up 30%, the higher price wins. Your pricing structure and your paywall are two parts of the same equation.

Don't bother testing button colors. Or background images, or the exact wording of your feature bullets. These changes produce results within noise for apps with fewer than 10,000 monthly paywall impressions. You need statistical significance to learn anything, and most indie apps don't have the volume for micro-optimizations to matter. Spend that energy on the big levers instead.

Paywalls in different markets

If your app serves multiple countries, your paywall probably needs to work differently in each one. This isn't just about translating text.

Users in Japan tend to prefer monthly subscriptions over annual commitments. Users in the US are more comfortable with annual plans, especially with a visible discount. Users in Southeast Asia often have lower willingness to pay but higher engagement, which means a longer free tier with consumption-based upgrades might work better than a flat subscription.

Apple's regional pricing tiers don't always correspond to actual purchasing power parity. A $4.99/month subscription in the US becomes roughly equivalent in countries where $4.99 represents a much larger share of disposable income. Some indie developers create separate price tiers for different regions using Apple's price point system. Our geo-arbitrage scanner identifies apps that succeed in specific regions partly because they've nailed the regional pricing.

One practical tip: if your app has significant downloads in non-English markets, run a separate paywall A/B test for your top 2-3 countries. What converts in the US often doesn't convert in Germany or Japan, and the paywall is usually where the gap is widest.

Mistakes I keep seeing

After looking at hundreds of indie app paywalls through our scanner data, some patterns keep repeating:

Gating basic functionality. If your free tier is so limited that users can't figure out whether the app is useful, they'll leave before they hit the paywall. The free tier needs to be generous enough that people understand the value. Then the paid tier extends that value.

Showing the paywall on cold open after an update. Existing users who just updated your app don't want to see a paywall. They were already using the app. Showing them a paywall feels like you're taking something away. If you're launching subscriptions in an app that was previously free or one-time purchase, grandfather existing users or at minimum don't ambush them with it. This is a top source of angry reviews.

Requiring subscription for features that feel like they should be free. Cloud sync, dark mode, and basic customization used to be paid features. User expectations have shifted. Gating these creates resentment, not revenue. Gate things that represent ongoing cost to you (server-side processing, AI features, cloud storage) or that genuinely cater to power users.

Not explaining what happens after the trial. Apple requires this legally, but many apps bury it in fine print. Be explicit: "After your 7-day free trial, you'll be charged $49.99/year. Cancel anytime in Settings." Clarity converts better than ambiguity because it removes the last objection ("what if I get stuck?").

One paywall for every context. The paywall someone sees when they tap on a locked feature should be different from the one shown during onboarding. The feature-tap paywall can be focused: "Export to PDF requires Premium." The onboarding paywall needs to sell the whole package. Same price, different pitch.

Measuring your paywall

The number most people look at is paywall conversion rate: people who subscribe divided by people who see the paywall. This is useful but incomplete. You need to track the full funnel.

Install to paywall view rate. What percentage of people who install your app ever see the paywall? If this is under 50%, your onboarding has a bigger problem than your paywall. People are leaving before they get to it.

Paywall view to trial start rate. If you offer trials, how many people who see the paywall start a trial? Low rates here mean the paywall isn't convincing them to try.

Trial to paid conversion rate. Of people who start a trial, how many convert to paid when the trial ends? Low rates here mean the trial period isn't demonstrating enough value. Either the trial is too short, the app isn't engaging enough, or the paid features aren't differentiated from what's free.

Paywall view to immediate purchase rate. For users who buy without a trial, what's that rate? Compare this to the trial path. Sometimes the direct purchase path converts better overall because the users are more intentional.

Track these in your analytics setup as a funnel. The number that's lowest relative to benchmarks is where you should focus your optimization effort.

What "good" looks like

Benchmarks vary by category, but here's a rough guide from what we see across apps in our data:

Paywall conversion rate (view to purchase or trial start): 2-4% is typical for indie apps. 5-8% is good. Above 10% is exceptional and usually means your timing and targeting are dialed in.

Trial to paid conversion: 40-60% is healthy for a 7-day trial. Below 30% means the trial isn't demonstrating value. Above 70% might mean your trial is too restrictive (people convert because they have to, not because they want to, which can hurt retention later).

Install to subscriber (end-to-end): 1-3% for most apps. The best subscription apps hit 5-7%. These numbers feel low, and they are. That's why your revenue model needs to account for lifetime value, not just initial conversion. A 2% conversion rate with a $49.99/year subscription and 12-month average retention is a real business. A 10% conversion rate with a $0.99/month subscription and 3-month average retention is not.

Start with timing, not design

If you take one thing from this: move your paywall to after the user has gotten value from your app. That single change will do more for your conversion rate than any amount of copy tweaking or design polish.

After that, default to annual pricing, show a clear close button, and don't gate things that feel like they should be free. These four changes cover 80% of what separates good paywalls from bad ones.

The remaining 20% is iteration. Test placement, test trial length, test pricing. Track the full funnel, not just the conversion rate. And remember that your paywall is downstream of your product. The best paywall in the world won't save an app that people don't want to use.

If you're still in the earlier stages, figuring out whether your idea has legs or building your first MVP, the paywall can wait. Get people using the app first. The paywall is the last thing you build and the first thing you optimize. And if your retention numbers look off even before the paywall, start with the broader reasons users delete apps before tuning conversion.