Most developer tools are built by developers. That's both a strength and a weakness.
Developers know what other developers need. But they also tend to build tools that only they understand — with cryptic error messages, hidden features, and UI that requires a tutorial.
After building three Chrome extensions (TabCost, PR Focus, and ChainTrace), I've learned a few principles that separate "tools developers use" from "tools developers install and forget."
Here are 5 principles I follow now.
1. The "one clear thing" rule
Every tool should have one clear job. If a user can't explain what your tool does in one sentence, your tool is too complex.
What I used to do: Add features because they were cool, not because they solved a problem.
What I do now: Start with one core feature. Add others only when users ask for them.
Example from PR Focus: The core feature is "sort GitHub PRs by priority." Everything else (AI summaries, risk scoring, draft reviews) is layered on top. If the sorting didn't work, nothing else would matter.
2. Error messages that teach
Bad error message: "Error: failed to authenticate."
Good error message: "Your API key is invalid. Generate a new one at [link] and paste it in Settings."
The rule: Every error message should tell the user what happened, why it happened, and what to do next.
Example from PR Focus:
text
❌ "Invalid API key"
✅ "Your Groq API key is missing the 'read' permission. Please regenerate it with 'read' scope. [Learn how →]"
3. Preserve user state
Developers are context-switchers. They open your tool, then get interrupted. When they come back, everything should be exactly where they left it.
What I do:
Save settings in chrome.storage.sync.
Save progress (checklist state) in chrome.storage.local.
No "start over" unless the user explicitly asks.
Example from PR Review Canvas: The interactive checklist saves progress in localStorage. Users can close the tab, come back days later, and continue where they left off.
4. Expose the "why"
Developers are curious. If your tool does something unexpected, they'll want to know why.
What I do:
Add tooltips to non-obvious features.
Include a "why" for every checklist item (PR Review Canvas).
Show logs or reasoning where possible.
Example from PR Focus: When the AI risk score is low, the tool shows the reasoning: "CI passing, PR age 2 days, changes to readme only → low risk."
5. Dark mode (done right)
Every developer tool needs dark mode. But it needs to work — not just be "dark gray instead of light gray."
What I do:
Use system theme detection as default.
Provide a toggle that actually works.
Test on both light and dark.
Example: PR Focus supports dark/light/system themes. The toggle is always visible, and the theme persists across sessions.
The checklist I use for new features
Before shipping any new feature, I ask:
Does this solve a real problem?
Can I explain it in one sentence?
Does it work without a tutorial?
Are the error messages helpful?
Is the state preserved across sessions?
Does it have dark mode?
If the answer to any is "no," I don't ship it.
Final thought
Developers are the hardest audience to please. They see through marketing fluff. They notice when something is broken. They'll uninstall your tool the moment it wastes their time.
But if you build something that saves them time — without getting in their way — they'll tell everyone they know.
