Anatomy of a 55,000-bot attack
on an anti-bot startup.

We sell bot detection. Last night I opened our database and found 555 pages of fake signups. This is the honest write-up: what broke, why it's embarrassing, how we fixed it in one night — and the accidental circuit breaker that saved our email domain.

The discovery

Tuesday, 11pm. I open the Supabase table editor to check something unrelated and the developers table feels… heavy. Every row has the same name: "🎁 Dene Hemen! 5K Lira Bonusunu Yakala" — Turkish for "Try it now! Grab the 5,000 Lira bonus." Casino spam. I scroll. Page 2. Page 40. Page 555.

Yes — you read the third number right. We're early. For a few minutes our growth chart looked incredible, as long as you didn't read the names. The irony was not lost on me: bots flooded the signup form of a bot-detection product.

Root cause #1 — no rate limiting on signup

Our public API endpoints had per-plan rate limiting from day one. Our marketing site signup? A honeypot field and good intentions. Honeypots only catch bots polite enough to render your form — these ones POSTed the endpoint directly, thousands of times, and never even saw the hidden field.

Root cause #2 — we dogfooded wrong (the embarrassing one)

Here's the part that stings. Our signup did call our own bot-detection API on every registration. So why didn't it catch 55,000 bots?

Because we called it with just a userId — no behavioral signals. useHUMA scores behavior: mouse movement, keystroke cadence, scroll rhythm, touch patterns. Given zero signals, the engine returned a neutral score. Neutral cleared our threshold. Every bot passed.

Root cause #3 — every fake signup sent a real email

Each registration fired a verification email. 55K signups = 55K attempted sends to fake addresses — the kind of bounce storm that gets a sending domain blacklisted. What saved us? Our email provider's free-tier daily cap. The limit we'd been mildly annoyed by quietly refused to send the flood. Domain reputation: intact.

The fix (same night)

Four changes, shipped before going to bed:

1. Per-IP rate limit on signup (5/min) — reusing the same
   atomic counter our API already used. ~12 lines.
2. Lifecycle emails (drip, trial reminders) now filter
   email_verified = true. Spam rows never get emailed again.
3. Deleted 113K junk rows (after pattern-matching them safely).
4. A weekly habit: one SQL count query. Monitoring you don't
   look at is monitoring you don't have.

Next on the list: passing real behavioral signals through the signup flow, so our own form uses useHUMA the way it was designed to be used. The camera now points at the door.

What I'd tell you if you run a signup form

1. Rate limiting is layer zero. Not a hardening task for later — it's the lock on the front door. Per-IP, low ceiling, on every public POST.
2. Honeypots don't stop direct-POST bots. They filter the lazy ones. Plan for the ones that never load your HTML.
3. Dogfood properly or not at all. An anti-bot API called without behavior data is a coin flip wearing a lab coat.
4. Your free-tier caps are accidental circuit breakers. Know which limits are protecting you before you upgrade them away.
5. Spam looks like traction until you read it. 55,388 "signups" and 12 customers. Vanity metrics can literally be written by robots.
6. Attacks are content. This post exists because of one. The most useful thing about a fire, once it's out, is the story of how it started.

The uncomfortable honesty, on purpose

We could have quietly fixed this. But useHUMA's whole pitch is that bot detection should be transparent — no black boxes, no PII, no theater. That has to include being transparent when the cobbler's children go barefoot. We got attacked, the attack found real gaps, the gaps are closed, and the product is better for it.