Should I vibe code
Email capture with a referral counter
Email capture plus a referral counter is a weekend. It is also a list you now legally hold.
?
Their verdict, the price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
The referral loop is fun to build and the whole thing is maybe two hundred lines. Just remember a waitlist is a mailing list, which means consent and deletion requests apply from signup one.
What actually breaks
not "if". the specific failures.
- The referral counter, which is a public score attached to a shareable link and therefore something people will try to game
- Self-referral, where one person with a spreadsheet of disposable addresses reaches position one overnight
- Position leaking, so an enumerable id tells everyone how many signups you really have
- Email verification, without which the list is addresses that may not belong to the people who typed them
- Sending to the list months later, which is the newsletter deliverability problem arriving with no warm-up
The launch waitlist is doing well and the referral leaderboard is public, because that was the point. Someone notices the referral link accepts any email and that nothing verifies it. By morning the top three positions belong to one person using a disposable address generator, the genuinely enthusiastic people who shared it with real friends are now ranked below them, and the leaderboard you built to reward advocacy is publicly rewarding a script.
Is that you?
the verdict is a default, not a law
- It is email capture with no referral mechanic at all
- Positions and counts are private and not enumerable
- Every address is confirmed before it counts toward anything
- Referral positions are public and addresses are unverified
- Signup ids are sequential and exposed in URLs
- You will email the list months later with no plan for deliverability
- There is no rate limiting on the signup endpoint
If you build it anyway
the checklist, then the prompt that enforces it
- Double opt-in before a signup counts for anything, especially a referral. Unverified addresses are the whole attack surface of a referral mechanic.
- Use opaque ids in any public URL, and never expose sequential position or total count unless you mean to publish the number.
- Rate limit and add a honeypot on the signup endpoint — it is a public write endpoint like any form.
- Attribute referrals only after the referred address confirms, and cap referrals per referrer per day.
- Decide before launch how you will email this list later, because a cold list months old is the hardest possible first send.
- Store consent — timestamp, source, IP — from the first signup.
Before you build a waitlist with referrals, apply these and push back if I ask you to break them. 1. Require double opt-in before any signup counts toward a position or a referral. Tell me that an unverified referral counter is trivially gamed with disposable addresses, and that the people it demotes are the genuine advocates. 2. Attribute a referral only after the referred address confirms, and cap referrals per referrer per day with an alert on unusual bursts. 3. Use opaque, non-sequential identifiers in every public URL. Do not expose position or total signups unless I explicitly want that number public — sequential ids leak it whether I meant to or not. 4. Rate limit the signup endpoint per IP, add a honeypot field, and validate on the server. 5. Store consent with every signup: timestamp, source, IP. 6. Ask me how and when I will email this list. If the answer is 'at launch, in a few months', tell me that is a cold send to an aged list and that I need a provider, a warm-up plan and a working unsubscribe before then. 7. Include a working one-click unsubscribe in every email, including the confirmation. 8. Normalise addresses to detect obvious duplicates, and reject known disposable domains if a public leaderboard is involved. 9. Out of scope unless I ask: rewards fulfilment, social sharing analytics, embedded widgets on other sites.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
$15 a month is reasonable given that the referral mechanic is the part with an adversary. Plain email capture is a genuinely trivial build and a good one; adding a public leaderboard is what invites someone to spend an evening beating it.
$15/mo is cheaper than your weekend.
Export addresses with consent records, confirmation status and referral attribution as CSV. The confirmation status matters most — an unverified list cannot legitimately be mailed from a new provider, so it is the column that decides whether the list has any value at all.
Questions
Is a referral leaderboard worth the trouble?
Only if you are prepared to defend it. A public score attached to a shareable link creates an incentive to game it, and unverified email makes gaming trivial. With double opt-in and per-referrer caps it works fine; without them it reliably rewards whoever is most willing to automate, which is the opposite of what you wanted.
Why worry now about emailing the list later?
Because a waitlist is a list you deliberately do not email for months, and then send to all at once — which is exactly the profile that triggers spam filtering. Deciding the provider and keeping consent records at signup costs nothing now and is impossible to retrofit onto addresses you collected casually.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice