Where a paywall should stop people, and what it should offer

The Pricing work group on value metrics, top-ups, paywall copy, checkout and getting a paywall to the person with the budget.

Updated October 13, 2026

People pay when the wall stops them partway through a job they care about and offers to sell them the thing they're stuck on.

Limit the unit people value. Japna Sethi would put the limit on the metric that tracks value, the way Dropbox's free plan limits storage. Elena Verna says free users should keep running into paid features so the wall never feels like an ambush, and sets a benchmark of at least 15% of pricing-page visitors clicking through to checkout.
Sell a top-up for a burst. Elena says that when Lovable added top-ups next to subscriptions, upgrades fell about 50% while total revenue rose 20%+ and paid retention improved 7%. Kyle Poyar would offer a top-up when a paying or clearly engaged user runs out mid-project for the first time and the next tier is far more than they need to finish the task, and push the plan once they hit the wall two or three cycles in a row. He points to Figma, whose pay-as-you-go AI credits cost 20% more than credits bought through a plan.
Fix the copy and checkout first. Lauryn Motamedi suggests paywall copy that says what the user will get done by upgrading, in place of a list of feature names. Working on trial conversion at Dropbox, she saw a ready buyer lost to an unsupported payment method, so she would break conversion down by country, payment method and plan before touching price. Japna passes on a tip to rename "overages" to "on-demand spend".
In dev tools, find the buyer. Ben Williams recalls a buyer who had the budget but couldn't create a Snyk API key without talking to sales. Snyk's self-serve channel, which let ready teams pay on the spot, grew 65% QoQ. He would judge readiness by usage across an account instead of one engineer, and suggests paywall copy an engineer can forward to whoever approves spend.

Group chat with Kyle, Elena, Japna, Ben, Lauryn — the Pricing work group

Question:

What makes people pay when they hit a paywall?

Elena VernaLeads growth at Lovable. Former SVP Growth at SurveyMonkey

People pay when the paywall stops them halfway through a job they already care about, and the price fits how they actually use the product. If the wall shows up before they've felt any value, all you've built is an exit.

So I'd look at three levers.

Let them taste premium before you take it away. Reverse trials put every new user on the paid plan, then drop them to free. When users have to give back something they already used, they convert far better than when you ask them to imagine what paid might be like. I've seen reverse trials lift freemium conversion anywhere from 10% to 40%. One caveat: if the product is expensive to give away or people don't use it often, a reverse trial is the wrong tool.
Make sure they know what paid gets them before they hit the wall. Too many product teams ship a feature, put it in the paid plan, and never show it to free users. Then the paywall feels like an ambush. Free users should keep running into paid features through the whole journeySpotify. My benchmark is that at least 15% of pricing page visitors should click through to checkoutelenaverna.
Offer a payment option that matches how they use the product. At Lovable, users ran out of credits mid-project and the only way forward was a subscription upgrade, which didn't fit how many of them worked. So we added top-ups on top of subscriptions. Upgrades dropped by about 50%. Total revenue still went up 20%+, ARR stayed on track, and paid retention improved 7%. The people buying top-ups were among our most engaged userselenaverna.

If people bounce off your paywall, check what you're asking them to buy at that moment. Often they want to pay, but only for the thing they're stuck on right then.

Japna SethiDirector of Product at Atlassian. Former Head of Product-led Growth at Productboard

Elena's Lovable top-up story is a value metric story underneath. Credits were the unit people got value from, so the fix was letting them buy more of that unit. I'd start any paywall diagnosis there. Work out what gives value back to the user, find the specific metric that tracks it, and put the limit on that metric

YouTube. Dropbox is the classic case. The free plan limits storage, and storage is exactly what people get value from, so the paywall gets more relevant the more someone uses the product. Even the Space Race referral program paid out 2GB per referral, the same unit as the wall. That program also plateaued after a while, so don't expect any one lever to keep working forever

YouTube.

In B2B the paywall is often a handoff to a person, and the same activation-first rule still applies. At Productboard we got trial users activated on specific key features first. Then we qualified them with firmographic and usage data and routed them to sales, so the rep was talking to someone who already understood what they'd be paying for

YouTube. When we launched the free plan, the team was nervous about what it would do to pipeline. We picked the free-plan limits on purpose and ran the riskiest bets first so we could test those fears with data

amplitude.

Wording at the wall matters more than teams expect. At one of Alvaro's Orb dinners, the PLG leaders talked about pricing as friction you balance against incentives. One tip from that group was that renaming "overages" to "on-demand spend" works very well. That pairs well with Elena's top-ups. If you sell people more of what they're stuck on, call it something that sounds like getting more, and A/B test the copy before you change the price.

Lauryn MotamediFormer VP Growth and Product at Notion and Head of Growth at Airtable

Once someone hits the wall and wants to pay, I've seen conversion leak in two places: the paywall copy and checkout.

The first is the wording on the paywall. At Airtable, the most common onboarding mistake I saw was naming features, like a tooltip that says "this is automations," when we should have shown how the feature helps that user's workflow. Better still was a one-touch option where we set up the automation for them and showed the result. Paywalls make the same mistake with a list of premium feature names. Japna's "on-demand spend" rename fits here, and I'd take it further. When someone hits the wall in the middle of a task, the copy should describe what they'll get done if they upgrade, and if possible let them preview that result.

YouTube

The second is checkout. At Dropbox I worked on trial conversion, helping teams move to premium after trying Dropbox together, and I learned how much the small fixes compound. We made sure people in different markets, with different payment methods and different customer profiles, could all get through the purchase, and we went really really deep in the data to find where each segment dropped off. A user in a market where we didn't accept their usual payment method was ready to buy, and we lost them anyway.

YouTube

I'd check both before touching price. Break paywall conversion down by country, payment method and plan type, because a blended rate hides the segments where the willingness to pay is already there.

Question:

Elena said Lovable added credit top-ups next to subscriptions, and upgrades fell about 50% while total revenue rose 20%+ and paid retention improved 7%. Kyle, when someone hits a usage paywall mid-task, under what conditions would you offer a one-off top-up at that moment instead of pushing the subscription upgrade, and what pricing on the top-up keeps it from cannibalizing the plan?

Kyle PoyarFounder of Growth Unhinged. Former Operating Partner at OpenView

I'd offer the top-up when the overage looks like a burst, and push the subscription when it looks like a new baseline.

My test for a burst:

1️⃣ The user is already paying, or clearly engaged, and runs out in the middle of a project.

2️⃣ The jump to the next tier is far larger than what they need to finish the task.

3️⃣ This is the first time they've hit the limit, so you can't tell yet whether it will repeat.

If someone hits the wall two or three cycles in a row, that's recurring usage. At that point the upgrade is the better deal for them, and the paywall should say so. Elena's data fits this. Her top-up buyers were among Lovable's most engaged users, and retention went up.

For pricing, I like what Figma did. Their pay-as-you-go AI credits cost 20% more than credits bought through a subscription. That's enough of a gap to nudge steady users toward the plan without punishing someone who only needs a one-time burst. Show both prices side by side at the wall, along with the point where the subscription becomes cheaper, so the user can do the math right there.

Two structural fixes cut down on mid-task walls in the first place:

1️⃣ Include enough credits that about 80% of customers get through their first month. The top 10% of customers usually drive 70 to 80% of credit usage, so the wall mostly hits power users.

2️⃣ Move from monthly to annual usage limits. Running out in month one feels like a bait-and-switch, and an annual drawdown smooths out the bursts so you need fewer top-ups.

Where you can, also charge when the usage succeeds, and skip charging the moment someone tries a feature.

Question:

So far the group has described paywalls where the person who hits the wall can also pay: Lovable credits, Dropbox storage, Kyle's burst-versus-baseline rule for top-ups. Ben, in developer tools the engineer who hits the wall often can't approve spend. At Snyk, when the self-serve channel was growing 65% QoQ, what actually got a team to pay at that moment? Was it a seat or team limit, a usage cap, or a handoff to a manager or sales, and what did you try that failed?

Question:

Elena, you said people pay when the wall stops them halfway through a job they care about. Kyle recommends enough credits that about 80% of customers finish month one without hitting a limit, and moving to annual usage limits so bursts get absorbed. At Lovable, would those two changes raise or lower conversion, and what data would tell you the free or entry allowance is too generous?

Elena VernaLeads growth at Lovable. Former SVP Growth at SurveyMonkey

At Lovable I'd expect both changes to lower the upgrade count and raise total revenue. We already ran a version of this test. When we added top-ups, upgrades fell about 50%, total revenue went up 20%+, and paid retention improved 7%. Before top-ups, people did an upgrade-downgrade dance to get through a heavy month. Afterwards they stayed on their plan longer

elenaverna. A bigger allowance and annual limits push in the same direction, toward fewer forced upgrades and longer paid lives. So I'd judge them on revenue per user and paid retention. Conversion rate alone will make them look like a loss.

I'd apply Kyle's 80% rule to paid plans first. At Lovable, every free credit costs real compute, and that's the same reason I warn that reverse trials are the wrong tool when the product is expensive to give away.

The free or entry allowance is too generous when:

Engaged users rarely reach the wall. If your most active cohort finishes real projects and never sees a limit, there's nothing to pay for.
Fewer people reach the pricing page, and engagement and retention stay flat. In that case you gave value away and didn't get usage back.
Pricing-page-to-checkout drops below 15%. That usually means people are browsing out of curiosity because nothing is blocking themelenaverna.

The allowance is too stingy when people hit the wall before they've built or published anything. At that point they haven't felt the value yet, so they leave.

I'd check one more thing: who is hitting the wall. Our top-up buyers sent more messages and published more than average users. When the people hitting the wall are mostly your heaviest users, the wall is in the right place, whatever the conversion rate says.

Question:

Elena's test is that the wall is in the right place when your heaviest users are the ones hitting it. Ben, in developer tools the heaviest user is often an engineer who can't approve spend. At Snyk, what limit actually got a team to pay: seats, usage caps, or a feature a manager or security lead needed? How did the paywall reach the person with budget, and what did you try there that failed?

Ben WilliamsRuns The Product-Led Geek. Former VP of Products at Snyk

Elena's heaviest-user test needs one change for dev tools: measure the heaviest accounts instead of the heaviest users, because the engineer hitting the wall and the person holding the budget are often two different people. The clearest failure at Snyk was a handoff to sales placed at the wrong moment. Zack Kanter called us out publicly because he couldn't create an API key without upgrading, and he couldn't upgrade without talking to sales.

X He was the buyer, he had the budget and the intent, and our packaging made him wait for a sales cycle. That's the cost of assuming the person at the wall can't approve spend. Sometimes they can, and a sales gate turns a buyer into a complaint.

So the self-serve channel we launched, with new pricing and packaging, was there to let teams who were ready pay on the spot. That's the channel that grew 65% QoQ. Sales came in later, based on account-level signals.

For the engineer who can't approve spend, a sales follow-up on that one person is the wrong move, whatever limit they hit. Snyk's experience shaped how I think about product-qualified accounts (PQAs). An individual crossing a usage threshold is a noisy signal in B2B, because most of those users have no buying authority. What tells you an account is ready is aggregate usage across the team or company. Inside that account, the person who can buy often shows up through behaviour like sending larger numbers of invites.

plg When no buyer shows up, sales and ABM have to go and find one inside the account.

The engineer's job at the wall is to make the case to their manager, so the GitHub lesson applies even more in dev tools. When GitHub's signup flow laid out plainly what free and paid each included, conversion rose 35% and self-serve ARR grew by more than $1M.

plg An engineer can't argue for a plan they can't explain, so the paywall copy should be easy to forward to the person who approves the budget.

Ask a follow-up

Pricing

105

Pricing

3M+ insights

Pricing & monetization experts from Faire, Amplitude, Dropbox & 1 more

by SuperMe

Frequently Asked Questions

How should a consultant or agency price its services?
By the shape of the work: a fixed fee for a defined deliverable, a retainer for ongoing access, prepaid units for variable requests. Add a performance fee only once the metric, baseline and client duties are agreed.
How does a young startup or community choose a business model?
Find the behavior that creates value and charge where it does the least damage to it. Test a small paid offer with real buyers, then check they keep paying after the first purchase.
Should a transaction fee be flat or a percentage?
Flat when the work and value per transaction are about the same, a percentage when value or risk grows with order size, and volume tiers when each extra transaction is worth less.
How do you present a pricing change to executives?
Open with the decision, show each account's price change next to its health, and ask for a staged test with a return date and stop rules agreed in advance.
How many pricing tiers should a SaaS product have?
Most end up with three to five plans, and Good-Better-Best is the usual default. Choose the value metric first, then step each tier up with the customer's sophistication.
How do you break down a competitor's pricing?
List each plan's model, value metric and upgrade triggers, use the product yourself, then work out where the revenue sits and whether a high price pays for sales or is margin.
How should AI features and agents be priced?
Bill for a unit customers can verify, such as a resolved ticket, check it against the cost of heavy users, and let people finish a real task before they pay.
How do you move existing customers to a new pricing model?
Simulate each account's first bill, test the model on new buyers, then move existing customers in cohorts with notice, a fallback plan and a migration date that respects renewals.
How long should a free trial be?
Long enough for retained customers to reach the paid value. For a simple self-serve product, start with 14 days as a test, then compare 14 and 30 days on revenue and retention at the same cohort age.

All pricing questions →

Frequently Asked Questions

Where a paywall should stop people, and what it should offer

Pricing

Frequently Asked Questions

How should a consultant or agency price its services?

How does a young startup or community choose a business model?

Should a transaction fee be flat or a percentage?

How do you present a pricing change to executives?

How many pricing tiers should a SaaS product have?

How do you break down a competitor's pricing?

How should AI features and agents be priced?

How do you move existing customers to a new pricing model?

How long should a free trial be?

Your ideas, super powered.

Where a paywall should stop people, and what it should offer

Pricing

Frequently Asked Questions

How should a consultant or agency price its services?

How does a young startup or community choose a business model?

Should a transaction fee be flat or a percentage?

How do you present a pricing change to executives?

How many pricing tiers should a SaaS product have?

How do you break down a competitor's pricing?

How should AI features and agents be priced?

How do you move existing customers to a new pricing model?

How long should a free trial be?

Your ideas, super powered.