7 days, 4.26M requests, 3,650 real visitors.

The anatomy of one week

This is a real application with real customers, of a size most founders would call small. Here is what arrived at its front door over seven consecutive days.

Two and a quarter million requests were refused outright. Another 810,000 were slowed to a stop for asking too fast. The remainder was absorbed by caching and bot rules before it ever reached application code. What was left over — the traffic the product was actually built for — is the 3,650.

The distribution was not even, either. Quiet days sat at a baseline, then a spike day arrived and multiplied volume several times over within an hour. Nothing was launched or announced on those days. Someone’s scanner simply reached this address in its list.

Who is actually sending this

“Bot traffic” sounds like one thing. It is four different businesses, and only one of them is indifferent to you.

• 1Scrapers — pulling your content, pricing and structure, usually at a pace that costs you real money in hosting bills.
• 2Credential stuffers — replaying username and password pairs leaked from other companies’ breaches against your login form, because people reuse passwords.
• 3Card testers — running stolen card numbers through any public payment form to find which ones still work. Your checkout becomes their validation tool, and you absorb the chargebacks.
• 4Exploit scanners — probing for known vulnerable paths, exposed admin panels, forgotten config files and leaked keys. These arrive within hours of a domain going live.

What a fast-built app usually does not have

An app assembled in a weekend on an AI builder can be genuinely good software. What it typically lacks is not features — it is the unglamorous layer that stands between the internet and the features.

• Rate limiting — nothing stops one source sending thousands of requests a minute at your login or checkout.
• A web application firewall — no filter for the well-known attack patterns that make up most of this traffic.
• Bot rules — no separation between a search engine, a scraper and a credential stuffer.
• Auth hardening — no lockouts, no throttling on failed logins, no alerting on a spike of them.
• A cost ceiling — usage-priced infrastructure with no cap turns a scraper into a bill.

This is why “it works, I tested it” and “it is ready to be public” are not the same claim. The first is about your users. The second is about everyone else.

How this application stayed up

• Requests were filtered at the edge, before reaching application code — cheap to refuse, expensive to process.
• Rate limits applied per source and per route, with the tightest limits on login and payment paths.
• Bot rules separated known-good crawlers from everything else instead of blocking or trusting both.
• Failed logins were throttled and alerted on, so a stuffing run showed up as a signal rather than a slow leak.
• Spend limits meant a traffic spike raised an alarm instead of an invoice.

“The traffic was not a sign of success. It was the weather. The question is whether the roof was on.”