760 sign-ups in a month, almost all bots: how we spotted them and what a captcha changed

In the autumn of 2026 Mellow Hub’s sign-up numbers looked healthy and its confirmation rate looked terrible. Both were wrong for the same reason: most of the people signing up by email were not people. In the 30 days to 7 November, 760 sign-ups by email code arrived before we switched on a captcha, and 42 of them confirmed. This is how we told the bots from the people, why we waited, and what Cloudflare Turnstile changed on 3 November.

The situation and the goal

On 6 October we were about to report the biggest leak in our funnel: of 142 email sign-ups, only 35 had confirmed their address. Before publishing that number we looked at who the sign-ups were, and took the claim back the same day. Of 140 email sign-ups since 24 September, not counting the team, 106 were automated.

From then on the goal was simple to state. Never read a sign-up or confirmation number without separating the bots first, and decide in advance when the bots cost enough to put a check in front of real people.

How we told bots from people

No single signal was enough. Together they left no doubt.

1. The network. Our sign-in runs on Supabase behind Cloudflare, and Supabase’s edge logs keep Cloudflare’s country code for every request. Every one of the 106 had the code T1, which Cloudflare uses for Tor. Later a second series appeared: requests marked as coming from the UK, from one network operator named “Private Customer”, 18 addresses and 19 user agents, posted straight to the sign-up endpoint with old, made-up browser versions.
2. Sameness. The Tor series used one identical desktop Chrome user agent and the locale en, at a steady 10–15 a day from 26 September.
3. The addresses. They were ordinary webmail addresses (Gmail, Yahoo, AOL, Comcast) that belonged to real people, who then received our sign-in letters. Nine of those people clicked the confirmation link, and eight became accounts. That is the pattern of subscription bombing: our form was being used to flood other people’s inboxes.
4. Bounces. Our mail journal for 22 September–12 October: 378 sign-in code letters, 122 bounced, 9 suppressed, 1 spam complaint, about 32% bounced. Between 26 October and 3 November: 264 sent, 166 bounced (63%), 2 complaints. Every bounced address was different, most of them Gmail addresses heavy with digits.
5. A group known to be human. People who came from our paid Meta ads confirmed at 87%, 20 of 23, almost all inside Instagram’s or Facebook’s in-app browser, 18 of them by typing the code.
6. For people, after the fact. Real sign-ups showed home and mobile operators in Cloudflare’s network organisation field. A VPN shows as a hosting company, or as a browser time zone two or more hours away from the time zone of the address.

What we did, in order

1. 6 October: every sign-up and confirmation figure is split by Tor first. We retracted the “biggest leak” claim.
2. 11 October: when we gave new accounts three free posts, we tied them to the connected social account, not to the Mellow account. A social account gets three in its life however many Mellow accounts it sits under, so a farm of bot accounts gains nothing. (Since 3 November new accounts start with a card trial instead.)
3. 12 October: we moved product mail to our own domain and considered a captcha. Our founder decided against it: there was no attack on the product yet, and a check at the door would only cost us real people. We wrote down when to ask again: if the mail provider warned us, or if the bounce share climbed well past 32%.
4. 3 November: at 63% that condition was met. Cloudflare Turnstile went live at about 05:40 UTC. The web sign-in sends a Turnstile token, and Supabase, with its CAPTCHA protection on, refuses a sign-up without a valid one, so the UK series’ direct requests fail as well. The iPhone and Mac apps now reach Supabase through an address on our own domain, with per-address limits and Tor refused.
5. 4 November: we fixed the captcha’s own problem, described below.
6. 7 November: our internal dashboard shows the pre-captcha rows apart, so nobody reads 880 rows as 880 people.

Results

• The first nine hours with Turnstile on: 4 sign-in letters sent, 0 bounced. In the 24 hours before: 34 letters, 23 bounced.
• The first 21 hours: 5 sign-in letters, 0 bounced; the UK series was refused three times; no Tor attempt at all.
• Before the captcha about 35 sign-up requests a day reached us, all of them bots: 14 from Tor through our page and 21 posted directly by the UK series.
• Rows in the sign-up table fell from 30–54 a day to about 3. Real confirmed sign-ups had been 2–4 a day from 30 October to 2 November, and there were 6 on 3 November. The people were still there; the bots were not.
• Every sign-in code letter sent between 3 and 7 November was delivered.
• The 30-day picture on 7 November: about 160 real people (106 through Google, 10 through Apple, 45 by a confirmed email code), 20–60 a week. Of the 760 code sign-ups before the captcha, 42 confirmed.

What did not work

• Our first number. Reading a confirmation rate without checking who signed up nearly sent us to fix a funnel that was not broken.
• The captcha hid its own box. On 3 November it refused 2 of 2 real people who signed in with a password. For a browser Cloudflare does not recognise, Turnstile shows a “Verify you are human” box. In Cloudflare’s own description, a managed widget chooses between a check that needs nothing from the person and a checkbox, by the visitor’s risk. Ours sat below the sign-in card, out of sight, and after 45 seconds the request went out without a token. On 4 November we made the box scroll into view, raised the wait to five minutes, let Turnstile retry by itself, and started recording each outcome: shown, passed, timed out, failed. Whether strangers’ browsers now get through the box is what those records are for; as of our last notes it was not yet proven.
• A new blind spot. App sign-ups now pass through our own server, so the auth logs show our server’s location, not the person’s. The country has to come from our own events.
• The chart looks like a crash. Sign-up rows dropped by about 90% overnight. Without the bots shown apart, that reads as a disaster. The real fall in visitors came earlier, on 31 October, and for another reason: ChatGPT stopped linking one of our pages.

About an hour after the captcha, the same morning, Hub also began asking new accounts for a card trial. That changes what happens after sign-up, not who signs up, which is why the comparison above uses only sign-up and mail data.

How to do it yourself

1. Before you read any sign-up or confirmation rate, split it by network: Tor (T1 in Cloudflare’s country field) and hosting providers first.
2. Watch the bounce share of your verification letters every week. It is the earliest sign that your sending domain is at risk.
3. Keep one group you know is human (paid visitors in an in-app browser work) and compare against it.
4. Tie anything free to something a bot cannot create cheaply, such as a connected social account.
5. Write down in advance the number at which you will add a captcha.
6. When you add one, close the side door too: direct requests to the auth API must need the token, and app clients should go through your own domain with per-address limits.
7. Make the challenge visible: scroll it into view, wait minutes rather than seconds, retry automatically and record every outcome.
8. Recount the past with the bots shown apart, or your charts will show a collapse that did not happen.

Numbers at a glance