After publishing a post about trial referral extensions, I got sharp feedback: "the uncapped part will break first. Anyone can invite themselves with throwaway inboxes."
The commenter was right. Here's what I learned building and operating a referral extension system in production, and the 5 patterns that prevent abuse without killing the viral loop.
The original design
7-day trial. Each accepted invite = +14 days for both inviter and invitee. Days stack on top of paid time. No cap on invites.
This is generous. It's also abusable.
The 5 anti-abuse patterns
1. Email verification before days are added
The naive flow: signup → days added.
The safer flow: signup → email verification → days added.
This filters out 80%+ of fake-account abuse. Most throwaway inboxes never click the verification link.
2. Delay days until first real action
Don't add the +14 days at signup. Add them when the invited user does something meaningful:
- Mounts a drive successfully
- Uses the tool for 7+ days
- Sends a file through the mounted drive
The "meaningful action" trigger varies per product, but the principle is the same: tire-kickers don't trigger, real users do.
For ScsDriver, we add the days when the invitee first mounts a WebDAV server. That's the moment we know they're a real user.
3. Rate-limit invites per inviter
Even legitimate users shouldn't invite 50 people in a day. We rate-limit to 3 invites per 24 hours per user. This doesn't stop abuse, but it slows it down and makes it expensive.
4. Detect throwaway email domains
Maintain a list of known disposable email providers (Mailinator, Guerrilla Mail, 10MinuteMail, etc.). Invites from these domains don't trigger day extensions.
This catches the lazy abusers. Sophisticated abusers can spin up real domains, but that's high-effort and not worth it for +14 days.
5. Cross-reference for duplicate humans
If two invites come from different emails but the same machine fingerprint (or the same payment method later), treat them as one. The "one user can't invite themselves 5 times" rule.
This is the most invasive check (privacy implications), so we only enable it for users who opt in. Most don't. The first 4 patterns catch most abuse.
What we measured after deploying these
Before (no defenses):
- Top 1% of inviters sent 40+ invites
- ~12% of invites appeared to be self-invites
- Day-stacking cap effectively 4 years for a power abuser
After (5 patterns deployed):
- Top 1% sends 8-15 invites
- < 2% self-invite estimate
- Realistic max ~6 months for power abuser
- Conversion rate to paid up 18% (because power abusers stopped getting free forever)
The tradeoff
Each anti-abuse pattern adds friction. Some real users will be filtered out. But:
- A friction-free trial that's heavily abused doesn't help anyone
- The product's reputation matters more than short-term conversion
- Power abusers are not your future paying customers
For a $5.50 lifetime product, the referral loop is pure margin. You can afford to be strict.
When NOT to add these patterns
If your product is:
- Subscription-based (not lifetime)
- Network-effect dependent (referrals are growth-critical)
- In a market with high churn
Then strict anti-abuse can hurt more than help. The math is different.
For small lifetime-purchase tools, the calculus favors defense. For SaaS with viral coefficient, you accept some abuse as cost of growth.
What I'd do differently
If I were starting over, I'd ship the 5 patterns from day 1. Adding them later means dealing with grandfathered abusers and edge cases. The first version of ScsDriver's trial had none of these, and cleaning up the abuse after the fact was a 2-week project.
TL;DR
If you're building a referral extension for a trial:
- Email verify before adding days
- Delay days until real action
- Rate-limit invites
- Filter disposable email domains
- Detect duplicate humans (optional, opt-in)
The uncapped design is generous. It also needs defenses. Ship both together.
Discussion: anyone running a referral program in production? What patterns have you found that work?
Top comments (0)