Paywalls
Mandatory Content Standards
Every output from this skill follows these standards without exception.
- Match output length to the skill, request, and deliverable type. Use concise answers for quick checks, structured detail for audits and plans, and full-length output only when the user asks for a complete deliverable.
- Write in a way that sounds like a knowledgeable human wrote it. No robotic or templated phrasing.
- Use short sentences. One idea per sentence. One focus per paragraph.
- Use active voice. Never passive constructions.
- Address the reader directly using "you" and "your."
- Use bullet points only when they genuinely improve readability.
- Replace all em dashes with commas, parentheses, semicolons, or a new sentence. No hidden Unicode characters.
- End every sentence with a period.
- No hashtags, emojis, or asterisks.
- No introductory or closing filler phrases such as "in conclusion," "in summary," or "in a world where."
- No warnings, notes, or disclaimers. Stick to requested output.
- No AI cliches: no "game-changer," "unlock," "leverage," "dive into," "delve," "cutting-edge," "transformative," "revolutionize."
- No excessive adjectives or adverbs. Let specifics do the work.
- No broad generalizations. Every claim tied to specific context.
- Use specific examples, data, and scenarios.
- Pose at least one thought-provoking question per skill.
- Mobile-friendly: short paragraphs, clear headers, scannable.
- Practical and actionable. Every section connects to a next step.
What This Skill Does
This skill helps you create and improve in-app paywalls, upgrade screens, upsell modals, and feature gates. It covers the copy, design principles, timing, and measurement for every type of upgrade moment inside your product.
Paywalls are distinct from public pricing pages. A public pricing page is read by someone who has not yet signed up. They are evaluating whether to commit. A paywall is shown to someone who already uses your product, has experienced value, and is encountering a limit or gate. The psychology is completely different, and the approach should be too.
The question worth sitting with: at the moment your paywall appears, what does the user believe your product is worth to them?
How to Use This Skill
Bring your paywall problem with this context:
- What type of paywall is it? (Limit-reached, feature-gated, trial expiration, usage cap, team seat limit.)
- What is the feature or limit that triggers the paywall?
- What plan does the paywall ask users to upgrade to?
- What is the current conversion rate of this paywall, if known?
- What is the user's typical experience just before seeing this paywall? What were they doing?
The moment just before the paywall is the most important context. A user who just hit a limit while doing something productive is in a completely different mental state than a user who saw a locked feature in the navigation. Copy and design should match that state.
The Psychology of In-App Paywalls
When a user sees a paywall inside a product they already use, they are not deciding whether to trust you. They already trust you enough to use the product. They are deciding whether the gated value is worth the price.
This changes everything about how you write paywall copy. You do not need to sell your brand. You need to sell the specific thing they are being asked to pay for, at the specific moment they want it.
The most effective paywalls share four characteristics:
They appear at the moment of maximum motivation. The user wants to do something specific. The paywall appears between them and that thing. Their desire to complete the action is at its peak. This is the ideal moment to present an upgrade offer.
They show the user what they get, not what they are missing. "You've reached your free limit" focuses on the loss. "Get 10x more reports with Pro" focuses on the gain. Both are true, but the second one frames the upgrade as a positive choice.
They make the price feel proportional to the value. A user who just invested an hour building a project in your tool and hits a paywall is more willing to pay than a user who has barely started. The perceived value of the upgrade is tied to their current investment.
They reduce friction to zero at the decision point. One click to upgrade. Pre-filled payment if possible. No diversion to a new page if you can help it. Every additional step loses a percentage of the users who would have converted.
Paywall Types and Copy Frameworks
Limit-Reached Paywalls
A limit-reached paywall appears when a user hits a usage cap. They have sent 100 emails, created 5 projects, added 10 users, or used 1GB of storage.
These are the highest-converting paywall moments because the user has demonstrated they want more of the thing. They are not speculating about whether they will need it. They know they need it right now.
Copy framework for limit-reached paywalls:
Headline: acknowledge what just happened and frame the next step positively.
"You've filled your free workspace. Here's how to keep going."
Not: "You've reached your free plan limit."
Subheadline: name the specific thing they will gain by upgrading.
"Pro gives you unlimited projects, plus priority support and team sharing."
Social proof: one short line from a user in their situation.
"Teams that upgrade to Pro create an average of 43 projects in their first month."
CTA: action-oriented, specific.
"Upgrade to Pro, $29/month" is better than "Upgrade now."
Secondary option: give users a way to continue without upgrading, if your product allows it. "Or delete a project to free up space." This reduces the feeling of being forced and paradoxically increases upgrade rate in many products.
Feature-Gated Paywalls
A feature-gated paywall appears when a user clicks on a feature that is not available on their current plan. They have not hit a limit. They are reaching for something they have not experienced yet.
These paywalls are harder to convert because the user has not yet felt the value of the feature. You are asking them to pay for something they only know about conceptually.
Copy framework for feature-gated paywalls:
Headline: name the specific outcome, not the feature name.
"Custom reporting lets you see exactly where your team is spending time."
Not: "Upgrade to access Custom Reports."
Show the feature: if possible, show a screenshot, video preview, or demo of the feature in action. The user needs to visualize the value they are buying.
Use case: give one concrete example of how a user like them uses this feature.
"Marketing teams use custom reports to cut their end-of-week report from 4 hours to 20 minutes."
Upgrade path: show the specific plan that includes this feature and its price.
The question you should ask when designing any feature-gated paywall: can the user understand what this feature will do for them from the paywall alone, without having to upgrade and discover it?
Trial Expiration Screens
A trial expiration screen appears when a user's free trial is about to end or has just ended.
These screens have two modes: pre-expiration (still within the trial) and post-expiration (the trial has ended). They require completely different copy.
Pre-expiration copy: the user still has access. Your goal is to convert them before they lose access. Use loss aversion framing.
"Your trial ends in 3 days. Keep everything you've built."
Then: summarize what the user has created or accomplished during the trial. "You've created 8 reports, connected 3 data sources, and saved 6 hours of manual work." This uses sunk cost psychology: the user has built something and does not want to lose it.
Post-expiration copy: the user has lost access. They are now in a different emotional state. Do not lecture them. Make reactivation as frictionless as possible.
"Your trial ended on May 14. Reactivate your account to pick up where you left off."
Show exactly what they will get back. Make the reactivation one click.
Do not guilt. Do not list everything they are "missing." One simple, clear path back in.
Annual vs. Monthly Framing in Paywalls
When your paywall offers both monthly and annual billing options, how you frame them dramatically affects which one users choose and whether they convert at all.
Default to annual. Show annual pricing first, as the primary option. Monthly is the secondary option. Most users anchor to the first price they see. If they see $290/year first, $29/month feels expensive by comparison. If they see $29/month first, $290/year feels large.
Show the savings in dollar terms, not percentage. "Save $58 per year" is more concrete than "Save 17%." Concrete numbers feel real.
Show monthly equivalent for annual plans. "$24/month, billed annually" is the standard way to present this. It makes the annual plan feel like a monthly decision, which reduces the psychological weight of the larger payment.
Put the annual plan in the default or recommended position. Visual hierarchy matters. Whatever is shown first or marked as "recommended" gets more attention.
Plan Comparison Design Inside Paywalls
Many paywalls show a comparison between the user's current plan and the upgrade plan. This comparison is often the moment that makes or breaks the conversion.
What to show in a plan comparison:
Focus on the three to five benefits most relevant to the user's current moment. Do not show a full feature matrix inside a paywall. It overwhelms and creates decision paralysis.
Lead with the outcome the user was just trying to achieve. If they hit a project limit, the first comparison row should be about project limits. If they were trying to use a reporting feature, lead with reporting.
Use plain language, not feature names. "Unlimited projects" is clear. "Advanced workspace management" is not.
Contrast the current state with the upgrade state explicitly. "Free: 5 projects" followed by "Pro: unlimited" is more persuasive than just "Pro: unlimited projects" because it makes the user feel the gap.
Avoid putting price at the top of the comparison. Put it after the value has been established. Price at the top makes users evaluate cost before understanding value.
Upgrade Trigger Timing
Timing determines whether a paywall converts or annoys.
The best paywall timing: the user is in the middle of doing something valuable and hits a natural stopping point that requires the upgrade to continue.
The worst paywall timing: the user is just browsing, has not yet experienced value, and encounters a locked feature they were not actively trying to use.
The rule: show a paywall when the user has just demonstrated they want something. Not before. Not speculatively.
This has implications for feature gates. Do not show a locked feature in your navigation with a lock icon, visible to all free users all the time. This approach creates a constant low-level reminder of limits without triggering at a moment of motivation. It trains users to think of your product as something that holds things back.
Instead, reveal gated features in context, at the moment the user would naturally want them. If advanced filtering is gated, show a free user the filter panel with basic options. When they try to add a condition that requires a paid plan, show the paywall then. They are motivated at that exact moment.
Freemium Conversion Psychology
Freemium models work when the free tier is valuable enough to attract users but limited enough that real users hit limits. Finding that balance is a product strategy decision, not a marketing one. But once you have the balance, your paywall copy determines how many users cross the line.
The mistake most freemium products make in their paywall copy: they list features. "Upgrade to Pro to get advanced analytics, team collaboration, custom workflows, and priority support."
The problem: none of those feature names means anything to a user who has never experienced them. You are asking someone to pay for concepts.
The alternative: use outcome language tied to the specific thing the user was trying to do.
"Your team needs to work on this project together. Pro gives every teammate full editing access, real-time updates, and a shared activity feed. No more emailing files back and forth."
This works because it translates "team collaboration" (a feature name) into "what this actually means for your workday" (an outcome the user cares about).
Another principle for freemium paywalls: never make the user feel bad for using the free plan. The free plan is why they are in your product. Shaming them for using it ("You're on the limited free plan") creates resentment, not motivation.
Measuring Paywall Conversion Rates
Your paywall conversion rate is the percentage of users who see a paywall and convert to paid within a defined window (typically 7 or 30 days).
How to set up paywall measurement:
Tag every paywall appearance as an event in your analytics. Include which paywall type appeared (limit-reached, feature-gate, trial expiration) and what the user was doing before it appeared.
Tag every conversion. Track whether a user upgraded within 7 days of seeing a specific paywall type.
Calculate conversion rate by paywall type. Your limit-reached paywall will likely convert at a different rate than your feature-gate paywall. They should be measured and optimized separately.
Track what happens to users who see a paywall and do not convert. Do they churn? Do they return to the free tier and continue using the product? Do they hit the paywall again later and convert then? This tells you whether the paywall is an opportunity or a churn trigger.
Benchmarks: in-app paywall conversion rates vary widely by product and pricing. A reasonable benchmark for a limit-reached paywall in a well-optimized product is 5-20% of users converting within 30 days of seeing it. Feature-gate paywalls typically convert at lower rates because the user has not yet experienced the value.
A/B Testing Paywalls
Paywalls are some of the highest-leverage things to test in a SaaS product because even small conversion rate improvements at this stage have large revenue impact.
What to test:
Headline framing: test gain framing versus loss framing. "Get unlimited projects" versus "Don't lose your work when you hit your limit."
Price presentation: test monthly versus annual as the default. Test showing savings as dollars versus percentages.
Feature emphasis: test which three to five features you lead with. Different users may respond to different benefit emphasis.
Paywall timing: test showing the paywall at the exact limit versus showing a "you're approaching your limit" prompt one step before.
CTA copy: "Upgrade to Pro" versus "Start my Pro trial" versus "Keep going with Pro." Each creates a different frame around the action.
Design layout: test showing plan comparison versus showing a single plan. Test showing social proof versus not.
How to run a valid paywall test:
Ensure you have enough traffic to reach statistical significance. Most paywall tests need at least 200-500 paywall views per variant.
Run the test for a full business cycle (at least two weeks) to account for variation by day of week.
Measure both short-term conversion (did they upgrade immediately) and 30-day conversion (did they upgrade within a month). Some copy changes shift timing without changing total conversion.
Common Paywall Mistakes
Showing the paywall too early: before the user has experienced meaningful value, any paywall creates resentment. The user thinks "this product is just trying to get my money," not "I want more of this."
Feature-listing instead of outcome-selling: listing features does not help users understand the value. Translate every feature into the specific outcome it produces.
Making the upgrade process multi-step: every additional click after the decision to upgrade loses users. If you can complete the upgrade in one click with a saved payment method, do it.
Showing a paywall to users who have already paid: this happens due to authentication bugs or caching issues. It is frustrating and erodes trust. Test your paywall logic regularly.
Ignoring the mobile experience: paywalls on mobile need to fit a small screen, load fast, and have a tap-friendly CTA. A paywall designed for desktop that appears on a phone will underconvert.
Generic copy for every paywall: a limit-reached paywall and a trial expiration paywall are completely different situations. Do not use the same copy for both.
No follow-up for users who dismiss: if a user sees a paywall and dismisses it without converting, what happens next? Most products do nothing. The better approach is a behavior-triggered email 24 hours later that references what they were trying to do.
Paywall Copy Checklist
Before publishing any paywall, run through this:
Does the headline acknowledge the user's current situation? (Not "upgrade now" but "you're ready for more.")
Does the body copy describe specific outcomes, not feature names?
Is the price presented after the value, not before?
Is the CTA copy specific and action-oriented?
Is there at least one piece of social proof that is relevant to the user's situation?
Is the conversion process one click if at all possible?
Have you tested this on mobile?
Do you have analytics tracking the appearance and conversion of this paywall?
Is there a follow-up flow for users who see the paywall but do not convert?