How to name a SaaS product

Name a SaaS product by generating twenty or more candidates, then running each through four pass/fail tests: say it once on a call, spell it from memory, confirm it reads as one word rather than two, and verify a short matching domain is obtainable. Keep only the names that pass all four, then buy the domain before you announce.

Key takeaways

• Judge names with tests, not taste. Four one-minute checks eliminate most candidates and remove the politics from the room.
• Two syllables is the target. Three works if it lands cleanly. Four or more loses recall in conversation, search, and ads.
• Descriptive names feel safe and are the most expensive mistake in SaaS naming: they box you into your first feature and resist trademark protection.
• Your ideal customer profile decides the extension, not personal preference. Developer tooling tolerates .dev and .app; enterprise procurement prefers .com.
• Generate wide before you narrow. Twenty to fifty candidates beats three names everyone is already attached to.
• Buy the domain as soon as the name passes. Landing pages and decks are cheap to redo; a name someone else registers is not.

The four pass/fail tests

Naming arguments stall because everyone is debating preference. Replace the debate with four binary tests: a candidate either passes each one or it does not, and a name that fails any test is out.

Test 1: Can you say it once on a call?

Say the name out loud, once, to someone who has never heard it. If they ask you to repeat it, or you feel the need to add "spelled like...", it fails. This catches names that look fine on a screen and collapse in a sales call.

Test 2: Can you spell it from memory?

Write the name down, look away, and write it again, then ask a colleague to type what they heard. Invented spellings fail constantly: dropping a vowel to dodge a trademark creates a permanent tax, because every verbal mention needs a correction.

Test 3: Does it read as one word, not two?

Compound names hide a decision. Is it CloudMeter or Cloud Meter? If two spellings are plausible, you will spend years owning one and watching the other send traffic elsewhere. Show the name in lowercase with no capitalization cue: if a reader cannot tell where one word ends and the next begins, it is too weak.

Test 4: Is a short matching domain obtainable?

Check availability before you get attached. The domain should match the name closely enough that hearing one gives you the other. If the obvious .com will not be sold, adjust the root word, accept an extension that fits the product, or walk away. Browsing a curated list of short SaaS domains is often faster than inventing names that turn out to be gone.

How many candidates to generate, and where to find them

Generate twenty at the minimum; thirty to fifty is better. The point is not to find one perfect name in a burst of inspiration, but to have enough material to be ruthless with the tests above.

• Customer language. The words users already use for the problem are the best raw material. Read support tickets and onboarding calls for recurring nouns.
• Benefit and outcome words. What changes for the customer? Speed, clarity, calm, control. Find a distinctive word that suggests the outcome.
• Adjacent categories. Borrow a pattern from a field sharing your product's personality: music, cartography, astronomy, botany.
• Invented and blended forms. Combine fragments of two relevant words. These tend to be the most trademarkable and available as domains.
• Curated marketplace lists. Names on open extensions show you the pattern space and the price level in one pass.

Write every candidate down without filtering. Volume is what makes the tests meaningful, and judging during generation kills volume.

Syllable count: two is the target

Two syllables is the sweet spot, and the reason is mechanical rather than aesthetic. A two-syllable name is short enough to type quickly, long enough to be distinctive, and easy to stress correctly on first hearing.

One-syllable names are excellent when they work, but the hardest category to clear: there are only so many short, pronounceable combinations, and the good ones are expensive.

Three syllables is workable and buys more room to be distinctive, but longer names lose recall in low-attention contexts. Past three, people start abbreviating, which means your brand is now two brands.

Why descriptive names box you in

• Your roadmap outgrows the name. A product called InvoiceRunner has a credibility problem the day you launch payments or a CRM. You rename, losing every backlink, or live inside a name that no longer fits.
• Descriptive marks are hard to protect. Trademark protection is generally stronger for distinctive, arbitrary names than for names that describe the goods and services themselves.
• The name does no work. A descriptive name communicates the category, which your hero would have done anyway. A distinctive name creates recall, which the hero cannot.
• Competitors sound identical. If every company names itself CategoryThing, none of the names differentiate. The one arbitrary name in the set stands out.

Suggestive is different from descriptive. A name that hints at the benefit or the shape of the product leaves room to grow while still giving the reader a hook.

How your ideal customer profile changes the answer

The same shortlist should be judged differently depending on who signs the contract.

Prosumer and self-serve SaaS

Your user discovers you through a search result, a social post, or a friend's screenshot. There is no procurement process and no legal review, and one person decides in seconds. Optimize for recall and for a name that sounds good when someone recommends it out loud.

Enterprise SaaS

Your user is not the buyer. The name passes through a champion, a manager, procurement, security, and legal, and each step is a chance for an unfamiliar domain to trigger a question with no upside for you. Enterprise naming favors names that are easy to say in a meeting and attached to a conventional extension. Read the .app vs .com comparison before you decide, because that choice sets your friction level for years.

Developer tooling and technical SaaS

Developers are the least extension-sensitive audience in software. They read documentation before they trust anything, and often prefer naming that signals the technical category directly. For this audience availability matters more than the extension: a short, clean .dev domain or .ai domain often beats a compromised .com.

Extension strategy for SaaS specifically

SaaS has one advantage: the product is delivered online, the customer already expects software, and your brand lives mostly in a browser tab and a chat message. That makes the extension a strategic choice rather than a default.

Start from the name, then work outward. If the root word is short, distinctive, and available on .com at a price you can justify, take it. If the .com is held by someone who will not sell, decide whether an alternative extension fits your ICP and go-to-market; for a developer tool or product-led app, it usually does. The IANA root zone database lists every delegated extension.

• Buy the exact-match domain for the name you will use. Avoid hyphens and prefixes like "get"; those workarounds add friction to every mention.
• Keep the name and domain matched across the product. A product called one thing on a domain that says another forces an explanation in every first interaction.

For the ownership side of the decision, domain name vs business name covers what you actually control, and the valuation tool gives you a price sanity check before you negotiate.

Product type to extension: a reference table

See live inventory across these categories on the .app, .com, and SaaS domain pages.

Your naming worksheet

Run this in order; each step feeds the next, and none depends on taste alone.

1. Write one sentence describing who the customer is and what changes for them: your source vocabulary.
2. Generate twenty to fifty candidates from customer language, benefit words, adjacent categories, invented forms, and curated lists.
3. Delete every candidate you would have to spell aloud for someone.
4. Run the survivors through the four tests: say it once, spell it from memory, reads as one word, short domain obtainable.
5. Score syllable count. Prefer two, allow three, cut anything at four or more.
6. Check that each survivor still makes sense if the product adds a major feature in two years.
7. Check the name against existing marks in your category before filing anything.
8. Shortlist three names and say each in a sentence a customer would use: "we use [name] for that."
9. Check availability for the final three, including the exact match and the likely misspelling.
10. Buy the domain for the winner, then start the trademark process.

The buying sequence: domain first, everything else second

Order of operations matters because the cheap artifacts are easy to redo and the expensive one is not. Lock the domain before the landing page, the pitch deck, and the trademark filing: a filing on a name whose domain you cannot own is money spent on a liability.

1. Run the four tests and pick the name.
2. Confirm availability on the extension that matches your ICP, and buy it the same day.
3. Register close variants and the likely misspelling, and point them at the primary.
4. Set up email on the primary domain with SPF, DKIM, and DMARC.
5. Build the landing page and deck on the name you now control.
6. Start the trademark filing with the domain secured.

If you are still torn between extensions, the decision rule in the startup naming guide settles it in a paragraph. If the shortlist is weak, generate more candidates: a mediocre name with a great domain is still a mediocre name.