For many indie developers, though, that assumption doesn’t always hold. We’re often not domain experts, and starting purely from personal pain can be misleading if the pain isn’t shared or frequent enough.

In my experience, the challenge isn’t “starting from yourself” vs “starting from keywords”, but figuring out how to get close enough to a real problem space to develop that kind of insight in the first place.

I built a “product” starting from keywords, but then realized I didn’t actually know where the users were, or how to talk to them. There was no obvious place for real feedback.

Starting from keywords let me ship something, but it also meant I was missing the professional context around the problem — the deeper understanding you only get by being inside the system where the frustration exists.

In hindsight, I think I optimized for building something, not for being close to the problem itself.

I’ve found that discovering keywords is rarely the beginning of understanding a need. Knowing where people with that need actually are — and how they talk about the problem — seems much more important.

Even if you do find a viable keyword, SEO alone usually isn’t enough. You still have to talk to users, watch how they use (or don’t use) the solution, and iterate based on real feedback. Keywords feel more like a downstream artifact once you’re already deep in the context.