DEV Community

疏影
疏影

Posted on

Why I cap daily invites at 3 (and what happens when I change it)

For my WebDAV mount tool (ScsDriver, $5.50 lifetime), I built a 7-day free trial that can be extended to 60+ days via a referral system. The single most important design decision was the daily invite cap. Here's the long-form comparison after running both unlimited and capped variants for the past 8 months.

What changed

In v1.0 (Q1 2025), I shipped unlimited invites. "Unlimited" meant: send as many referrals as you want, get +14 days for each accepted one.

In v2.0 (Q2 2025), I capped it at 5 per day.

In v3.0 (Q3 2025), I dropped the cap to 3 per day.

What I expected

I expected lowering the cap to reduce spam behavior. I expected it to also reduce legitimate user activity (since power users would hit the cap).

What actually happened with cap=5

Referral volume dropped 30% in the first week. Then it stabilized back to 80% of the unlimited baseline within 3 weeks. Conversion (trial → paid) went up 12 percentage points (from 8% to 20%).

Why? Because the invites that dropped were the spam invites. Bulk inviters stopped trying once they realized the ROI broke down at cap=5. The remaining invites were higher quality.

What happened with cap=3

Referral volume dropped further to 65% of the unlimited baseline. But conversion went up to 27%. Paid revenue per user went up 22% vs cap=5.

Even better: trial-to-paid conversion rate improved even though the absolute number of invites dropped. This is the key insight — a smaller, higher-quality referral channel beats a large spam-prone one.

The case for cap=1

I considered cap=1. The "one-invite-per-day" extreme case. I tested it on 5% of users for 2 weeks. Result: referral volume collapsed to 30% of baseline, conversion rose to 35%, but total paid conversions decreased because the total invite volume was too low.

Cap=3 is the local maximum. Cap=1 is too restrictive. Cap=5 starts inviting spam back.

What I learned about cap design

  1. The cap is a quality signal, not just a quantity limit. Users willing to spread invites over multiple days are quality users. Users trying to refer 50 people on day 1 are spammers.

  2. The cap thresholds matters less than the existence of a cap. cap=5 vs cap=3 doesn't matter as much as unlimited-vs-capped.

  3. Conversion rate is the right metric, not referral volume. Aim for max(conversion × volume), not max(volume).

  4. Allow "next day" behavior. Don't penalize users for hitting the cap. Make them wait 24h, not "once hit, no more invites ever."

How I implement cap=3

Server-side enforcement. Each user has a daily_invite_count column that resets at 00:00 UTC. The invite endpoint returns 429 if count > 3. No client-side bypass is possible.

For UI: we hide the "invite friend" button after 3 sends. We show "Resets in 18h 32m" instead.

Power users who want more reach the limit silently (no warning). They wait for reset.

Tradeoffs

The cap introduces frustration for legitimate power users. Two of them have asked me to remove it. I declined (politely).

Their argument: "I have 50 friends who'd genuinely use this, why limit me?" My counter: "We can't distinguish from the server side who's bulk-spamming and who's power-user-extending. The cap protects both of us from false accusations."

The quiet surprise

After 8 months with cap=3, my support tickets about "invites don't work" went to near-zero. When unlimited was active, 15% of support tickets were invite-related (broken referrals, disputes, fraud claims). With cap=3, that's 1.5%.

The cap's secondary benefit is fewer disputes. When invites are unlimited, abusers find edge cases. When capped, the surface is small enough to keep clean.

For ScsDriver specifically

Cap=3 has been the right call for a $5.50 lifetime product with a developer audience. The cap also signals product taste. Power users notice that I thought about spam vs legitimate usage.

I won't change it back to unlimited. I won't lower it to 1. Cap=3 is the answer, empirically, for this product and price point.

The takeaway

If you're building a referral or invite system:

  • Pick a small cap (3-5)
  • Enforce server-side
  • Measure conversion, not volume
  • Let users wait for reset, don't block them forever

The cap turns invite systems into relationship tools instead of growth hacks. Less spam, higher quality, better long-term revenue per user.

Top comments (0)