When a new idea arrives, my brain sometimes jumps to the name before the problem. I combine a few words, check the domain, and get a small rush when the good one is still available: “I should buy this now.” The payment goes through and, for a moment, it feels as if ten percent of the product is already done. I have fallen for that little trick more than once.
Buying a domain is not bad; I still enjoy it. The risky part is treating five minutes of excitement as product progress. The next evening, when I open the laptop again, the domain is waiting for me. So are all the unanswered questions about the problem and its users.
What does a domain actually provide?
A good domain provides a name, an address, and sometimes motivation. It can make it easier to publish a landing page, create an email address, and explain an idea. There are also names worth securing early because they are short, differentiated, or strategically useful.
A domain does not automatically provide:
- A problem worth solving
- Reachable people who experience that problem
- A reason for them to leave an existing solution
- A distribution channel
- A working product
- Repeat usage or payment signals
None of those questions are answered at checkout. What we have is a new asset with an annual renewal date.
Starting with the most comfortable task
Choosing a name, sketching a logo, and selecting a stack are controllable tasks. Talking to users, learning that an idea is unnecessary, or facing a distribution problem is less comfortable. It is easy to spend time on activities that feel productive without reducing the important uncertainty.
I do not want to kill the excitement, so I use a small brake instead. Before purchasing another domain, I try to answer these questions:
- Who has this problem, and how often?
- How is it solved today?
- Where will the first user come from?
- Which assumption can I test without the domain?
- What is the smallest working output I can show in a week?
If I cannot answer them, domain scarcity is not my current risk. Problem ambiguity is.
The sunk cost grows after checkout
After buying the domain, the thought changes to “I paid for it, so I should build it.” Hosting, a logo, a social account, and a repository follow. Small costs accumulate and make the idea harder to evaluate objectively. Closing it feels like wasting the investment rather than ending a weak experiment.
The domain fee is usually the smallest cost. Attention is the expensive part. Every repository, backlog, deployment, dependency update, and security notice needs a little space in my head. Ten half-alive projects can look impressive in browser tabs. One small working product is usually worth more.
My current decision framework
I classify new ideas into four states:
- Buy: The name is strategically useful, the risk is low, and a near-term test exists.
- Build: The problem has evidence and the next step is a small working product.
- Park: The idea may be useful, but capacity or distribution is missing today.
- Kill: The problem is weak, users are unreachable, or the learning is complete.
Parking is not failure. It frees mental RAM. Killing an idea does not erase previous effort; it limits the cost of a disproved assumption.
When should the domain come first?
I may buy early when the name is genuinely rare and losing it would make the project harder to position. It also makes sense when I will publish a landing page or prototype within days. If “maybe I will build it someday” is the only reason, a bookmark is often enough.
I have not stopped buying domains. I am only trying to see checkout as tying my shoes, not crossing the finish line. The product starts afterward: show it to someone, make it work, ask for uncomfortable feedback, sometimes let the idea go, and sometimes return the next evening to improve it.