How I Evaluate a New Dev Tool (My 3‑Question Filter)

New tools are innocent until proven guilty

I treat new dev tools like strangers who want root access to my brain.

They might be brilliant. They might also quietly tax me 30 minutes a day in friction and context switching, which is murder for deep work as a creative dev and coach with a limited calendar.

So I use a simple 3‑question filter. No fancy scoring system. No 30‑page Notion database. Just three blunt questions I run on every tool before it touches my real workflow.

If a tool passes, it gets trial access to my actual stack. If it fails, I uninstall it and move on. No nostalgia. No “maybe one day”.

I used this exact filter on three tools that are now core for me: Cursor (my main editor), Tower (Git client), and SecondsPro (the weird one: an interval timer that ended up being a serious dev productivity tool).

The 3 questions every tool has to answer

These are the three questions I use:

1. What recurring pain does this remove, in my actual week?
2. What am I willing to uninstall or stop doing for this?
3. Can I get to “unconscious usage” inside 7 days?

If a tool cannot give me a clear win on all three, it does not belong in my stack. It might be good. It might be clever. I still do not let it live rent‑free in my brain.

Question 1: What recurring pain does this remove, in my actual week?

I start here because this is where most devs lie to themselves.

We install tools for imagined futures. "This will be great when I finally build that SaaS" or "One day I will run Kubernetes on a cluster and this dashboard will be handy".

I only care about this week. Not someday. Not maybe.

So I literally write down a quick list in a scratch note:

• What annoyed me three times last week?
• Where did I copy paste the same thing repeatedly?
• What made me feel stupid or slow?

If the tool does not touch anything on that list, it is probably just entertainment.

How Cursor passed Question 1

When I looked at Cursor, it was obviously hyped. "AI code editor" everywhere. That alone is usually a red flag for me.

So I mapped my actual pain for the week:

• Jumping between ChatGPT in the browser and VS Code to iterate UI ideas.
• Manually rewriting boring boilerplate in React and Next.js projects.
• Context switching to write quick documentation or commit messages.

Cursor looked like it could hit all three.

The first night I tried it, I took a small real project: a custom UI component for a coaching dashboard I am building in Next.js. I forced myself to do the whole iteration loop inside Cursor. Code, refactor, tweak copy, document.

Pain check:

• Did I alt‑tab less?
• Did I write less boilerplate myself?
• Did I feel less mental friction when jumping between “code” and “explain the code” modes?

The answer was yes across the board.

I was spending less time moving my eyes and more time making decisions. That is a real pain removed. Not a future fantasy improvement. Current week, concrete.

How Tower passed Question 1

Tower is not new, but my adoption of it was.

I have nothing against the CLI. I still use it. But I noticed a recurring pain: digging through complex Git histories during feature work or debugging client projects.

My pain list for version control:

• Reconstructing what happened across several branches and force pushes.
• Explaining Git history to non‑Git‑nerd collaborators.
• Fixing ugly interactive rebases I half remembered.

Tower did one thing immediately: it turned Git history into a UI I could visually parse in seconds. No more crafting complex log commands to answer simple questions like “what happened here last Tuesday?”.

Again, actual week. I was in the middle of iterating on a baseball training analytics tool, juggling branches for sensor integration and UI experiments. Tower removed friction daily.

How SecondsPro passed Question 1

SecondsPro is technically a fitness interval timer on my phone. I do not use it for fitness.

My real pain: I wanted consistent, short, intense focus blocks that did not require me to babysit a timer window. Standard Pomodoro apps always felt clunky, and I hate extra windows on my Mac.

My list:

• Starting a focus block without touching the mouse.
• Noticing breaks without having timers all over my screens.
• Keeping sessions consistent across coding, writing, and research.

SecondsPro already runs my training intervals. I realised I did not need a “productivity” app. I just needed a different profile in the same timer.

So I created a simple routine:

• 35 minutes focus
• 7 minutes break
• Repeat for 3 cycles

Phone is out of sight. Sound is just loud enough to be heard while coding. No new software on my Mac. No new visual noise.

Concrete pain reduced: I stopped fussing with timers and started respecting my own sessions more consistently.

Question 2: What am I willing to uninstall or stop doing for this?

The second question is brutal on purpose.

If everything is additive, your stack bloats. Every new tool becomes one more thing you have to keep updated, remember, and mentally route tasks through.

So I force a trade:

• What app will I uninstall?
• What manual process will I abandon?
• Where will this tool be the single place I do X?

If I cannot name the thing I will kill, I do not keep the tool.

Cursor: replacing VS Code and my AI tab circus

For Cursor, the trade was big: replace VS Code for 80% of my coding and stop using separate AI chat tabs for code work.

I did not keep both and “see which one I like more over time”. That is a recipe for endless indecision.

The rule I set for myself was clear: for one month, every time I wanted to write front‑end or full‑stack code, I opened Cursor by default. If I needed something exotic I could jump to VS Code, but that was the exception, not the norm.

I also killed my habit of “ask ChatGPT in the browser, then paste back in”. Cursor’s inline and composer workflows took over that role.

That trade created a strong filter. If Cursor could not fully carry normal day‑to‑day work, I would feel it quickly.

Tower: replacing Git blame gymnastics

With Tower, my trade was this: no more customizing Git log commands and random GUIs. One Git UI, properly learned.

I removed other half‑baked UIs I had tried. I archived my personal list of fancy git log alias spells. I committed to learning Tower’s workflows for rebasing, cherry‑picking, and conflict resolution instead of Googling a slightly different Stack Overflow snippet every time.

That forced me to see: is Tower really faster, or is it just more visual noise on top of Git?

Within a week, it was obvious. I stopped fighting with history. I spent more time reasoning about changes and less time constructing commands.

SecondsPro: killing the desktop timer stack

SecondsPro had to replace something too. That meant uninstalling or ignoring a string of timer and habit apps on my Mac.

I deleted menu bar timers and disabled browser extensions that did similar things. No more “one timer for writing, another for coding, one more for workouts”.

One app. Different profiles. That was the deal.

You feel real resistance when you delete those tools. That is exactly the point. If the new thing cannot absorb that job, it should not exist in your system.

Question 3: Can I get to “unconscious usage” inside 7 days?

This is the question that saves me from clever tools that never quite become natural.

By “unconscious usage” I mean this: I am in flow, I reach for the tool, I use it, and I do not have to think about how. It is muscle memory.

If I still feel like I am piloting a new cockpit after a week of use, it is not for me. My brain has better things to do than remember yet another keybinding system or mental model.

Cursor: muscle memory inside the editor

I gave Cursor one week as my main editor for real work. Not toy projects. Live stuff.

During that week, I tracked one thing: how often do I feel lost or slowed down by the tool?

Day one and two were awkward. I was still mapping “ask AI for refactor” and “edit in place with AI” to shortcuts. I wrote those shortcuts on a sticky note on my desk like it was 2009.

By day four I stopped looking at the note. By day seven I caught myself doing something important: I was thinking in Cursor’s workflows. For example:

• Highlight a nasty function, hit the shortcut, type “extract this into a reusable hook with proper error handling”, check the diff, done.
• Use the chat with context from the current file to explain a bug I could not track mentally.

I was not “using an AI tool”. I was just coding. The AI part faded into the background. That is the threshold I look for.

Tower: visual Git that disappears

Tower started out as “the new visual toy”. The first two days I kept reaching for the CLI out of habit.

So I flipped the rule: if I was about to type a non‑trivial Git command, I forced myself to open Tower first and see if I could do it faster there.

By the end of the week, a pattern settled:

• Simple stuff like git status, git add, git commit stayed in the terminal.
• Anything involving history, branches, or stashes started in Tower automatically.

I did not debate it in my head. My fingers and eyes just went there. That is what I want.

If after a week I was still thinking “should I use Tower here?” then it would have failed. Tools that constantly ask for your attention are a tax.

SecondsPro: invisible but reliable

SecondsPro had a different hurdle. It is on my phone, but the work happens on my Mac.

So my 7‑day test for unconscious usage was simple: do I automatically start it before I begin a focused coding session, without reminding myself?

I put the app on my home screen in the bottom right, in thumb range. I created a “Dev Focus” routine and named it exactly that. No cute names. Just honest.

By day three I was unlocking my phone and starting the routine before I opened Cursor. Not because I was disciplined. Because it felt wrong to start without that audio boundary.

That is when you know a tool has clicked. It becomes part of the ritual. It is not another thing to remember.

My actual adoption sequence for new tools

So how does this look in practice for a random tool that crosses my timeline?

Here is the short sequence I use.

1. Quick plausibility check (5 minutes)

I ask: what on my “last week pain” list does this touch? If the answer is “nothing specific” then I close the tab.

If it hits something concrete, I install it. No long pondering.

2. One real task, start to finish

I take a real task I was going to do anyway. I do it entirely inside the new tool where possible.

No “playing around”. That is how tools trick you. Everybody looks fun on a toy problem.

3. Decide the trade

If the tool passes the first experience, I write a single sentence: “This tool replaces X.”

Then I actually remove or disable X.

4. 7‑day muscle memory test

For a week, I force usage in the situations it is supposed to help with. I do not measure hours used. I look for whether it becomes automatic.

If it has not gone at least semi‑automatic by day seven, I uninstall it.

Why I run a harsh filter

I like tools. I build things for a living. I coach. I experiment with my own biology. I understand the itch to try new software weekly.

But I also watch what bloated stacks do to smart people. They become operators of their tools instead of builders of their projects.

Cursor, Tower, and SecondsPro did not win because they were shiny or clever. They won because they survived this boring, practical filter:

• They removed pain I actually had.
• They replaced something else, instead of adding clutter.
• They became invisible enough that I just used them without thinking.

That is all I want from a dev tool.

If you are honest with yourself and run your own 3 questions, you will probably install fewer tools. The ones that survive will carry more weight though. Which is the whole point.