Not a Wall but a Sieve: A Signup Anti-Abuse Guide for Vibe Projects

First, a note: every person, product name, and number in this guide is fictional, invented to explain the method. Nothing here is a real product or a real user case. The method is general; the numbers are illustrative scales, not measured results from any product.

When a vibe project is first targeted by bots, the maker's first instinct is often "add a captcha, the harder the better". The usual result: bots keep coming, and real users get stuck first. My view: signup anti-abuse is not a wall, it is a layered sieve — use quiet signals to filter out most machine traffic, and only put a task in front of the small minority that genuinely looks suspicious. Get the order backwards and you block your own growth, not the bots. Worse, badly done anti-abuse hurts real users most: everyone behind a campus network, a company gateway, or a shared home broadband connection can be swept up together because they share one IP.

Know the opponent: signup bots are not one thing

"Bot" is too vague a word; different bots want different things and need different defences. The first kind registers thousands of accounts in bulk, saving them for later advertising, comment spam, or referral-reward farming. The second abuses trials: new emails and phone numbers, over and over, to harvest free quotas for resale. The third pumps SMS: it targets your verification-code endpoint and burns your SMS budget sending codes to other people's numbers. The fourth scouts: it registers, posts nothing, and crawls data and probes endpoints to prepare a later attack. Once you see these four, the goal becomes clear: not "zero bots get in", but "bulk registration becomes uneconomical, a single fake account cannot do much damage, and real users barely notice". A goal of absolute zero always leads to captchas for everyone and phone numbers for everyone — a lose-lose.

Take the fictional example of Ah Hai's "Seagull Docs". In its second week, 800 registrations arrived within one hour overnight, all from the same batch of disposable email domains, with no document activity, and the next day they started posting comments full of outbound links. That is the classic bulk-plus-advertising combination. A picture captcha alone would probably not have stopped them — solving services sell human solving for a fraction of a cent per account. What works is a combination: rate-limit registrations per IP, send disposable-domain signups to a review queue, and restrict link posting for new accounts. Together, those three raise the attacker's cost past the point of profit.

The friction ladder: from invisible to hands-on, only for the suspicious

I recommend a four-layer ladder. Layer one is imperceptible to everyone: server-side rate limits, minimum intervals between form submissions, and per-IP and per-device registration frequency counts. Layer two is light signals: is the email domain a disposable one, is the password in a common breached-password dictionary, was the form filled at copy-paste speed? Layer three is invisible verification: only higher-risk sessions trigger it, and the server validates the result — the user is never given a puzzle. Layer four is hands-on verification: picture or slider challenges, email verification, and SMS verification, in ascending order of cost. The principle is escalation, not a jump to layer four for everyone. A real user on a normal network should stay in layers one and two; only sessions triggering several abnormal signals at once are worth spending one SMS on.

One warning matters above all: every decision must be made server-side. Hidden form fields, client-side rate limits, and client-side captcha states are decoration — bots never use your frontend, they call your API directly. The frontend only collects and displays; the server decides to allow, challenge, or block, and its decision must not be bypassable from the client. Also bind a passed verification to that session and device; do not make it "verified once, valid forever", or a bot will verify one account and reuse the credential for bulk registration.

Choosing a verification method: none is perfect, each has a price list

Every verification method comes with a price list — read it before choosing. Picture captchas are the least friendly to real people: users with poor vision, small phone screens, or a different native language all get stuck, and solving services defeated them long ago. Their remaining value is raising bulk cost slightly, not stopping bots. Invisible verification feels best, but it misjudges some network environments and its decisions are opaque, so explaining "why me?" to a blocked user is hard. Email verification is cheapest and answers "is this mailbox yours", but it cannot stop bulk signups — disposable mailboxes are unlimited. SMS verification is the most expensive and the most farmable: once an SMS endpoint is targeted, it can burn months of budget overnight, so it must always carry quotas and rate limits, never "send as many codes as the user requests".

Match the combination to the scenario instead of applying one rule site-wide. Ordinary signup: rate limits plus invisible verification is enough. Abnormal signals triggered: add email verification plus new-account restrictions. Anything involving money or referral rewards: add SMS verification or manual review. Link posting, mass invites, and sensitive profile changes: judge by account age and behaviour history, not by whether the account was verified at signup — an account verified at signup and left dormant for three days before spamming is still a spam account. Treating verification as a one-time ticket is the most common misconception in signup anti-abuse.

Restrict new accounts first: more important than blocking

Even if some bots slip through, do not panic. What decides the damage is what a new account can do after entering. Give new accounts an observation period: within 24 hours of signup, no outbound links, no mass invites, no bulk project creation; anything over the threshold goes to a review queue first. Real users barely feel this — a genuine newcomer does not post 50 link-filled comments in their first hour. For bots it is fatal, because a hoarded account's value lies in being usable immediately after registration. State the rule in the product, do not silently block: when a user hits the limit, say "new accounts can post links after 24 hours; contact support for early access". A restriction with a visible path forward does not become a complaint.

Prepare a cleanup path alongside. Accounts judged to be bulk fakes should be frozen first and reviewed, not deleted outright: the cost of deleting a real user by mistake far exceeds the cost of keeping a fake account for one more day. Keep an appeal channel on frozen accounts, and answer fast — a solo maker can promise "manual review within 48 hours", but a promise made must be kept. Run regular cleanup jobs: long-dormant accounts with highly consistent fingerprints go to the review queue instead of inflating your user table forever. A fake user count is worse than a small one, because it corrupts your retention and conversion maths.

Five traps to avoid

One, do not block whole countries or regions at a stroke. You may block an entire student dormitory, while bots route around you with a new proxy in a minute. Two, do not require a phone number from every user. Phone verification is the most expensive and most privacy-sensitive check; reserve it for money and rewards. Three, do not store device fingerprints indefinitely. A fingerprint may inform a single risk decision, but long-term retention is a privacy liability — state its purpose and retention period, and delete on expiry. Four, do not defend only the signup endpoint. Login, password recovery, email rebinding, and reward claiming are all abused too; rate limits and anomaly detection must cover the whole account API surface. Five, do not phrase blocks as verdicts. Never show "our system has determined you are a bot"; show "this action is too frequent right now, please try later or contact support". The first enrages a misjudged real person; the second leaves room for both sides.

Lock the SMS endpoint before designing the flow

SMS verification is the endpoint most likely to be attacked on its own, because it is directly connected to your money. Attackers need not register successfully; repeatedly requesting codes is enough to blow up your bill. So lock it first, in four ways: per-number frequency limits (one code per minute, five per day) with a visible "too frequent" message rather than silent failure; per-IP and per-device sending caps; code expiry of five minutes with at most five wrong attempts, after which old codes are void; and a daily spend circuit breaker that falls back to email verification and alerts the admin when the budget threshold is crossed. Test the attack cases, not just the happy path: ten rapid requests for one number, ten numbers from one IP, and an expired code must all fail safely.

Appeals are the second line of defence for misjudged users

Even good risk controls misjudge people; the difference is whether those users can come back. An appeal channel needs three concrete designs: the entry point sits on the block page itself, not buried in a help centre; the form asks only for what is necessary — account, time, and rough action — not identity documents upfront; and every appeal gets a receipt number, a decision within 48 hours, and one of three clear outcomes: restored, more information needed, or restriction upheld with reasons. Appeal data is also your best threshold-tuning signal: review weekly which rule generates the most appeals and which network environments succeed most often, and loosen the dimension that is doing the harm instead of tightening everything. A system with zero appeals either has no users, or its misjudged users have already left without telling you — the latter is worse, because you never learn what went wrong.

How to tell whether it is working

After shipping, watch four numbers, not just "how many bots we blocked". First, real signup conversion: did it drop noticeably after launch, and does any drop over 5 percentage points mean rolling back one friction layer? Second, bot share: what proportion of new signups show zero activity within 7 days with consistent fingerprints, and is it falling? Third, false-positive rate: appeal volume and appeal success rate — a long-term appeal success rate above 20 percent means your thresholds are too tight. Fourth, verification cost: the monthly bill for SMS and verification services as a share of total cost, and whether it is out of control. Review these four weekly and adjust one threshold at a time — anti-abuse is not a ship-and-forget feature, it evolves with attacker methods. One final rule: good signup anti-abuse is invisible to users; the moment users notice it, it is probably aimed at the wrong people.