What happens the first time your AI-built app gets real traffic
Every AI-built app I've ever looked at was fast on the laptop it was built on. One person, one browser tab, clicking through the same three screens over and over while the tool wired things up. Then it launches, a post takes off or a bot finds the signup form, and for the first time the app has to answer more than one request at once. That's the moment app rate limiting — or the total absence of it — stops being a theoretical gap and starts being a bill or an outage.
I've seen this go two ways, and they're both bad in a way nobody budgeted for.
The 3am bill
Say your app calls an AI API on every request — summarizing something, generating something, answering a question. In the demo, that's you, clicking maybe forty times an hour. Then a bot finds the endpoint, or a script kiddie decides to hammer it, or — best case, worst case — a post about your app actually takes off and real humans start hitting it in a burst. With no cap on how often any one visitor (or non-visitor) can call that endpoint, every single request gets served, gets billed, and gets served again. Nothing in the app knows the difference between one enthusiastic user and a script firing the same request a thousand times a minute. You find out what happened the next morning, in an invoice email you didn't want to open, for usage that has nothing to do with anyone actually using your product.
That's what app rate limiting is, stated plainly: a rule, enforced by the server, that says how many times a given visitor, IP, or account can hit a given endpoint in a given window — and what happens when they go over it. Without it, "how much can this app cost me in an hour" doesn't have an answer. It's just whatever anyone with a browser tab decides to send.
The single box that falls over
The other version doesn't cost you money, it costs you the app. Most AI-built projects ship running on one server, doing one job — answer every request, run every query, render every page. That's completely fine for the traffic one person generates clicking around. It is not fine the moment a hundred people load the same page in the same ten seconds, because that one box has a ceiling, and nothing about "it worked when I tested it" tells you where that ceiling is. Past it, requests queue, then time out, then the page just doesn't load — for everyone, including the people who were already using it fine a minute ago. There's no caching layer sitting in front of the expensive parts, so every single page load redoes the same database query or the same AI call that the last ten visitors already triggered, instead of serving a cached answer that took none of that work to hand back.
Put no rate limiting and no caching on top of one server, and you've built something that behaves identically for a demo and for a slow week — and completely differently the one day it actually mattered.
Why "it was fast on my laptop" tells you nothing
This is the trap, and it's an honest one: speed while you're building genuinely does feel like proof the app is fine. It isn't proof of anything about production. Your laptop, testing solo, will never generate the concurrency, the repeat requests, or the malicious traffic that real exposure generates on day one. Cursor, Claude, Lovable, and Bolt are all extremely good at making an app that responds instantly to you — because "respond to the person building it" was the only load they were ever asked to handle. Nobody described "and also survive two hundred people or a bot arriving at once," so nobody built for it. I made the same point about the auth and data gaps in the security holes AI coding tools leave in every app — this is that same pattern, just showing up as a bill instead of a breach.
What production teams do instead
None of the fixes here are exotic, which is the frustrating part — they're just not things a single-user demo ever surfaces the need for. Rate limiting: cap how many requests any one IP, session, or account can make to a given endpoint per minute, and return a clear "slow down" response instead of quietly processing every one. Caching: put a layer in front of anything expensive — an AI call, a heavy database query, a report — so the fifth identical request in a minute gets the answer the first one already paid for, instead of redoing the work. And instead of one box that has to do everything, production setups spread load across more than one instance, so a spike gets absorbed instead of queued behind a single point of failure. None of these are rebuilds. They're additions, usually a day or two of work once someone has actually identified that they're missing.
The quick check
Open your app's codebase or ask whoever built it one direct question: "what happens if the same visitor hits this endpoint two hundred times in a minute?" If the honest answer is "it just runs two hundred times," you don't have app rate limiting yet, and that's worth knowing before a stranger — or a bot — finds out for you.
Your Turn: pick your most expensive endpoint — the one that calls an AI model or hits the database hardest — and ask that same question about it today. If nobody can answer it confidently, that's the layer to fix before you actively drive more traffic to the app.
This is one of the 13 layers we run through in the Launch-Ready Audit, alongside the auth and data-isolation checks I've written about before — because "it's fast" and "it holds up under real traffic" are two different claims, and only a load test tells you which one you actually have.
See how the Launch-Ready Audit works →
— Kyle Tysvaer, Founder, Insightful Eye Marketing