I don’t think usernames are a solved problem.

In fact, I think a lot of teams are quietly lying to themselves about how fragile their username logic actually is.

I’ve done it too.

Early on, usernames feel boring. You add a uniqueness constraint, maybe a regex, block a few obvious words, and ship. It passes code review. It works in staging. Nobody complains.

Then real users show up.

And suddenly you’re dealing with impersonation, abuse, legal edge cases, support tickets, and weird Unicode tricks you didn’t even know existed.

This post is about why I stopped pretending this was a solved problem, what pushed me to build username.dev, and what I learned after getting called out on Hacker News.

The lie we tell ourselves

The lie sounds like this: "We’ll handle usernames later."

Most products start with a single question: is this username available?

But the moment you ship to real users, that question explodes:

• Is this a brand name?
• Is this a public figure?
• Is this a city or country?
• Is this offensive in another language?
• Is this a system term like admin, root, or support?
• Is this a premium or high-demand handle that should be treated differently?

Every product that allows user-generated identities eventually runs into the same quiet problem: usernames.

The difference is when you choose to confront it.

How this usually goes wrong

In practice, I see three common approaches:

1. A growing regex list
2. A blacklist table someone manually edits
3. Post-hoc moderation after damage is already done

I’ve implemented all three.

They all work at the beginning. They all fall apart under real usage.

Regex lists turn into unreadable landmines. Blacklists grow without structure or context. Moderation queues become a tax you never budgeted for.

The worst part is that all of these approaches only answer yes or no. They don’t tell you what the username actually is, or why it should be treated differently.

The mistakes I kept repeating

I kept seeing the same patterns across different products:

• Blocking English profanity while missing obvious abuse in other languages
• Forgetting to reserve internal paths and roles
• Letting brand impersonation slip through until legal got involved
• Realizing too late that short dictionary words had real economic value

Once usernames are live, fixing any of this is painful. Renaming users is messy. Policies change. Trust erodes.

That’s the part people underestimate.

What I decided to build instead

I stopped building a reserved usernames list or trying to answer "is this allowed?" and started asking a different question:

What is this username?

username.dev is an API that categorizes usernames instead of just approving or rejecting them.

It tells you whether a username is a brand, a public figure, a city, a system term, a dictionary word, or something else entirely, along with relevant metadata.

That context matters.

Once you have structured information, you can make your own decisions:

• Block system terms outright
• Flag brands for review
• Prevent impersonation
• Treat premium handles differently
• Apply different rules in different parts of your product

I’m not trying to enforce policy. I’m trying to give teams a reliable source of truth so they don’t have to reinvent this logic over and over again.

Why I finally shipped this

The honest answer is exhaustion.

I was tired of seeing the same bugs reappear in different codebases. Tired of seeing teams patch symptoms instead of causes. Tired of hearing "we’ll fix it later" about something that sits at the core of user identity.

Usernames feel small until they aren’t. By the time they hurt, they’re already everywhere.

What other teams told me

Once I started talking about this publicly, the responses were familiar:

• "We didn’t think users would actually try that."
• "We have a list somewhere."
• "We only block English words."
• "We’ll clean it up after launch."

Almost every team treats usernames as a UI concern instead of an identity, trust, and safety concern.

That’s usually a mistake.

Getting called out on Hacker News

When this hit Hacker News, I got pushback. Some of it was blunt. Some of it was uncomfortable. Most of it was fair.

People pointed out that users will always find ways around naive guardrails. They questioned whether categorization alone was enough. They challenged assumptions about coverage and completeness.

What I learned from that thread is that this needs to be a foundation, not a silver bullet.

The API is meant to be an exhaustive, centralized source of structured data. Variations, heuristics, and policy decisions belong on top of that layer.

HN also validated something important: nobody argued that the problem doesn’t exist. The skepticism was about execution, not relevance.

That told me I was working on a real problem.

This problem is already costing you

If your product has usernames, you’re already paying for this. You’re just paying in hidden ways: engineering time, support load, legal risk, or user trust.

You can pay that cost reactively, or you can deal with it earlier when the surface area is smaller.

I built username.dev because I didn’t want to keep paying it the hard way.

If you want to poke at it

There’s a free tier with no credit card. It’s there so you can test your existing logic against a more exhaustive dataset and see what falls through.

At worst, you’ll confirm your approach is solid. At best, you’ll catch something before your users or your lawyers do.

Either way, you’ll learn something.

That alone makes it worth testing.