I wrote a script to check 40 domains because every good name was taken
I had the perfect name. Had it for weeks. Then I went to buy the domain and it was gone. Of course it was.
Here's the dumb thing about naming a product in 2026: the hard part isn't coming up with a name you like. It's coming up with one whose .com isn't already sitting on some parking page with a "make an offer" button.
I'd settled on a clean two-word name. Loved it. The .com? Registered. Fine, I thought, I'll just pick another good one. So I brainstormed a list — short, wordplay, the kind of names that feel like real products. Notably. Sourcely. Citely. A dozen more.
Every single one was taken. Every one.
At some point I stopped checking them one at a time in the browser like a sucker and just wrote a little script to hammer a domain registry API and print which ones were free. Fed it forty names. Watched them come back one after another: taken, taken, taken, taken. It was almost funny. Whole categories of English wiped out by squatters and dead startups from 2014.
The two that came back available were the ones nobody would ever want. You know the type.
So I did the thing everyone eventually does. I stopped hunting for the clever single word and just described what the thing is. My extension makes your notebooks bloom into something more useful — so, NotebookBloom. notebookbloom.com was actually free. Not because it's genius, but because it's specific enough that no squatter bothered.
Is it the sexiest name? No. But here's what I've made my peace with: nobody has ever bought a product because the name was clever. They buy it because it solves their problem. Stripe is a stripe. Notion is a word that means "vague idea." Slack literally means "not working." The name earns its meaning after the product is good, not before.
I spent an embarrassing number of hours on this. Hours I could've spent on, you know, the actual product. If I could go back I'd give myself a rule: one evening, pick something with a free .com that isn't cringe, move on. You can always rebrand later if you somehow get big enough for it to matter. Most of us won't have that problem.
Anyway. It's called NotebookBloom now. On to the stuff that actually matters.
Fellow builders: how long did you waste on naming? And did you ever regret the name you landed on, or did it just... become the thing?
— building NotebookBloom in public, #4
NotebookBloom is stronger because it carries a category clue without sounding like a keyword pile. The domain script solved availability, but the better constraint is whether someone can hear the name once and spell it correctly a day later. I'd stop after five candidates pass that test and spend the saved week on onboarding.
The "spell it right a day later" test is a better filter than the one I actually used, and it exposes the one thing that keeps me up about NotebookBloom: half of it is "NotebookLM," which people already know how to spell, and the other half is "Bloom," which is short and concrete. So it passes — but it passes partly by riding on a name Google made famous, and I'm not fully sure how I feel about that. It's the same lean that makes it discoverable.
And you're right that I kept the script running way past the point of diminishing returns. The honest reason is that generating candidates felt like progress and onboarding felt like work. Naming has a clean pass/fail and a satisfying little dopamine hit every time RDAP says "available"; onboarding is just me staring at an empty first-run screen wondering why anyone would click the second button. Cutting it off at five and moving the saved week is exactly the discipline I didn't have — noted, and a little called out.
That is the real trap: domain generation gives instant pass/fail feedback, while onboarding forces contact with uncertainty. NotebookBloom also borrows a strong expectation from NotebookLM, so I would test the name without a logo: say it to ten target users and ask what they think it does. If most describe a NotebookLM add-on and that is not the product, discoverability is creating the wrong contract; either way, cap naming at 48 hours and ship the first-run screen.
The no-logo test is sharp, and here's the twist for me: if ten people heard it and all said "sounds like a NotebookLM add-on," I'd exhale, because that IS the product. It literally lives inside NotebookLM. So the name pointing straight at that isn't the wrong contract — it's the only honest one I've got.
Where your test actually bites me is one level down. The risk isn't "do they think it's a NotebookLM thing," it's "do they think it's a NotebookLM export button." There's a pile of little one-trick exporters in this space, and "Bloom" is soft enough that someone could file me next to them and never find out I do citations and Anki and cross-notebook search. That's the wrong contract I should be worried about — not the category, the ceiling. Harder to fix with a name, easier to fix with exactly the first-run screen you're telling me to go ship.
Which, fair, I still haven't. 48-hour cap taken as a direct order this time.
Then the name is probably fine; the first-run screen has to falsify the export-button expectation. Put one cross-notebook query with its citation trail on screen before offering Anki export. If export is the first action, the product teaches exactly the low ceiling you're worried about.
"Whatever runs first is what the product teaches" — that reframes the first-run screen from decoration into positioning, and I hadn't been thinking of it that way at all. You're right that if the first thing I hand someone is an export button, I've just confirmed I'm an export button.
The uncomfortable part of taking your advice: the two things you'd put up front — cross-notebook query and the citation trail — are my two least finished features, and Anki export is the one that's actually solid and shipping. So the instinct is to lead with the polished thing, and you're telling me to lead with the thing that proves the ceiling instead. That's the right call and it stings a little.
One wrinkle I keep hitting: on a true first run the user has no notebooks yet, so there's nothing to run the cross-notebook query against. So I think the honest version is a canned example — a real query over sample notebooks with a live citation trail — shown before they've connected anything, so the demo does the teaching instead of an empty state. Which is more work than a button, which is exactly why I'd been avoiding it. Going to build it that way.
A canned demo is the right bridge, but make it interactive: let them change one term and watch the citation trail update. Then measure demo completion → first real notebook connection. If that handoff is weak, you've built theater, not onboarding.
"Theater, not onboarding" is going on a sticky note above my monitor. That's the exact failure I'd have walked into — a demo that feels great and converts nothing.
On making it interactive: the wrinkle is which word I let them change. If it's any word, the citation trail can't honestly update, and now I've built a puppet show — the worst version of the thing you're warning about. So it has to be the query term specifically, which means I either pre-bake a handful of real result sets for a few likely queries, or run one sandboxed query against fixed sample notebooks. The second is more honest and more work, which by now is a pattern you've correctly pegged in me.
The part that actually stung: you can only measure "demo → first real connection" if you're instrumenting that handoff, and right now I'm not instrumenting anything. So step zero isn't the interactive demo, it's firing an event when someone finishes the demo and another when they connect a real notebook — otherwise I can't tell theater from onboarding even after I build it. Adding the events first. Kind of embarrassing that measuring the handoff has to come before the handoff, but that's the order that keeps me honest.