DEV Community

Cover image for How I built a free, unlimited, no-login AI chat and kept abuse under control
GetAskAl
GetAskAl

Posted on

How I built a free, unlimited, no-login AI chat and kept abuse under control

Every AI chat I tried wanted something before the first question. An email. A verification link. A card, "just to confirm you're human." Or it let me in and started counting: five messages, then a wall.

So I built GetAskAI: a free AI chat with no login, no app and no message counter. You open it, type, get an answer.

Then I found out what that actually costs.

This post is about the part nobody puts on the landing page: when you remove the account, you remove the one thing that makes abuse control easy, and you inherit a bill that scales with strangers.

Why no login is a technical decision, not a marketing one

The pitch writes itself. No signup, no friction, ask and go.

The engineering reality is less fun. An account is not just a retention hook. It is:

  • a stable identity to attach usage to
  • a natural rate limit boundary
  • a cost ceiling per human
  • an abuse trail you can ban

Delete it and every one of those disappears at once. You are now serving inference, the most expensive thing on your bill, to anonymous traffic, with no way to say "this is the same person as five seconds ago."

That is the whole problem. Everything below is a consequence of it.

The bill is the constraint, not the traffic

Most side projects have a fixed cost and variable traffic. A spike is a bragging right.

An LLM product inverts that. There is no meaningful fixed cost to amortise. Every request costs real money, and the cost scales linearly with usage. A traffic spike is a cost spike. Going viral is an invoice.

Which means the honest framing is not "how do I stop bots." It is:

Every request has a price. My job is to make sure a human asking a real question always gets served, and everything else gets served last or not at all.

Rate limiting stops being a security feature and becomes a business model. That reframing changed every decision after it.

Why the obvious answers do not work

I am not going to publish my exact setup, mostly because writing down your abuse rules is how they stop working. But it is worth saying why the first three things everyone reaches for are weaker than they look.

IP limits. Carrier-grade NAT puts entire mobile networks behind a handful of addresses. A university, an office, a co-working space, all one IP. Set a limit tight enough to stop a script and you have banned a country's mobile users on a bad day. And residential proxy pools rotate through real consumer IPs, so a determined scraper looks like a hundred innocent people. IP is a weak hint, not a boundary.

Browser fingerprinting. Technically effective, and it quietly destroys the product. The whole promise is that I do not build an identity for you. Fingerprinting builds one anyway, just without telling you. It is the same tracking with worse ethics. I decided this was off the table, and I want to be clear that this is a values call, not a technical one. It costs me abuse resistance. I pay it.

CAPTCHA on everything. Kills the thing that makes the product worth using. The whole point is five seconds from question to answer. A puzzle in front of every message is a signup form with extra steps.

What actually worked, in one line

Stop thinking about who and start thinking about cost.

I do not need to know your name. I need to guarantee that any single visitor, whoever they are, can never cost much, and that the cheap path is the default while the expensive things stay the exception. Once you frame the problem that way, most of the design follows from it, and none of it needs an account.

The principle underneath all of it: degrade, do not block. Suspected abuse gets slower, not a hard error. A false positive then costs a real person a little latency instead of their answer. When you cannot identify people you will have false positives, so make them survivable.

On live answers and files

Two things people always ask about.

A model on its own is a frozen snapshot, so anything genuinely recent is a confident guess, which is the worst kind. There is a step that pulls in fresh information when a question needs it, used sparingly rather than on every message, because that is expensive too.

And files. Images and PDFs work, and they are never written to disk. A file is held only long enough to answer the question, then it is gone. That is not a policy line, it is architecture: a file that is never stored cannot leak, cannot be subpoenaed, and cannot be sold by whoever buys the company later. It also means I cannot debug your failed upload, which is a real cost I accept.

Would I do it again

Yes, with less certainty than I had at the start.

The no-login decision is genuinely good for the user and genuinely bad for the business in every measurable way. No email list. No retention. No cohort analysis. Every visit starts cold. I have no idea if the same person came back yesterday, and by design I never will.

What I would tell someone about to do this:

  1. The rate limiting is the product. Not a chore you bolt on later. If you cannot serve one human cheaply, you cannot serve a thousand at all.
  2. Degrade, never block. You will have false positives. Make them cost latency, not the answer.
  3. Decide what you refuse to build before you need it. Fingerprinting looks reasonable at 3am during an attack. Decide at noon.
  4. Ads are a cleaner incentive than a free tier. With a paywall I would spend my time tuning where the wall goes. With ads, the tool being good and the tool making money point the same direction.
  5. Costs scale with strangers. Budget for the spike you want, not the traffic you have.

Not a business yet. A tool that pays for itself, if the ads hold.


It runs at getaskai.com. If you find a hole in the rate limiting I would genuinely rather hear it from you than find it on the invoice.

Happy to talk about the tradeoffs in the comments.

Top comments (0)