Choosing a Tool
Six questions worth five minutes before you install anything new.
Adding tools is not productivity by itself. Each one costs installation, configuration, learning, and maintenance, and the more you have, the more you have to explain to your team. Run through these six questions before adopting anything and you’ll avoid most of the regret.
Six questions
| Question | Passing answer |
|---|---|
| How often do I do this? | At least three times a day, or 30+ minutes even once a week |
| Can my current tools do it? | If an unused feature of something you already run covers it, start there |
| What’s the learning cost? | If you get a first win within 30 minutes, it passes |
| Is anyone else forced into it? | A tool only you use is far easier to adopt than a team standard |
| Can I get back out? | Can the data be exported as text, Markdown, or JSON? |
| Is the project alive? | A release in the last six months, and issues that get replies |
Suggested order of adoption
- Personal tools first. Terminal, search, editor — things that start and end with you. Cheap to reverse, and you feel the benefit daily.
- Team tools next. CI, linters, hooks — anything that affects other people. Prove it as a personal tool before proposing it.
- Platform tools last. Orchestration and IaC carry the highest cost to undo.
Common traps
- Configuration perfectionism. Instead of spending two hours on a prompt theme, run the defaults for a week and fix only what actually annoyed you.
- Leaving duplicates around. Two tools doing the same job means you will never remember which config you edited. Once a new one sticks, delete the old one.
- Undocumented aliases. A pile of aliases only you know leaves you helpless on anyone else’s machine. Scripts you share should use the real commands.
Where to find candidates
The six questions above assume you already have something to evaluate. When you don’t, the usual sources, roughly in order of how much you should trust them:
| Source | Good for | Watch out for |
|---|---|---|
| A colleague who already uses it daily | The honest version, including the annoyances | Sample size of one |
| The tool’s own GitHub issues | What breaks in real use, and whether anyone answers | Survivorship — happy users don’t file issues |
Awesome-* lists and topic: search on GitHub | Breadth in a narrow niche | Unmaintained entries linger for years |
| Directories like Startup Stash | A fast map of an unfamiliar category — CRM, analytics, compliance | Listings are paid. Ranking is placement, not judgement |
| Product Hunt and HN “Show” posts | Discovering something new exists | Launch-day enthusiasm, no long-term signal |
Startup Stash is worth naming because it covers the SaaS categories a developer-focused site like this one doesn’t — sales tooling, GDPR compliance, e-commerce platforms, video conferencing. It’s organised by category, so “what are the five things people use for X” takes a minute rather than an afternoon.
But read it as a candidate list, not a recommendation. Vendors pay to be listed and to be featured, so position on the page reflects a marketing budget rather than how the thing performs on the six questions above. That’s true of essentially every directory in this space; it’s only a problem if you forget it. Use the directory to build the shortlist, then do the evaluation yourself.
The same caution applies in reverse to this site. Toolian is one person’s read on a few hundred tools — no money changes hands, but it is still a set of opinions, not a survey. Anything you’re about to depend on deserves half an hour of your own.
Next
With a bar in place, move on to Package Managers and build an environment where the install commands in the rest of this site just work.
Last updated 19 Aug 2026, 00:00 UTC.