MMatt Senter
nowprojectsaboutconnectblog

← Blog

How I Name the Things I Ship

July 29, 2026 · Matt Senter

The short version

Naming a product is one of the few choices that follows it everywhere: onto the App Store, into the URL, and out of a stranger’s mouth when they recommend it to a friend. My method is a set of practical tests, not a branding framework. Can someone spell it back after hearing it once? Is it short enough for a menu bar? Can I get a usable domain? Does it point at the job? My names fall into two families. Premail, Comoji, and SeedMatrix fold the job into the word, while Burly and StockCar are short, sturdy words the product has to teach. The trap I talk myself out of most is the clever pun only I fully get, because a name you have to explain has already lost. When AI makes competent apps cheap, being findable and sayable is an edge a model will not hand you. I do not lock a name until I can describe the product in one sentence, and then I leave it alone.

Naming a product feels like the smallest decision in the whole build. It is a word. You can change a word. And yet it is one of the few choices that follows the product everywhere it goes, onto the App Store, into the URL, out of a stranger's mouth when they try to tell a friend.

I have shipped enough small things now to have a rough method for it. It is not a branding framework. It is closer to a set of tests I run before I commit, so I do not end up defending a cute name for the next three years.

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.

What makes a good product name?

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.

The USPTO lands in a similar place from the legal side: itfavours names people can remember, pronounce, and spell, while warning that the most descriptive name is often the legally weakest. It also points out that checking a name meanslooking well beyond an exact match. An available domain is not clearance.

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.

Why do clever names usually backfire?

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.

Matt Senter

Matt Senter

Founder, entrepreneur, and CEO based in Durham, NC, with 30 years building software and 18 companies and products founded. Currently Founder & CEO of Senternet and Co-Founder, COO, and CTO of BeeReady, and the builder behind Orgabot, Highwire, StockCar, Premail, Comoji, Burly, and Weatherling. More about Matt · Get in touch.

← All postsNext: Small, Local Software →

On this page

  • A name is the first promise
  • What makes a good product name?
  • Two families of names
  • Why do clever names usually backfire?
  • Why this matters more now
  • Name it once, and mean it
  • The short version

Keep reading

  • Why Most of My Apps Are Free, and One Is NotStockCar, Comoji, and Burly are free. Premail is not. How I decide when an indie product should have a price and when it should not.
  • Why I Built BurlyWhy I built Burly, a macOS link router that sends each link to the right browser profile, and how it compares to Browserosaurus, Choosy, Velja, and Bumpr.
  • Why I Build Small, Local Software That Does One ThingAI makes it cheap to build sprawling apps fast. I keep shipping tiny, single-purpose tools that run locally with no account, on purpose. Here is why.

More on Indie software →

This post is about Comoji. Read the Comoji case study →

© 2026 Matt Senter · Created by Matt Senter of SenternetMade with OrgabotDurham, NCBuilt for buildersaboutblogToolsPrivacyTerms
EnglishEspañol简体中文Français日本語PortuguêsDeutsch