Tiers give place, points give purpose: membership and loyalty for vibe projects

A tier is not a badge; it is how benefits are packaged

(The example product "Bailu Reading Club," the example people, and all numbers in this article are fictional, used only to illustrate rule design. Prices and benefits are examples, not any real product's pricing.)

Many vibe projects hit the same wall at a certain size: free users want more, power users want to be treated differently, and you have only two tiers — free and paid — with no steps in between. Either you sell everything at once to the highest bidder, or you watch the middle group most willing to pay drift away. Membership tiers and points solve exactly this step problem: users climb one step at a time, and every step has a clear reward.

Separate the two concepts first. A tier is an identity — it answers "who are you": bronze, silver, gold, or free, plus, pro. It decides which benefits you enjoy. Points are a currency — they answer "how much have you saved": completing tasks, spending, and consecutive use all earn them, and enough of them can be redeemed for concrete rewards. Tiers handle long-term identity; points handle short-term motivation. Tiers without points leave users in a long empty stretch between levels where "nothing happens." Points without tiers leave users never knowing where they stand in your product.

This guide offers a plan you can ship directly: how to cut three tiers, what benefits go in each, how points are earned and spent, how expiry and downgrades can be handled without hurting people, and four anti-abuse points to settle before launch. The goal is not an airline miles program, but a rule set an indie developer can explain on a single page.

Step one: three tiers, each answering one question

On tier count, three is the safest starting point. Two is too coarse; four or more pushes users into comparison paralysis. Each tier should answer one question: the free tier answers "can I try this first," the middle tier answers "is this worth paying for monthly," and the top tier answers "can I do this more professionally." If a tier cannot answer its own question, it is redundant.

Fictional example: Bailu Reading Club cuts its tiers like this. Free "Reed": two group reads per month, a basic book list, community browsing. Plus "Egret" at 68 yuan per month: unlimited group reads, a dedicated reading guide, reading-note exports, priority signup for offline events. Pro "Lighthouse" at 168 yuan per month: everything in Egret plus small-group reads (no more than 12 people), an annual reading report, and guest-talk seats. Notice what this cut avoids: no tier is designed by crippling a feature. The free tier is not core functionality cut in half; it differs in quantity and depth — session counts, group sizes, exclusivity — all dimensions that scale smoothly.

The most common cutting mistake is cutting by feature checklist instead of user scenario. "Pro has 17 more features than Plus" means nothing to users. What they care about is "I read three books a week and want a small-group discussion — which tier do I buy?" When writing the tier page, the first sentence of each tier should be a scenario sentence, not a feature list. Another iron rule: a higher tier must fully contain every benefit of the lower tiers. A "Pro lacks one Plus benefit" inversion instantly convinces users your pricing was improvised.

On price anchors, the middle tier should be your flagship, and the top tier should cost roughly two to three times the middle. That multiple comes from user psychology, not cost accounting: below two times, users feel the top tier is "barely different"; above three times, middle-tier users feel the jump is unreachable. The flagship tier's benefits should satisfy one test: buying any single benefit alone costs more than just buying the tier. Otherwise users price-compare item by item instead of subscribing.

Step two: points do three things only — earn, spend, expire

If your points rules take more than one page, they are already too complex. A point's lifecycle has three stages: how it is earned, how it is spent, and when it expires. One main rule per stage, plus one or two supplements, is enough.

Earning: reward only behavior that genuinely benefits the product. Bailu's earning rules: 20 points for completing a group read, 30 for publishing a note, a 50-point bonus for a 7-day check-in streak, 100 for inviting a friend who registers and completes a first group read. Note what is absent: no "5 points for daily login." Logging in creates no value; rewarding it breeds users who tap once and leave. Also do the arithmetic on earning speed: how many points does an ordinary user naturally earn in a month? If the answer is 300, the redemption floor must not sit at 3000, or points will remain decorative forever.

Spending: redemptions must be things users actually want, and they must be tiered. Low-threshold redemptions (100 points for a month of Plus trial, 200 for an e-book) let new users taste success within a week or two. Mid-threshold redemptions (800 for an offline event seat, 1500 for an annual membership discount) give long-term users something to aim at. High-threshold redemptions (5000 for hosting a guest talk) serve as status symbols that not everyone needs to reach. Redemption itself must be one click — no application forms. Every step of friction in redemption teaches users that points are worthless.

Expiry: points must expire, or your liability grows without bound. But how expiry is written decides whether it motivates or offends. The recommended approach is rolling expiry: points are valid for 12 months from the day they are earned, with reminders 30 days and 7 days before expiry, and only the earliest-expiring batch is deducted — never the whole balance at once. The most damaging approach is a year-end wipe with no warning: users wake up to find a year's savings gone, and what leaves is not just points but trust. Expiry reminders are also your best reactivation channel: a message saying "your 300 points expire in 30 days and can be redeemed for a month of Plus" is more dignified than any retention blast.

Step three: celebrate upgrades, handle downgrades gracefully

Upgrades are the most celebration-worthy moment in a product, yet they are often delivered in silence. A user moves from free to Plus and the page just says "payment successful," with no ceremony. The right approach: the upgrade success page states the three newly unlocked benefits, the points balance change, and what is still needed for the next tier. The upgrade email should not just say "thanks for subscribing" but "you can now join unlimited group reads, and a seat at Wednesday's guided session is reserved for you" — translating benefits into the user's next action.

Downgrades are the opposite: the goal is dignity. When a user drops from Pro to Plus, the worst responses are instantly revoking all top-tier benefits or bombarding them with retention popups. The recommended handling: benefits stay unchanged for the current billing cycle and step down automatically when it ends; seven days before the downgrade, send an email listing what will be lost and what will be kept, with a one-click restore link. Points must not be wiped on downgrade — points are the accumulation of past behavior, not an accessory of the tier, and clearing them on downgrade tells users "your past effort does not count."

Retention rules for a tier must be written in advance, not explained when a user is about to drop. A common approach is an annual review: every January, tier status is decided by the previous twelve months of spending or activity, with a reminder 30 days ahead saying "200 more points will keep your tier." Ad-hoc rules, verbal promises, and case-by-case support decisions are poison for a retention system — once users discover the bar varies by person, the tier's credibility is gone.

Four anti-abuse points: block them before launch

First, points farming. Invite rewards and check-in rewards are the easiest to script. Countermeasures: invite rewards only after the invitee completes one real core action; check-in rewards need a daily cap and require the action to have content (for example, a note of at least 50 characters); abnormal bulk behavior from one device or network should trigger human review, not automatic payout.

Second, points cash-out. When points redeem for physical goods or cash equivalents, set a per-person monthly cap, and make every redemption traceable to the specific earning action. Allowing free transfers between users opens a black market — unless you can operate a market, do not open that door.

Third, tier sharing. A user lending a top-tier account to others is effectively wholesaling your benefits. Countermeasure: at least one top-tier benefit should be strongly identity-bound (for example, a named offline event seat or a personal annual report), so borrowing the account feels awkward everywhere instead of smooth everywhere.

Fourth, changing the rules mid-game. Once points values, redemption rates, and tier benefits are published, cutting them is a trust incident. When a change is unavoidable, announce it 30 days ahead, honor the old rules for points already earned, and apply new rules only to newly earned points. A retroactive rule change saves costs that user churn will repay several times over.

Launch checklist: all eight must pass

One: each tier page opens with a scenario sentence, not a feature list. Two: higher tiers fully contain lower-tier benefits, with no inversions. Three: buying any single flagship benefit alone costs more than subscribing. Four: earn, spend, and expiry rules fit on one page. Five: an ordinary user's natural monthly earnings match the lowest redemption threshold. Six: upgrades feel ceremonial, downgrades are graceful and take effect at cycle end, and points survive downgrades. Seven: retention rules are published in advance with pre-review reminders. Eight: farming, cash-out, account sharing, and rule changes each have a countermeasure. Any single failure is worth fixing before launch — once tiers and points go live, they become user assets, and changing the rules costs far more than changing the plan before launch.

One counterintuitive closing thought: the goal of a membership system is not to push every user to the top tier, but to let every user sit comfortably in the tier that fits them. A product where everyone is top-tier has cut its tiers wrong. A product where users know why they are at their current tier, what the next tier requires, when their points expire, and what a downgrade will do is a product where the membership system is actually working. Tiers give people a place, points give people something to look forward to, and graceful movement in both directions gives people trust. With all three in place, retention finally has a foundation.

(Scope note: this article covers paid membership tiers and points currency design. It complements, and does not repeat, this site's guides on gamification mechanics, internal credits ledgers, and pricing-page design: gamification covers badges and streaks, ledgers cover internal bookkeeping, pricing pages cover price presentation. This article covers only user-facing tier benefits and points rules.)