Show HN: No more writing shitty regexes to police usernames (username.dev)

19 points by choraria ↗ HN
Every product that allows usernames eventually ships the same broken solution. Someone adds a blacklist. Then a regex. Then another regex copied from StackOverflow. It works just long enough to ship, and then `admin`, `support`, city names, brand impersonation, and obvious slurs start leaking through anyway. Everyone knows it’s fragile, but it gets ignored because "it’s just usernames".

I’ve had to rebuild this logic across multiple products, and I got tired of pretending it’s a solved problem. So I built *username.dev*, an API that answers a more useful question than "is this taken?" — it tells you what a username actually represents.

Instead of returning a boolean, the API classifies usernames into real categories like brands, public figures, places, system-reserved terms, dictionary words, premium handles, and offensive content, and returns structured metadata you can actually make decisions with. That means blocking impersonation without breaking legitimate users, stopping abuse without maintaining massive regex lists, and even monetizing high-demand usernames if that’s part of your product.

Under the hood it’s intentionally boring infrastructure: Cloudflare Workers at the edge, KV for fast reads, D1 for usage and analytics, and a simple HTTP endpoint (`GET /check?input=foo`). P95 latency sits around 300ms globally. There’s no ML magic, no black box, and no attempt to be clever — just fast, deterministic classification.

Pricing is usage-based and prepaid because subscriptions for infrastructure like this are annoying. There’s a free tier with 1,000 requests and no credit card. Use it, throw it away, or rip the idea off.

If you think regex blacklists are "good enough", usernames don’t matter, or this is a trivial problem, you’re probably already shipping bugs — they’re just not loud enough yet.

Tell me why this is a bad idea, what edge cases I’m missing, or what you’ve duct-taped together instead.

— Sourabh

16 comments

[ 2.4 ms ] story [ 38.9 ms ] thread
I want all the SaaS in my stack
I can’t tell if this is some complex joke or a real product. This is literally string.contains() as a service.

Edit: 300ms?!

Ok so taylorswift is reserved but taylor_swift and realtaylorswift can be used? It seems like impersonation would still be a problem.
I hate to say it but checking if a string is ~= some identifier might actually be something an llm might be useful for, since it doesn't need to be 100% accurate and does need to evaluate the string against a massive number of potential transformations.
So, I can’t use my legal name as a username because some random town with a few thousand people is named the same?
I can easily generate valid yet foul names that I’d prefer to not allow if I was into censoring usernames.
Congrats on the launch!

Do you expect / want this to be a business? This feels like the kind of thing where anybody big enough to pay for it will build it in house. And your pricing seems so cheap that even if you do win some it won't be enough.

Genuine curiosity but 300ms seems slow? Am I missing something? How big is the blacklist?

I love that you’re tackling this problem, and congrats on launching and getting this on HN!

This does feel like a real problem. The thing that concerns me (and likely other devs here) is that it adds an additional remote API dependency for a very core part of a system when a lot of people are trying to keep those dependencies to an absolute minimum. When your service goes down (not if), everyone who’s dependent on you will not be able to register new users, etc.

Is there any way you can offer this as a library instead? You deserve to get paid of course - maybe provide the library and initial data and charge for updates / premium checks, something like that.

I'm not understanding your categories. Every dictionary word is flagged? It seems any first or last name is a "public_figure" ("apple" is a "public_figure" and also a "brand", I guess that means there's someone named Apple? Tim Apple?)?

It "blocks profanity", but "shithead", "assfucker", etc. are allowed (not to mention obfuscating a restricted term even slightly, e.g. "sh1t")? Yes, the Scunthorpe problem exists, but you can do better, and should if you're expecting people to pay to wait 500ms.

Something that detects these sorts of things very well could actually be worth paying for, although it still would probably be better off as a library.

Why do I care as a website owner whether someone uses a brand name (e.g. cocacola) as their username on my site?

Same question, but for place names which seems completely innocuous?

Instead of us telling you why this is a bad idea, can you tell us why this is a good idea and what bugs we are shipping currently that this prevents?

Hmm… I do know, certain usernames in one language can have a bad meaning in others
Site is AI-generated. The post to HN is AI-generated.

As other comments point out, lots of holes.

I think nobody should pay for that.

Credits need to expire in X months. That way you don't have to keep the service running if it turns out not to get traction.
As a counter to my skeptical comments elsewhere, one way this could be a more useful service is if you go poll well known social media sites and see what the handle is associated with.

If the handle is taken by what seems like the same content/brand owner across FB, IG, reddit, X, etc. then that could add weight to a decision to reserve it (and be provided as useful context to your user as to why you recommend it be reserved), and if it's associated with something like hate speech or just crappy content someone who is doing brand research can know to look for alternatives.

You might need to invest in a copy of Roger's Profanisaurus, I just registered something absolutely obscene.
That's helpful. I think I need to beef up profanity keywords A LOT more than I'd originally anticipated. On it!