Developer tools

What developer tools are worth building?

Engineers adopt tools that fit a command they already run, a file they already keep or a page they already open. A tool that asks for a new workspace or a new login loses to the search engine and the official docs. The best ideas answer a question an engineer would otherwise look up again and again.

Look for tasks where the answer exists but is buried. A cron expression has an exact meaning that is hard to read at a glance. A deploy that breaks after a configuration change hides one variable that differs between two builds. Both are diagnostic problems with a clear before and after, which makes them easy to demonstrate in a single screen.

Who uses developer tools, and how do you reach them?

Individual developers adopt quickly and talk about tools in the places they already read: developer forums, newsletters and the issue trackers of projects they depend on. Small teams buy when a tool fits the repository host and chat tool they already use, and when one person can roll it out without asking for budget. Open source maintainers form a third group; a tool that works without an account suits them.

Reach engineers with something they can run in under a minute, and link to the source so they can read what the tool does. Engineers check claims against code. Post the tool where the problem is already being discussed. A thread where someone asks how to read a cron expression is a better place for a working answer than a launch announcement.

Watch rather than ask. Give four engineers the task and let them solve it with whatever they normally use, while you time them. If the existing route takes under a minute, a new tool has to be far better than that to be worth installing.

What makes a developer tool idea good?

• A task with a checkable answer. The engineer can confirm the output against the code, the log or the schedule in seconds.
• Local first. The input stays on the engineer’s machine, or the tool states exactly what leaves it.
• No secrets in the output. A config diff that prints values will paste credentials into a chat or a ticket. Show names and counts, and keep values hidden.
• It fits the command the engineer already runs. A small command-line tool, a browser page or a single script the engineer can read in a minute.
• It gets used more than once a month. A tool used once a year is a reference page, not a product.

The env-variable idea on the board, Which env var changed between the deploy that worked and the one that didn’t, meets the first and third points well. The third is the hard part, which is why it returns in the pitfalls section.

What would a first developer tool look like?

Hypothetical example: a cron explainer that runs in the browser. It takes a five-field expression, returns a plain sentence and the next five run times in the reader’s time zone, and does nothing else.

Input: one cron expression, five fields, typed or pasted.
Output: one plain-English sentence, the next five run times, and a warning when a field can never match.
Not in v1: accounts, saved schedules, team sharing, the reverse direction.
Test: ten engineers use it during a week of code reviews. Count how often they copy the sentence into a pull request, and whether any of them ask for the reverse direction.

Nothing in the first version sends data anywhere, so the test is about the explanation rather than about infrastructure. The reverse direction, turning English into a cron expression, is a deliberate second step.

What are the pitfalls for developer tools?

• Secrets in input or output. Config files, deploy logs and tokens are where credentials hide. Never log the input, and redact anything shaped like a key before it is displayed or shared.
• Uploading private code. A tool that sends a repository to a hosted model or a server has to say so, and the code’s owner decides. Local processing is the simpler promise to make.
• API limits and terms. Tools that call a git host, a CI system or a package registry work inside that service’s rate limits and terms. Read them before you build a scheduled job on top.
• Dialects. Cron, semantic version ranges and date formats each come in dialects. A tool that does not name its dialect will be wrong in ways that cost someone an hour.
• Licences. A tool built on a library inherits that library’s licence. Check it before you publish code or a binary.

These are engineering and licensing checks, not legal advice. Security questions deserve a proper review before any tool touches production credentials.

Which task to start with?

Start with a task you repeat at least once a week. Three ideas on the board start from one: Explain this cron expression in plain English, and the reverse, A changelog your users actually read, and the env-variable idea above.

To add one of your own, name the input, the output and where the data stays, then send it through the submission form. For the first build, how to scope an MVP helps you cut the tool down to one command, and how to build an app with Claude Code covers a terminal-first build from start to finish.