9 — Profitable at 100 users, bankrupt at 10,000
What happens when someone calls this 10,000 times? Two invoices arrive for that question: the attacker's, and the cloud provider's.
There are two failure modes here and one root cause. No rate limiting invites abuse; no cost model invites an organic cost inversion. Both exist because "what if someone hammers this endpoint?" was not included in the prompt. The mechanics are simple: exposed keys, no throttling, client-side gating. Traction is usually the trigger. The same virality that should read as a growth win instead reads as "I'm under attack," because nothing was built to tell the difference between a thousand real signups and one script hitting the same endpoint a thousand times.
One endpoint, no throttle, every request billed. The meter doesn't care whether the traffic is malicious or just unbounded.
Spending caps aren't rate limits — billing enforcement lags real-time usage, so a cap is reactive where a limiter is preventive, and you need both plus a budget alert that actually pages someone. I've been on both ends of that lag myself: a surprise bill that arrived well after the spending was already done, and separately, a mid-month budget alert that had me pulling the team off everything else to get on top of it before it became the surprise bill. You often hear people complain about a bill landing far above the cap they'd set, and that's exactly why — there's a lag between the event that burns the credit and the bill for the credit itself. Denial-of-Wallet is the new Denial-of-Service.
I've used this example before, in the post on your frontend talking straight to the database — it's worth returning to here because it's as much a cost story as a security one. On 15 March 2025 the builder announced "zero hand written code." By 17 March: "guys, i'm under attack" — maxed-out API keys, the subscription paywall bypassed, junk writes hitting the database. On 20 March he gave up on the vibe-coded app in favour of a no-code platform. It's simultaneously a security story and a unit-economics story — a maxed-out key is someone else's usage landing on your bill, whether they're an attacker or just a heavier user than your pricing assumed.
Cost per user rises superlinearly — power users deepen usage, and scraper traffic scales with visibility, not paying customers. The crossover is where growth starts costing you money.
AI can't see this failure mode coming, and it won't tell you to kill the project before the bill does — it'll happily let you embarrass yourself instead.
This is a well-solved software engineering problem: rate limiting, windowing, tiering, and treating cost-per-request as much of a metric as latency.
If you've shipped fast with AI tools and want a second pair of eyes before it goes further, that's exactly what a vibe code audit is for — there's a free one you can run yourself, or book time with me directly.