How to choose a domain for a side project (in an hour)

Set the time limit before you start

One hour, and write down what 'good enough' means before you begin — otherwise the standard rises to meet however long you are willing to spend, which is the mechanism that eats the weekends.

A reasonable definition of good enough for a side project: you can say it out loud, somebody can type it after hearing it, it is not a near-copy of something that exists, and you would not be embarrassed to put it in a post. That is the bar. It is not the bar for a company, and it does not need to be.

The reason a lower bar is correct here is not laziness. It is that you do not yet know whether this project will exist in three months, and the cost of renaming an unlaunched thing with no users is close to zero.

Match the effort to what this actually is

The naming decisions worth making carefully scale with what is at stake, and side projects sit at the bottom of that scale by definition.

Most side projects are the first two rows and most people name them as if they were the fourth. The one thing you should not skip in any row is avoiding a name that is confusingly close to an existing product — that is cheap to check and expensive to discover later.

Descriptive is fine, and often better here

This is where the usual advice inverts. For a company, a descriptive name is a constraint you carry for years. For a side project, it is a feature: it explains itself in a post title, in a link somebody shares, and in the sentence you use when a friend asks what you have been doing.

A small utility whose name says what it does needs no brand-building at all, and brand-building is precisely the work you do not have spare capacity for. If the project is one clear thing, name it that clear thing and go and build it.

The exception is if you can already see the project becoming a product. Then a distinctive name saves a transition, and it is worth the extra hour — the trade-off is laid out in short versus descriptive names.

A modifier is completely acceptable

If the clean version is taken, take get-, try-, use- or a product word in front. For a side project this costs almost nothing real: your visitors will arrive from a link in a post, a forum, a message or a search result, and none of those involve anybody typing your address from memory.

What the modifier costs is direct traffic, and a project with no audience has none to lose. Revisit it if the audience appears — that is what the re-evaluation point below is for.

Keep it technically boring

Two rules, both about not creating work for yourself later: no punctuation, and no letter substitutions. A hyphen or a clever misspelling means explaining the address in every post, correcting it in every conversation, and eventually setting up the version people actually type.

You want to spend your limited energy on the project. Every character somebody has to think about is a small tax collected on your behalf by nobody.

Do not pay a premium yet

An aftermarket domain for something unvalidated is money spent on a benefit nobody is using — nobody is typing your address from memory, because nobody knows it exists.

Generate a good available alternative and compare honestly. In almost every case the available name is four percent worse and several hundred times cheaper, and that difference is better spent on anything that tests whether the idea works. How much to spend on a domain name has the framework if you are tempted.

The twenty minutes of research you should not skip

Cutting corners is the point of this guide, and these are not corners. Side projects sometimes get attention very quickly, and an audience arriving before the research is done is exactly the wrong order.

1. 1Search the exact name and read the first page. You are looking for an existing product, not for an exhaustive picture.
2. 2Search the name plus your category, which is where a similar small project will show up.
3. 3Check the relevant app store or package registry if the project lives in one.
4. 4Confirm you have not landed one letter from something well known.

That is twenty minutes and it catches the failures that are genuinely painful. The full clearance process — documented here — is the right thing to do later, when there is something to protect.

Set a re-evaluation point, then stop thinking about it

This is the part that makes a fast decision safe rather than merely fast. Write down a specific milestone at which you will reconsider the name, and put it somewhere you will see it.

Good milestones are concrete: the first paying customer, a thousand users, incorporating, the first month you would be upset to lose. Bad milestones are 'when it feels serious', which never arrives.

Knowing the decision is scheduled is what lets you stop optimising it now. And if the milestone arrives, renaming is genuinely more work by then — but you will be doing it for a project that earned it, which is the good version of this problem.

Then go and ship it

Once a candidate is clear, usable and roughly researched, register it and close the tab. Auto-renew on, privacy on, and back to the thing you were building.

Nobody has ever discovered a side project because of its domain. Plenty have never been discovered because the naming took longer than the enthusiasm did.