Forem: Sourabh Choraria

I think most teams are lying to themselves about usernames

Sourabh Choraria — Fri, 26 Dec 2025 18:12:27 +0000

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:

A growing regex list
A blacklist table someone manually edits
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.

Webhooks for Sheets

Sourabh Choraria — Thu, 14 Apr 2022 18:51:38 +0000

Hey peeps 👋🏾

Just a quick share here that my upcoming product — Webhooks for Sheets is now LIVE on Product Hunt and you can start your experiments with the add-on here —
https://www.producthunt.com/posts/webhooks-for-sheets

Would love to hear back from you about ways in which the tool can be improved or if you'd like to contribute to the actual Webhook code, you can do that too from here —
https://github.com/choraria/google-apps-script/blob/master/Sheets/Webhooks

I'll continue sharing more updates on Twitter and LinkedIn so feel free to follow along and engage in whatever way you feel like ☺️

Cheers,
Sourabh

develop & implement some of the most common uses of puppeteer via pptr.io

Sourabh Choraria — Sat, 09 Oct 2021 11:05:30 +0000

background

in case this is the very first time you're hearing about puppeteer, i'd highly recommend googling what it does first and also refer to the official documentation to get a quick sense of what it's all about.

here's a video from the docs that should help you get started too —

intro

a couple days ago, i launched pptr.io with the purpose to deliver a free & open source api that runs puppeteer as a service — think of it a spin-off of the original pptraas.com (defunct) tool.

the entire service is powered by vercel — specifically, it's serverless functions offering.

as of this post, the api is able to deliver the following —

capture a screenshot from a given url
fetch metrics of a page
get a timeline trace
render page as a pdf

...more to be added soon 😉

i've ensured to keep the documentation as simple as possible and you can find all you need on that here —

choraria / pptr-io

puppeteer as a service.

pptr.io

a free and open-source api that runs puppeteer as a service.

usage
1. screenshot
2. metrics
3. trace
4. pdf
5. meta
6. duckduckgo_profiles
7. version
contributing
credits
license
host your own

usage

base url:
- production: https://pptr.io/
- preview (staging): https://dev.pptr.io/
default path: api/
endpoint: any one of the individual .js files in the api folder
- ignore the index.js file inside the api folder

endpoints

screenshot

task: takes a screenshot of the input url
class: page.screenshot
method: GET
api: https://pptr.io/api/screenshot?url=https://dev.to
source: screenshot.js

optional params	type	description	default
`width`	number	width of the screenshot.	`1920`
`height`	number	height of the screenshot.	`1080`
`deviceScaleFactor`	number	device scale factor (can be thought of as DPR).	`1`
`fullPage`	boolean	when `true`, takes a screenshot of the full scrollable page.	`false`
`type`	string	can be either `jpeg`, `png` or `webp`.	`png`

sample output of the screenshot endpoint

metrics

task: fetch metrics of the page
class: page.metrics
…

View on GitHub

contribute

i'm actively working to —

partner with folks who'd want to add more methods to the api.
check-in with the community on some feedback & inspiration on what new can be done.

discuss

feel free to reach out in case you have any cool problem statements that you'd like to see solved using this api —

// Detect dark theme var iframe = document.getElementById('tweet-1444732327133806595-194'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1444732327133806595&theme=dark" }

Workbook Statistics - Google Spreadsheet Add-on

Sourabh Choraria — Fri, 10 Jan 2020 19:32:57 +0000

Get stats for your current active sheet and the entire workbook in one place.

Finally! Its live on the G Suite Marketplace 🎉

Would love for some of you to critique it so I can improve 😅 will soon put out the code on GitHub and open-source this + also share a post on the entire process.https://t.co/5koer6xQt2 pic.twitter.com/goyRZFYEoJ
— Sourabh Choraria (@schoraria911) January 10, 2020

Post install tip:

Refresh the sheet
Navigate to the 'Add-ons > Workbook Statistics' menu
Click on 'Get Stats' and wait until the add-on fetches the details
Re-navigate to the 'Workbook Statistics' option and then hover over any of the 3 available options
Hit 'Refresh All' to update stats

You can find stats for the following:

Current Sheet:
- Sheet Name
- End of Sheet = Cell reference of where the sheet ends
- Cells with Data
- Named Ranges - similar to "Tables" in MS Excel
- Pivot Tables
- Cells with Formulas
- Charts
Entire Workbook:
- Count of Sheets
- Cells with Data
- Named Ranges
- Pivot Tables
- Cells with Formulas
- Charts

You can always connect with me on Twitter to share any suggestions or feedback as well!

Build a Telegram Bot using Google Apps Script

Sourabh Choraria — Sun, 27 Oct 2019 08:04:18 +0000

Originally posted on script.gs

I just launched SphygmoBot which is a human "Heartbeat" checker that pings you every 24 hours to see if you're alive and notifies someone in case your response fails.

It uses:

Google Apps Script for it's backend architecture
Google Spreadsheet as a database
Telegram Bot API and it's webhook services

You can access the entire codebase on my GitHub repository here.

Build a URL Shortening service using Google Apps Script

Sourabh Choraria — Sun, 13 Oct 2019 09:31:51 +0000

Originally posted on script.gs

It all started when I came across Jonathon Broughton's technique to use Apps Script web apps within embeded ifames in Github Pages, which got my gears turning for I was jonesing to make use of an undocumented parameter within Apps Script's doGet function - pathInfo; which in the end, blew up on my face and I rolled back to using queryString instead.

You can access the working demo on (https://tmt.pw) and refer the entire codebase (with documented instructions) on my github repository.

The architecture is rather not that of a conventional URL shortening and redirection service because my methodology does not throw a 301/302 permanent redirect status but instead, uses JavaScript's window.open to have a new URL loaded on the same browser window (using _top), based on the slug.

Midway through the development I get to know that Github Pages serves a 404 if it doesn't recognise the path or have a resource already allocated against it in the project repository and that's what led me to plug Rafael Pedicini's Single Page Apps for GitHub Pages - I doubt I'd have been able to host my service on Github Pages (for free), had it not been for this ingenious technique to deploy single page apps.

Access to the original resources can be found here -

The entire folder on my Google Drive
A Spreadsheet that acts as the datasource
Finally, the script itself

I'm still working my way through a whole bunch of caveats and from my bucket list but I'm more than happy to have your contributions considered too.

Major learning from all of this was that in order to use e.pathInfo, we'd need to append the script URL and in doing so, end up having Apps Script prompt user to login using their Google accounts (not particularly to allow script permissions but just because - we don't know yet).

Overall, it has been a humbling experience for having to publish a tool of my own 😊 - also available on Product Hunt.

Forem: Sourabh Choraria

I think most teams are lying to themselves about usernames

The lie we tell ourselves

How this usually goes wrong

The mistakes I kept repeating

What I decided to build instead

Why I finally shipped this

What other teams told me

Getting called out on Hacker News

This problem is already costing you

If you want to poke at it

Webhooks for Sheets

develop & implement some of the most common uses of puppeteer via pptr.io

background

intro

choraria / pptr-io

puppeteer as a service.

pptr.io

table of contents

usage

endpoints

screenshot

metrics

contribute

discuss

Workbook Statistics - Google Spreadsheet Add-on

Build a Telegram Bot using Google Apps Script

Build a URL Shortening service using Google Apps Script