The product is built. The MVP is live, or close enough that you're testing it on real users, and the name is still whatever you typed into git init at 2am: untitled-project, my-app, api-v2. Naming a company product is a months-long exercise with agencies, focus groups, and trademark attorneys clearing every option before anyone commits. Naming a micro-SaaS is nothing like that. You need a name this week, alone, with no committee, for a product that might pivot in three months anyway. The constraints are different. The tools are different. The bar for what counts as good is different. This guide is for that version of the problem.
The micro-SaaS naming constraint no other guide covers
A micro-SaaS name does not just have to sound good. It has to survive four separate systems at once, and most naming advice only thinks about one of them.
The name becomes the GitHub repository slug, which has its own formatting rules: lowercase, hyphens instead of spaces, no special characters. If the product ships a library or a CLI, the name also becomes the npm package name, and npm enforces even stricter rules than GitHub does. Then there's the domain, or at least a subdomain: .com availability for short English words is close to zero, but .dev, .app, and .io all have far better availability for developer tools. And there's Google: a name that returns fifty thousand unrelated results is effectively invisible, while an invented or specific name surfaces on the first page immediately.
Most solo founders pick a name based on how it sounds, then find out the domain is taken, the npm package already exists, and the GitHub repo name looks wrong sitting next to their other repos. The constraint check has to happen first, not after you've already printed the stickers. This is the same problem open source maintainers run into, and checking for name collisions works the same way whether the project ships as a library or a hosted product.
What the name actually needs to do (not what it needs to sound like)
Drop the aesthetics question for a minute. A micro-SaaS name needs to do three things. It needs to be findable when someone half-remembers it after seeing it mentioned once in a tweet or a Slack thread. It needs to be typeable without friction in a terminal, a URL bar, or a Stripe invoice description. And it needs to be available as the same identifier everywhere you'll actually use it: the domain, the GitHub org, the npm scope. It does not need to be clever. It does not need to be evocative. It does not need agency approval, because there is no agency.
If you want the creative side of this decision too, not just the constraint checklist, NameKit's guide to naming a side project covers the broader angle: how to land on something that feels right, not just something that survives a domain search. That guide and this one are meant to work together, not compete.
Four naming patterns that work for micro-SaaS
Four patterns show up again and again among micro-SaaS products that got the name right. None of them require creative genius, just a willingness to check availability before falling in love with an option.
The function-first name
Describe exactly what the product does using plain words, then check if that description is available as a name. csv-to-json, invoice-tracker, uptime-ping. These names tend to rank well in search because they match what people actually type when they're looking for the thing you built. The tradeoff is that a purely descriptive name can box you in if the product expands past its original scope, but for a micro-SaaS solving one specific problem, that's a reasonable price to pay.
The invented short word
A made-up word, four to seven characters, pronounceable, with no prior search results, that can be claimed everywhere at once. The checklist: type it in a terminal without needing the shift key, say it out loud to confirm it's actually pronounceable, search it on Google in quotes and confirm the results page is empty or close to it, then claim the domain, the GitHub org, and the npm scope the same day you decide. NameKit's CLI naming guide covers why the shift key matters for developer tool names in more depth, and the same logic applies here.
The compound word
Two short, specific words joined or hyphenated that together describe what the product does. Raycast, Supabase, and Upstash are all examples from the developer tools ecosystem. The compound works when neither word alone is specific enough to stand as a name, but together they form a distinct identifier nobody else is using. The failure mode is a compound that's too generic on both sides, or one that's technically accurate but too long to type comfortably.
The narrow domain claim
A real word from the exact domain the product operates in, specific enough that it doesn't compete with everything else that word can mean. This is how Linear works for project tracking, Zed works for a code editor, and Clerk works for auth. The risk is the same one the ImageMagick convert command ran into: if the word is already claimed in another technical context, you'll be fighting that confusion for as long as the product exists.
What to do when your first choice is taken
Most founders handle a taken name badly. They either give up and settle for something worse, or they burn a week hunting for an alternative that never quite feels right. There's a shorter path.
Add a qualifier that makes the name more accurate, not less: not app2, but csv-sync-worker instead of csv-sync. Try a different TLD, since .dev and .app both have dramatically better availability for developer tool names than .com ever will. Publish the npm package under a personal scope, @yourusername/packagename, so a taken unscoped name doesn't block you from shipping at all. Or read the taken name as a signal: the space has demand, so pick something adjacent but clearly distinct instead of a near-copy that invites confusion.
The same logic behind scoped npm packages applies directly here, and it's worth reading in full if the unscoped name you wanted is already gone.
The five-minute constraint check
Before you commit to any name, run it through this process. Each step is one specific action with a specific place to do it.
- 01Search the exact name on GitHub. Check the top results for anything that could be confused with your product, not just an exact repo match.
- 02Search the exact name on npmjs.com. If the unscoped package is taken, decide immediately whether the scoped version works or you need a different name.
- 03Search the name on Google in quotes. Count how many unrelated results show up on the first page before deciding the name is clear enough.
- 04Check domain availability for .com, .dev, .app, and .io. You don't need all four. You need at least one that feels right and that you can claim today.
- 05Type the name as it would appear in a terminal command and a git clone URL. If it needs the shift key, adds friction, or looks wrong in monospace, fix it before you commit to it.
Name it, claim it, ship it
For a micro-SaaS, the constraint check matters more than the creative brainstorm, because a name that fails one of the five checks above has to be changed later, usually under worse time pressure than you're under right now. Generate a batch of candidates first, run each one through the constraint check, then commit to whichever one survives. NameKit's Startup Name Generator is a solid place to start generating those candidates before you start checking them against GitHub, npm, and Google.
Frequently asked questions
Does a micro-SaaS need a .com domain?
Not necessarily. For developer-focused tools, .dev and .app are widely accepted and have far better availability than .com. What matters more is consistency: the same name across your GitHub repo, npm package, and domain, rather than which specific TLD you land on.
Should a micro-SaaS name describe what it does?
Usually, yes, especially at launch when you have no brand recognition to lean on. A descriptive name does part of the marketing work for you. Invented names can work too, but they take longer to establish, and that's a real cost when you're building alone.
How long should a micro-SaaS name be?
Short enough to type without effort in a URL or a terminal command. Two to four syllables is a practical ceiling. If you can't say it in one breath and type it without looking at the keyboard, it's probably too long.
Can I rename a micro-SaaS after launch?
Yes, but it costs more than getting it right the first time. A GitHub repo rename redirects automatically. An npm package rename does not. A domain rename means broken links and split search equity. The earlier you catch a bad name, the cheaper the fix ends up being.
What if every name I want is taken?
Try a personal npm scope, a less common TLD, or a qualifier that makes the name more specific rather than less. Task-runner being taken doesn't mean pg-task-runner is taken too. Specificity is usually what opens availability back up.