You've had the idea for three days. You've sketched the features, picked a stack, maybe even opened Cursor or Lovable and pasted in the first prompt. Then someone asks what it's called and you say, "I don't know yet." And somehow, a week later, you still don't know. You've opened a dozen naming sites. You've asked an AI to generate 50 names. You've shortlisted six. You haven't shipped a line of code.
The name is eating the project.
Here's the thing: naming gets either ten minutes (and you regret it) or three weeks (and you ship nothing). Both are mistakes, but the second one kills more projects. A 30-minute framework gets you out of the loop without making something you'll cringe at in six months.
The four name archetypes and when each one works
Before you brainstorm anything, it helps to know what kind of name you're even reaching for. There are four archetypes, and they're not equally good fits for every product.
Descriptive names say exactly what the thing does. Screaming Frog. Buffer. Forecast. These names are the easiest to understand, tend to rank well for the thing they describe, and age well because the description stays true. The downside is they're harder to trademark, and the obvious ones are taken.
Evocative names suggest a feeling or mood without stating a function. Notion. Linear. Vercel. They're flexible because they don't lock you into what the app does today, but they cost more in early marketing because users have to learn the association.
Invented names are words you made up or heavily distorted. Figma. Supabase. Vercel (again, a portmanteau). These are the easiest to trademark and nearly always have the domain free, but they start at zero brand recognition. If you're pre-launch with no audience, invented names are actually underrated.
Compound names smash two words together. GitHub. Tailwind. Draftlytic. They thread the needle: immediately meaningful enough to understand, usually available as a domain, and distinctive enough to stand out in a search result.
For most indie apps at zero traction, the honest advice is: descriptive or compound gets you to first users faster because people understand it without an explanation. Evocative and invented work beautifully once you have distribution. Pick based on where you are, not where you hope to be.
The kill list: what to filter out before you fall in love
You've brainstormed 20 names. Good. Now run every surviving candidate through this filter before you get attached to any of them.
Hard to spell. Say it to a person; watch them try to type it. If they hesitate, it's failing. Phonetic misspellings mean missed direct traffic, missed word-of-mouth, and a Stripe page that customers can't find. Anything with a "ph" where people expect "f," a silent letter, or more than two syllables you'd have to spell out when speaking aloud should raise a flag.
Hard to say aloud. If you have to explain pronunciation the first time someone reads it, the name is already working against you. Say it out loud to yourself right now. Did it feel natural?
Sounds like a competitor. Open a browser and search for the name. Then search for the name plus your category. If a funded competitor with 50,000 users owns that namespace, you're building brand confusion for them for free. Not the same company, but something close enough that a confused customer Googles both is also too close.
Trademark conflict. You don't need a lawyer for a quick check. Go to USPTO's TESS database (opens in new tab) and run a basic search, or use the EU trade mark registry if you're in Europe. You're looking for exact matches or near-matches in the same category. If there's a hit, scratch the name. Trademark fights are not a startup problem you want.
Typo exposure. What happens if someone accidentally types one letter wrong? If they land on a parked domain, you've just lost a conversion. If they land on something embarrassing, that's worse. Swap adjacent keyboard letters and see what you get.
Run all 20 through this list honestly. You'll probably have four to six survivors.
Domain reality in 2026: what actually matters
You've whittled to five names. Time to check domain availability, and this is where a lot of people make decisions they'll regret.
The current reality: .com is fine. .app is fine. Weird TLDs are not.
.com is still the default expectation. If you can get the .com of your name and the brand feels right, take it. But .app is also well-understood, and for an actual application, it scans immediately. A lot of legitimate products launched in the last few years live on .app and nobody thinks twice about it.
What doesn't work: .biz, .info, .xyz, .io (increasingly crowded), and any other TLD that requires you to explain why you chose it. If your name only works on a TLD that makes people pause, consider it a signal the name is too crowded, not that the TLD is the solution.
For each name that clears the domain check, do two more things before you move on:
Check the social handles. Go to Instagram, X, and LinkedIn (or whichever platforms matter for your audience). You don't need all three to be perfect, but if all three are taken and active, you'll spend your marketing life trying to route around someone else's brand. Use a tool like Namecheckr to scan multiple platforms at once.
Check the Stripe name (or whatever payment processor you use). When a customer sees your company name on a credit card statement, does it read like a real company? "DRAFTLYTIC.COM" reads fine. "NOTESNXT LLC" reads like a transaction someone disputes. Think about what lands in their statement and whether their first reaction is confusion or confidence.
You do not need the exact handle on every platform. A getYourAppName or tryyourappname handle is totally fine. But you want to know going in that you have a workable path.
The say-it-out-loud test
This sounds simple and it's actually where the finalists get separated.
Find a person who is not you and is not invested in your idea. It can be a friend, a family member, a coworker. Tell them the name, don't spell it, don't write it down. Then ask them to spell it back to you.
If they spell it right, good.
Ask them what they think it does. Don't prompt them. If their answer is somewhere in the vicinity of your actual product, even loosely, that's a green signal. If they have no idea, that's useful data too, especially if you're planning to explain the product before anyone encounters the name in the wild.
Then ask: does it sound like something you'd trust? "Trust" is doing a lot of work in that question. What you're testing is whether the name triggers any immediate associations that work against you: something childish, something clinical, something that sounds like a scam. You'd be surprised what comes up.
One person is not a survey. But one person saying "I don't know how to spell that" is already telling you something.
You can rename later (and you might)
There's a fear buried under most naming paralysis: that the name is permanent, that you have to get it right now or live with the mistake.
You don't.
Buffer was named Bufferoo when it launched. Slack was called Linefeed. Instagram was Burbn. These aren't edge cases; they're the norm. The name you ship with is not the name your company runs on forever. It's the name you ship with. That's all it has to do.
The cost of renaming is real: redirects, re-registering handles, notifying users, updating the Stripe profile. But it's a one-week project, not a catastrophe. Most indie apps that rename do it cleanly before they have meaningful traffic. If you rename after 10,000 active users, it's bigger, but it's still survivable.
What you cannot undo is not shipping. Every week you spend in naming limbo is a week you didn't learn whether the idea has legs. The name doesn't make the product good. The product makes the name recognisable.
So if you've applied the framework above and you still have two candidates you genuinely like equally, pick the one with the easier domain situation and move on. Before you open your builder of choice, whether that's Cursor for the IDE-native route or Bolt or Lovable if you'd rather stay out of code files, spend the 30 minutes, make a call, and get to the part that actually matters: picking what to ship first so you have something to show in a weekend.
The name you pick today might not be the name on your Stripe dashboard in two years. But the app you ship this month absolutely could be.
If you're stuck on more than just the name, and the concept itself still needs pressure-testing, the right next step is validating whether the app idea has a real audience before you build. Naming a bad idea fast is still fast failure. But naming a good idea fast is the thing that lets you start finding out.
Draftlytic can't pick the name for you. But once you've picked it, it'll help you turn the idea into a structured spec your AI tool can actually follow, instead of building from a one-sentence prompt and hoping for the best.