How I Name the Things I Ship

A name is the first promise

Before anyone opens your app, the name has already told them something. It sets an expectation, and the product either meets that expectation or spends its first thirty seconds correcting it. That is a bad trade. The best thing a name can do is get out of the way and let the thing be what it is.

So I try to make the name carry a little bit of the job. Not the whole pitch, just enough that when someone hears it and then sees what it does, the two click together instead of fighting. When a name and a product agree, the product feels inevitable. When they disagree, everything downstream, the copy, the icon, the first impression, has to work harder to paper over the gap.

The bar I actually use

I do not brainstorm a hundred options. I hold a candidate up against a short list of practical questions and see what survives:

• Can I say it out loud once and have someone spell it back correctly?
• Is it short enough to live in a menu bar, an icon label, and a sentence?
• Can I actually get a usable domain and handle for it?
• Does it point at the job, or at least not point away from it?
• Will it still make sense if the product grows a little?

Most clever ideas die on the first two questions. A name you have to spell out letter by letter is a name that leaks users every time it gets spoken. A name nobody can search for is a name that makes you pay for every visitor twice. These are not glamorous constraints, but they are the ones that decide whether a name helps you or quietly taxes you forever.

Two families of names

When I look at what I have actually shipped, the names fall into two camps, and both are fine as long as you know which one you are choosing.

The first camp folds the job into the word. Premail reads as what it is: it works on your mail before the mail reaches you. Comoji is emoji you summon with a colon, and the name compresses that mechanic into something you can say. SeedMatrix is a grid of seed performance data, and the name says so. Even BeeReady, the nonprofit, leans on a phrase people already know so the mission is legible before you explain a thing. These names do a little work for free.

The second camp does not describe the job at all. It just wants to be short, sturdy, and easy to remember. Burly does not explain that it routes links to the right browser profile, and it does not need to. It is two easy syllables of personality that stick, with URL hiding in the middle of the word for anyone who notices. StockCar works the same way: it reads as fast and concrete before it reads as a stock briefing you listen to in the car, which is exactly what it is. A name like that carries little meaning on day one, so the product has to teach it. That is a fair deal when the word is memorable enough to be worth teaching, and a bonus when the meaning is sitting there waiting to be found.

The clever-name trap

The failure mode I have to talk myself out of most often is the pun only I fully get. There is a specific kind of naming high where you land on something layered and witty and feel briefly like a genius. Almost every time, that name is worse than the boring one sitting next to it.

The problem with a too-clever name is that the cleverness lives in your head, not the user's. They do not get the reference. They mishear it, misspell it, and cannot find it again. You end up explaining the joke, and a name you have to explain has already lost. I would rather have a plain name that works than a clever one I keep apologizing for.

Why this matters more now

It would be easy to treat naming as vanity, especially now that building is so cheap. But that is exactly why it matters more, not less. When AI lets anyone generate a competent app in an afternoon, the world fills up with competent apps. Being good is table stakes. Being findable, sayable, and memorable is one of the few edges left that a model will not hand you.

A generator can write the feature. It can even suggest a name. What it cannot do is know how the word will feel in your mouth, whether it fits the rest of what you have built, or whether you will still be proud to say it in a year. That judgment is the human part, and it is the same judgment I keep coming back to in this work: the building is cheap, and deciding is the job.

Name it once, and mean it

There is a tension in when to name. Name too early and you can fall in love with a word before you know what the product is, then bend the product to fit the name. Name too late and you ship something with a placeholder that never leaves. My compromise is simple: I do not lock a name until I can say what the product does in one sentence, and once I can, I try to name it and be done.

That rule doubles as a check on the product itself. If I cannot name the thing, it usually means I have not decided what the thing is yet. The struggle to name is often the product telling me its scope is still blurry. When the job is clear, the name tends to come easily, because there is finally something specific to point at.

And once it is named, I treat the name as settled. The name is the permalink, the handle, the word in someone's recommendation. Changing it later is not a rebrand, it is throwing away every bit of recognition you had started to earn. So I would rather spend the hour up front and then never touch it.

The short version

Before I commit to a name, I make it clear four hurdles:

1. Say it once. Can a stranger spell it back?
2. Search it. Does it lead to me, or to noise?
3. Match it. Does it agree with what the product actually does?
4. Keep it. Will I still want to say it out loud in a year?

None of this guarantees a great name. But it reliably kills the bad ones, and for a solo builder shipping small things, killing the bad ones is most of the battle. A name that is honest, sayable, and yours is worth more than a clever one, and it costs the same to choose. So I choose the honest one, and then I get back to building.

← All postsNext: Small, Local Software →