Case study · 04 / 04 · 20254 min read
  • Monetization
  • Systems design
  • Edge cases

Couchsurfing Freemium

What do you gate when the product is people talking to each other?

Where
Couchsurfing. The free tier for members in countries where membership is optional.
Role
Sole designer. Model comparison, decision tree, inbox and notification design, engineering handoff
Six phones on cream: the contacts sync ask, the paywall's Not Now, the three-more-views profile offer, the membership paywall, the inbox with two free views left, and the inbox with the views spent and a chat locked
Two views, then a gate

WithheldFree-tier conversion magnitudes, and the share of users who earn views versus pay, are under my confidentiality obligations.Where the direction is safe to say, I say it, without the size. This study is the model, the rules and the shipped screens.

At a glance

  1. The problem

    In countries where membership is optional the app still has to give free users a reason to pay, and the only thing worth paying for is the conversation. Gate it and you gate the product; leave it open and nobody converts.

  2. What I did

    Compared three gating models, dropped the reverse trial first, and shipped the one that meters replies at two views every 48 hours while exempting hosts and friends, with twelve decision points engineering built from.

  3. What happened

    Shipped and held. Hosts and friends never hit the wall. The model, the rules and the edge cases are here.

01Scope

  • 3

    gating models compared

  • 12

    decision points in the shipped flow

  • 2

    views every 48 hours. The one number

02The problem

If you gate the conversation you gate the product, and if you leave it open there is no reason to convert. Every model I looked at was somewhere on that line.

The goal I wrote on the board was to balance conversion opportunity (free users actually hitting paywalls), paid user experience (not frustrating the people already paying), and simplicity from a technical perspective. All three pull against each other.

03What I dropped

The reverse trial, before I got to the second column.

  • A reverse trial: full access for 48 hours, then a countdown and a push telling you your time is running outit works, and it runs on loss aversion, the mechanic I had just spent the paywall research arguing against. An opt-out trial with different branding.

04Three models

  1. 01Restrict only communication requests. Better for paid users, who never hit a dead end reaching out to a free user. The least paywall exposure, so the lowest conversion pressure.
  2. 02Restrict all message responses. The most scalable and conversion-oriented, and the easiest to build. The problem: a paid host accepts a free surfer's stay and then cannot get an answer from them, which is the most valuable interaction on the platform.
  3. 03Restrict responses, exempt hosts and friends. Monetizes surfers, protects hosts, keeps conversations on the platform. The cost is role and timestamp logic, and it is harder to explain why one chat is gated and another is not.

Model 3 shipped. Exempting hosts and friends protects the interactions the community actually runs on while still putting paywall pressure on surfers, and a host giving someone a place to stay is providing the platform's value, so charging them to reply to a guest is the wrong side of the transaction to charge.

05The rules

  1. 01Sending is unlimited. Requests, messages, all of it.
  2. 02Viewing a response costs one view. Two views every 48 hours.
  3. 03A message request is previewed for free. Replies after it count.
  4. 04Accept or decline on a stay counts as a response.
  5. 05Chats with an accepted stay are open until the stay ends.
  6. 06Friends made before the first message are open. Friends made after are not.
  7. 07An empty allotment unlocks one offer: sync contacts, calendar or location for two more views. Once.
  8. 08After that, complete your profile for two more. Once.
  9. 09Rewards are only offered when the allotment is empty, so nobody banks views.

The friend rule is the one I expected to argue about. Without the timestamp check you can add someone as a friend after they reply and the wall disappears, and with it the loophole costs more effort than the membership does.

06Edge cases that shaped it

  1. 01A paid user requests a stay from a free user, the free user accepts, then cannot read the paid user's follow up. Rule 5 covers it.
  2. 02A surfer sends three requests. One declines, one accepts, one is pending. The pending one is locked, the accepted one is open, and the decline used a view.
  3. 03Syncing contacts and immediately completing a profile does not earn four views. The second reward is not offered until the first two are spent.
  4. 04Making a new account to reset the counter is possible but slow, and the profile reward resets with it, so it is not really free.

07The flow

The Model 3 decision tree redrawn: from onboarding and the paywall, through the country check, the chat-type check with friend, request and accepted-stay exemptions, the two-views-per-48-hours counter, the paywall modal, and the sync and profile-completion rewardsSwipe across
Twelve decision points from onboarding to the paywall trigger, redrawn from the flow engineering built from. Every node keeps its original wording; the sticky notes did not make the cut.

08What shipped

The chat inbox, two states: the counter card reading Unlock Unlimited Views, you have 2 free views left, and the same inbox after the views are spent, the card now naming the reset date and the chat row locked with Tap to unlock 1 new messages
Left, two views left. Right, the allotment spent: the card names the next reset and the chat row locks, sender still visible.

A card at the top of the inbox. Unlock Unlimited Views. You've got 2 free views left! Under it, locked chats still show the sender and a blurred preview so people know what they are missing. The push notification when the allotment refreshes is written the same way the rest of the app talks.

09The impact

It converted, and it did it without the loss-aversion tricks the benchmark models run on. Hosts and friends never hit the wall, which was the constraint the whole model was built around, and it held.

Under NDA

Free-tier conversion and the share of users who earn views versus pay are under my confidentiality obligations. I can talk through the model, why it shipped, and what I would measure next.

The model, the rules, the edge cases and the shipped screens.

Corrections & caveats

Variables
Design was not the only thing that changed, so this is not a design-only result.
Cohort
Live from mid 2025.
Confidence
The model shipped and held. Direction only.
Not measured
  • The paywall redesign shipped in the same window, so anything that moved in free-country conversion has two causes and I cannot split them.
Confidential
Magnitudes withheld. Direction stated.

10What I would measure next

  • Days to convertby cohortHow long the free tier holds someone before they pay, and whether that changes by who they message.
  • Retention after paying30 days onSomeone who pays to read one reply and leaves is probably a refund.
  • Converting triggerthird view, sync, profileWhich of the three gates actually does the converting.
  • Support loadtickets per weekLosing access to a chat generates tickets. Count them.