← Back to Blog

Why I Built Seed Keyword (and What Six Months of It Taught Me)

·7 min read·Hyunjin Lee

There are at least ten serious keyword research tools already on the market. Ahrefs, Semrush, Keyword Tool, Ubersuggest, KeywordsEverywhere, Mangools, and a long tail of smaller players. So when I started building Seed Keyword, the obvious question, both from friends and from myself, was: why another one.

This post is the honest answer. It's also a half-postmortem of the first six months of running it.

The original itch

I run a few content sites as a side thing. Some are paid SEO work. Most are personal. Across all of them, the part of the workflow I dreaded most was the early keyword discovery phase, specifically for trilingual research across English, Japanese, and Korean.

The existing tools were either expensive (Ahrefs is great but the entry price is high if you only do this part-time), incomplete (most paid tools have weak Naver and YouTube autocomplete coverage), or had user experiences that felt designed for marketing teams rather than individual creators. (I wrote a fuller breakdown of that trade-off in Ahrefs vs free tools.)

What I actually wanted was something stupidly simple. Type a seed. Pick a source (Google, YouTube, Naver). Get a clean, expandable list of autocomplete suggestions in three seconds. Export as CSV. That's it. The whole thing I wanted fits in one screen:

Seed Keyword's list view: a single seed expanded into hundreds of autocomplete suggestions with one click

No dashboard, no onboarding, no "upgrade to see more." One input, three buttons, and the results right there. This screenshot is basically the entire spec I had in my head.

The closest existing thing was keywordtool.io, which I used for a few years and which is fine but limits free usage aggressively and feels like it was last visually refreshed in 2017. I wanted the simpler thing, free, modern, and with better multilingual coverage. So I built it.

What "building it" actually looked like

A lot of indie tool launches get romanticized in retrospect. The reality of the first version of Seed Keyword was:

It took me a weekend to get the autocomplete fetching to work. It took me roughly six weekends after that to make the UI not embarrassing. I underestimated the visual design effort by, conservatively, 5x.

I picked Next.js because I'd been using it for other projects. In hindsight this was the right call but for boring reasons (deployment ergonomics, file-based routing) rather than the reasons people usually cite. Honestly any modern framework would have worked.

The hard parts weren't technical. They were:

  • Deciding what to leave out. The temptation to add "just one more feature" before launch is enormous. I forced myself to launch with three sources (Google, YouTube, Naver) and zero account system. No login, no saved searches, no projects. People asked for those things almost immediately. I'm glad I didn't have them at launch.
  • Picking a domain name. I burned an embarrassing amount of time on this. Most good names are taken or expensive. I ended up with seed-keywords.com (plural, with a hyphen) because the singular without the hyphen was four-figure expensive on the secondary market.
  • Figuring out what to write on the homepage. Turns out writing good copy is harder than writing code.

What surprised me

A few things I didn't expect.

The Naver source has been more popular than I anticipated. I built it mostly for my own use, assuming most users would be English speakers researching English keywords. The Korean and Japanese traffic share is meaningfully higher than I projected. There's apparently a real underserved market for tools that take East Asian search engines seriously.

The default "what's a seed keyword?" question got asked more than I expected. I assumed anyone landing on the site already knew the term. They didn't. That insight is why the homepage has a brief explanation and why there's now a blog post specifically about what seed keywords are. (You're reading the related-posts tree of that decision right now.)

The single biggest source of qualitative feedback has been people emailing me directly. Not Twitter, not analytics, not a fancy feedback widget. People write you long emails when they care. The lesson I drew from this: make it easy to email me, and read the emails.

What I got wrong

I'll keep this honest.

I built the feature where you can click on any suggestion to "expand" it as a new seed, and I was pretty proud of that recursion. Then I watched session recordings (with consent) and realized most users didn't notice it. They used one round of suggestions and bounced. I had to make the expansion behavior much more visually obvious. Versions of this lesson keep happening to me with everything I build: my features are not as discoverable as I think they are.

I spent too much time early on optimizing for desktop. Mobile traffic was 60% of visits from day one. I should have designed for mobile first and let the desktop layout be a side effect. I'm still paying down that decision.

I waited too long to set up basic analytics and search console. There were probably two or three months where I had no idea what queries were bringing people to the site. Those months would have been more useful with data.

Where the tool is going

A short list, in no particular order:

  • Better Bing and DuckDuckGo coverage. Both have autocomplete data and almost no tools surface it. I don't think it'll be huge, but it's a small differentiator.
  • A more useful "related questions" extraction. Long-tail keyword research and FAQ generation are increasingly the same workflow. I want to make that explicit.
  • Optional saved searches without a full account system. Maybe magic-link based, maybe just localStorage. Still thinking.
  • More language-specific quirks. Japanese romaji-to-kana conversion in queries, for example, surfaces a different set of suggestions. Small things like this matter for people doing real multilingual research.

I'm explicitly not planning to add: a paid tier, an account system with passwords, "keyword difficulty" scores I can't verify, or an API. These are all things people have asked for. I think they would make the tool worse for the people who use it most.

On running a free tool as a one-person project

If you've been thinking about building a tool of your own and you're worried about whether it makes sense without a business model, here are my honest reflections.

The free tool is useful to me as marketing for the rest of what I do. It generates inbound interest from a category of people (content creators, SEO practitioners, indie founders) that overlaps with audiences I want to reach for other projects. I do not need it to generate revenue directly. This is not the right model for everyone, but it works for me.

The cost is low. Hosting plus a domain is under $30 a month. The labor cost is real but the labor is also enjoyable, which is the only reason it's sustainable.

I don't run ads on the autocomplete pages, only on the blog, and even on the blog ads only show on posts deep enough to have AdSense approve. I prefer it that way. The product is more credible without ads cluttering the core experience.

To anyone using the tool right now

A genuine thank you. I read every email. If something's broken or confusing, please tell me. The next version exists mostly because of feedback that earlier versions weren't quite right.

The plan for the rest of 2026 is to keep the tool free, keep adding small useful features, and keep writing posts like this one when I learn something worth sharing. If there's something specific you'd like me to write about, that's also a perfectly reasonable thing to email me about.