Why We Named Our Developer Tools After What Developers Say When Things Break

Most tools are named after what the creator thinks they are. The best ones are named after what the user is already searching for.

When we built five CLI diagnostics for Node.js developers, we didn't name them after the underlying technology, the engineering approach, or what sounded clean on an npm package page. We named them after the exact phrases developers type when something goes wrong.

That was deliberate. Here's why. And why the principle applies well beyond developer tooling.

The problem with most tool names

Most software is named from the inside out. What the builder thinks it is. What sounds clever. What's available as a package name. What the team called it in Slack.

The user's perspective ("what do I search when I need this?") rarely comes first. Sometimes it comes last. Often it doesn't come at all.

The result: tools that are genuinely useful and nearly impossible to discover organically. The developer who needs them is searching for the problem. The tool is named after the solution. Those two things don't always match, and when they don't, the search space between them is empty.

What we actually built

The npm Simple Name Series is five zero-config CLI diagnostics for Node.js developers. TypeScript 5, Node 18+, one command each, published under @workingmodel/ on npm, MIT licensed. Each tool does one specific thing.

The names:

• @workingmodel/why-is-this-slow: CPU profiling and event loop lag
• @workingmodel/who-ate-my-ram: memory leak patterns and heap analysis
• @workingmodel/why-wont-this-install: npm install diagnosis
• @workingmodel/why-is-this-failing-in-prod: local vs. production environment gaps
• @workingmodel/what-is-this-package-actually-doing: dependency sandboxing and tracing

Read those names again. Every one of them is a sentence a developer has said out loud, usually in frustration, usually right before they open a browser tab and type it into a search bar. We made the tool name and the search query the same string.

The naming strategy

npm search why is a real search path. The series is designed to show up there.

This is keyword research applied to product naming. But the question isn't "what keywords should we target?" It's: "what does the user say to themselves in the moment they need this?" Those are different questions with different answers, and the second one gets you to a name the first one doesn't.

The standard naming process asks: what is this? The naming-for-discovery process asks: what does someone type when they're looking for this without knowing it exists? The gap between those two questions is where discoverability lives. Most products are stuck on the wrong side of it.

Why this extends beyond developer tools

The same logic holds anywhere names meet search:

• Blog post titles. Write the headline the reader would type, not the one the author would write. "How we rebuilt our content strategy" is an author's frame. "Why our content stopped ranking" is a reader's frame. One of them matches a search query.
• Service page copy. Describe the service the way clients describe their problem, not the way the agency describes their process. "Strategic brand architecture" is internal language. "We can't explain what we do clearly" is the client's language. Know which one they're typing.
• Feature names. Name features after the outcome, not the mechanism. "Smart scheduling" is a mechanism. "Book without back-and-forth" is an outcome. One of those is what someone searches for.
• FAQ content. Write questions in the exact language customers use in support tickets and sales calls. Not the polished internal version. The difference between "What are your payment terms?" and "Can I pay monthly?" is the difference between a page that ranks and one that doesn't.

Discoverability is a design choice. It gets made, or not made, at the naming stage. Most teams make it too late, or not at all.

What this approach doesn't solve

Names that match search queries get discovery. They don't build brand recall the same way a distinctive name does.

@workingmodel/why-is-this-slow will surface when a developer searches that phrase. It won't stick in memory the way a name like "Datadog" or "Sentry" does. Those names are arbitrary relative to the function. That arbitrariness is what makes them memorable. You can't accidentally learn that Datadog is a monitoring tool. You can accidentally find why-is-this-slow at the exact moment you need it.

Know which one you're optimising for. For five diagnostic tools in an empty search space, discovery was the priority. For a product you want people to remember and return to, you might weight the trade-off differently. The choice should be made explicitly, not by default.