There's a specific kind of dopamine hit you get when an HN post lands right. The title is crisp, the score is solid, and the top comments are the useful kind — "finally someone built this," followed by twenty engineers explaining the exact same frustration you thought was just yours. This week mine was a Show HN: a code search tool for AI agents that claimed to use 98% fewer tokens than pointing a model at grep. I read the thread for twenty minutes, closed the tab, and thought: I know what I'm building this weekend. Open-source TypeScript MCP server. Token-efficient code search for agents. Better than just dumping your whole repo into context and hoping the model figures it out. I had a name, a repo, and a BUILD.md within an hour.
Then I actually looked at the space.
I'd been tracking YC's Requests for Startups, which kept circling back to "Software for Agents" as a funding theme. Code intelligence for agents — tools that help models navigate codebases cheaply instead of reading every file — felt like the right intersection: a problem the market had confirmed, technical enough to be interesting, small enough to ship in a weekend. I was looking for a real portfolio project. Not another CRUD app. Something that reads as actual engineering work and might convince someone that hiring me or paying me to build something was a reasonable idea.
The reasoning was fine. The conclusion needed work.
The Hour I Should Have Spent First
I gave myself an hour to search the space before writing any code.
The list of existing tools grew embarrassingly fast. Semble — the exact project that sparked the idea — was already out there and open-source. There was codegraph, there was CocoIndex, there were several others with similar names and similar goals. All of them free. All of them building the same indexing layer: parse files, build a search structure, return compact snippets to the agent so it doesn't have to read fifty files to find one function.
I wasn't looking at an open market. I was looking at a crowded market and had been about to enter it by building a free clone of the most popular thing in it.
That's a specific kind of bad plan.
The problem with chasing a hot HN thread is that HN signal is, by definition, public. If it's on the front page, it's not a hidden need — it's a known need that a lot of engineers read about at the same time and started solving. "The problem is real" is confirmed by the thread. "The market is open" is a different claim entirely, and the thread doesn't prove it.
One Step to the Side
Here's what I noticed when I kept looking past the obvious lane: every one of those tools was solving the same phase of the same problem.
Understanding code cheaply. An agent needs to find where a function is defined — give it a searchable index so it doesn't have to read the whole codebase. Return ranked snippets. Use 98% fewer tokens than grep. It's a real problem and those tools solve it.
But there's a different phase that nobody seemed to have touched in a framework-aware way.
Changing code safely. Not "find where auth is used" — but "if I rename this function, what else breaks? If I change this database column, which routes and queries and components are now pointing at a thing that no longer exists?" That's a different question. It requires not just an index of where symbols live, but a graph of how they flow. Which route handlers call which services. Which queries touch which columns. The dependency graph, not the definition index.
I couldn't find anything that did the framework-specific version. Parse a Drizzle ORM schema, map which code paths read or write each column, traverse the graph to break sites. The demo: change a database column name, get back a list of the seven places that'll fail at runtime before you run the migration. That felt like the open gap.
The reframe was small in words — understand cheaply versus change safely — but the competitive landscape looked completely different on each side. One side: a dozen free tools with real momentum. The other side: mostly nothing.
The new project became an MCP server that builds a reference graph over your codebase and answers one question: if I change this, what breaks? I kept the name gist-mcp. The meaning shifted: gist now refers to the condensed, graph-derived understanding of what's connected — what actually matters about a codebase, stripped of the noise — rather than compact search snippets.
The Honest Part
I don't have it working yet. I have a BUILD.md with the architecture locked in, and a two-day build schedule. The tree-sitter proof-of-concept is this weekend. So the lesson I'm writing about isn't "here's how to build a code intelligence tool." It's "here's the hour of research that changed what I was going to build."
And I genuinely don't know if the pivot is correct. Maybe nobody has built the framework-aware impact analysis layer because it's fundamentally harder than it looks, or because the market for it is smaller than I think. Maybe I'll build it and find the real gap is somewhere else again. That's fine — I'd rather discover that after one weekend than after three months.
The other thing worth conceding: the competitive audit required some luck in what I was looking for. I happened to notice that all the existing tools stopped at the same phase, which made the adjacent gap visible. Someone else might have run the same search and concluded "it's saturated, skip it." The strategic reframe wasn't obvious — it needed a couple of hours of sitting with the search results before it clicked.
Both Things Can Be True
HN is still one of the better places to find real problems. Not hypothetical things people might theoretically want, but actual friction that developers are actively trying to work around, documented in comment threads where people describe exactly what's annoying them. That's good signal, and it's worth using.
The trap is reading "the problem is real" as "the market is open." A problem that makes the front page with a few hundred points is confirmed real and being actively worked on by everyone who read that post. Those are different claims. Only the first one is guaranteed.
The useful move: use HN to confirm the problem is real. Then look at where the current solutions stop. The crowded part of the market shows you where smart people have already built — which means just past it is often where they haven't.
What the Hour Bought
The cheapest work on this project was the hour I spent before touching the keyboard.
I found ten tools I hadn't known existed. I found one gap worth taking seriously. I changed the entire design of the project — tools, architecture, positioning — and ended up with something I think is more interesting and less competed than what I'd started with.
Most project ideas don't fail in execution.
They fail because they're solutions to a problem that's already been solved.
Check first. The hour costs nothing.