Paywall

Concept

The boundary built into a product where a free user stops and has to pay before anything further opens up.

Why it exists

When software shipped in boxes, nobody had to design a line between free and paid. The line was the cash register. You paid, you got the box, and before the box there was nothing to use, so the question of how much to open up never came up.

Moving to the web inverted that order. Signing up takes an email address, and the person who signs up starts using the product immediately. The moment of payment shifted from the entrance to somewhere inside. That created a question nobody had faced before: at which point in the product do you say that going further costs money? Too early and people leave before they can tell whether the thing is any good. Too late and the people who already got what they needed have no reason left to pay.

The first answer was time. Open everything for thirty days and lock it on day thirty-one. It was easy to set and easy to explain, but the limits showed up quickly. For someone who tried it for a few days and then got pulled onto other work, thirty days simply elapsed, and at the moment the wall appeared that person still didn't know why the product mattered. So the boundary moved off the calendar and onto what the user actually did inside the product — how many documents they created, how many colleagues they invited. A trial that ends on a date treats a person who opened the product twice and a person who moved their whole team onto it as the same case, and only one of those two has a reason to pay on day thirty-one. Counting actions instead of days puts the wall in front of the second person and leaves the first one room to keep looking.

While this point had no name, meetings kept missing each other. When Mia at Pagedeck said the team should push harder on payment prompts, Theo pictured a window covering the screen the moment someone tried to create a fourth document, and Ravi pictured a banner strip along the top of the page. Sofia heard it as sales reaching out to free users directly. Three completely different user experiences came out of one sentence. Two weeks later, when the pieces were put together, a single user was receiving the same prompt three times.

Paywall is the name attached to that point. Once it had a name, what used to be one vague thing split into three decisions: where to put the boundary, how hard to block at it, and what to show the person who hits it. Inside the product field, the monetization branch also covers pricing, which sets the number, the billing model, which sets what gets counted, and expansion revenue, which comes from customers already inside. The paywall sits on a different layer from those three. They decide how much is charged and on what structure; the paywall is the one spot where that decision surfaces on the user's screen. Move the paywall without touching a digit on the price page and revenue still moves.

How this field breaks down

The terms under the paywall fall into two branches: strength, meaning how hard the block is, and method, meaning what gets counted to block. They aren't alternatives to choose between but two axes that describe one paywall, so real products use both at once. Pagedeck's free plan allows three documents and locks the create button on the fourth. On the strength axis that's the loose end, since the first three stay usable. On the method axis it counts documents.

Strength splits by what a blocked person can still see. There are two.

  1. Hard paywall — nothing opens before payment. Either the signup screen leads straight to checkout, or you can log in and find nothing inside. This works when the value carries on the description alone: enterprise products bought under a signed contract, or paid publications where the content itself is the product. The cost is that people have to decide before looking, so signups drop sharply. The share of remaining visitors who pay comes out high, but that share only counts people who arrived already intending to buy, so it can't be compared to other approaches at face value. Run the same product hard and 200 people sign up in a month with 60 paying; open a free tier and 3,000 sign up with 150 paying. The rate fell from 30 percent to 5 percent while the money coming in went up two and a half times.
  2. Soft paywall — part of the product stays open and only what lies beyond it is blocked. This is a decision to spend the free tier proving the product's value. People judge whether to pay after actually using it, so the barrier to signing up is low, and in exchange plenty of people stay free forever and leave. How far the free tier extends is the whole design here, and a badly placed line means either free is enough and nobody crosses, or the wall arrives so early that nobody felt any value.

Method splits by what serves as the measure. There are two.

  1. Feature gating — access is divided feature by feature according to plan. The free plan lets you write and share documents while permission settings and version history open on a paid plan. What to lock is usually chosen at the point where user types diverge. A good candidate is something a solo user never needs and a company using the product as a team can't do without. Lock something like export, which pulls out data the user created themselves, and what comes back isn't payment but resentment.
  2. Usage limit — a ceiling on how much the free tier allows, written as a number: three documents, five teammates, two gigabytes of storage. Every feature stays open and only the quantity is capped, so users experience the product whole and hit the wall naturally as they grow. The ceiling shouldn't be guessed; it comes out of the distribution of people already using the product. Line up how many documents free users have created, find where half of them stop, look at where accounts that started working as a team tend to separate, and put the line between those points. When choosing the unit to count, pick something that grows as the customer grows. Headcount rises as a company expands, while document count fills up fast even for one person working alone, so the same ceiling blocks different people depending on which one you count. A cap of five teammates never touches a freelancer and stops a ten-person team in its second week; a cap of five documents stops both, and the freelancer it stops was never going to buy a team plan.

The two branches meet in the decision about how big the free tier is. Drop the free tier entirely and the paywall stands at the entrance. Make the free tier the product's main face and open it generously and the arrangement has its own name, freemium. Either way, strength and method each need one decision before a real screen exists. Settle strength alone and what to count is still blank; settle method alone and it's still undecided whether a blocked person loses access to what they already made.

Where to put the boundary remains open even after both branches are settled. The working rule is a single one: put it after the moment the user first feels the product's usefulness. At Pagedeck that moment wasn't writing a document alone but a colleague leaving the first comment on it. Block earlier and the user leaves carrying the memory of briefly trying a text editor. Block later and the user weighs payment against losing a place the team is already working in. Where that moment falls isn't settled in a meeting room; it's found in usage records. Lay out what paying accounts and departing accounts did differently in their first two weeks and the split usually comes down to one or two actions.

How it sounds at work

"Let's push the paywall from three documents to five this time. Too many people hit it two days after signing up."

The free tier is too short and people are blocked before feeling the value, so the proposal is to move the boundary back.

"This isn't people dropping off at the paywall, it's people never reaching it."

The reason payments aren't happening lies at an earlier step, not at the block itself.

"Locking export on the free plan doesn't read as a paywall, it reads as a hostage situation."

Keeping users from retrieving data they created themselves isn't setting a boundary, it's spending trust.

Pagedeck started with the free plan capped at three documents. Four months in, Mia opened the numbers: of 1,000 signups, 620 left without creating a single document, 90 reached the cap, and 34 of those paid. Looking only at people who stopped at the cap, 38 percent paid, which looked respectable — except fewer than one in ten had made it that far.

Mia raised the cap to five and ran a quarter. People reaching the cap rose to 140 and payers to 41. As a rate that's 38 percent down to 29 percent, and Ravi pointed out that on the metric alone this was a step backward. Mia's framing was to count people rather than percentages. Moving a paywall almost always pushes the rate and the absolute number in opposite directions, so without agreeing in advance on which one to read, the same result gets reported as a success and a failure at the same time.

What people get wrong

The most common mistake is treating paywall as another word for checkout screen. Hitting the wall does bring up a checkout screen, so the confusion is understandable. But the paywall is a boundary and checkout is the door through it, and the two are fixed by different people in different ways. Working on the door — the message, the button, the card entry steps — belongs to conversion rate optimization (CRO), the practice of getting more conversions out of the same traffic. Leave the two conflated and the team spends months rewriting copy on the checkout screen while nobody asks again whether the boundary belongs at three documents or five. The first kind of work usually moves things by a few percent; the second changes the number of people converting by a multiple.

Reading a harder block as more revenue goes wrong just as often. The arithmetic is plausible: more locked doors, more reasons to pay. In practice the free tier is where value gets proved, and blocking before the proof finishes means the reason to pay never forms. That is what happened when Pagedeck moved comments to a paid plan. Invitations sent by free users fell from 1.8 per week to 0.4, and three months later new signups were visibly down. Comments had been the channel bringing other people in, and that channel had just been moved behind payment. Left alone, the flow of new people dries up and the company drifts toward extracting more from whoever is left. The damage also takes months to surface, which is what makes this one hard to catch: the quarter the feature moves behind payment usually looks fine, because the people converting that quarter signed up before the change.

Easily confused with

TermWhat it decidesHow it differs
Billing modelWhat unit gets counted and chargedSets the charging structure, per seat or per usage. The paywall points at where in the product that structure stops the user, so two products on identical billing models can have their paywalls in different places

Where to go next

  • Product

    see where monetization sits among the product field's branches

  • Hard paywall

    one concrete case of the strictest block makes the strength axis clear

  • Conversion rate optimization

    how people stopped at the boundary get across, from the growth side

Sub-terms

Related terms

Last updated 2026-09-16