Every week there’s a new tool that’s supposed to change how I work. A new AI coding assistant. A new note-taking app. A new self-hosted thing someone posted on r/selfhosted that looks incredible and only takes “five minutes to set up” (it never takes five minutes). A new MCP server. A new CLI. A new way to manage the other new things.
I try a lot of them. Probably too many. And if you’re reading this, you probably do too.
The problem isn’t that these tools are bad. Most of them are genuinely good. The problem is that trying them all is a full-time job, and you already have one of those. At some point, tinkering stops being exploration and starts being procrastination with extra steps.
I still tinker. I don’t think you should stop. But I’ve developed a system (loose, imperfect, frequently violated) for keeping the tinkering from eating the actual work. This is that system.
The Tinkerer’s Dilemma#
Here’s the tension: the people who are best at adopting new tools are also the people most likely to spend all their time adopting new tools. If you’re the kind of person who sees a new release on Hacker News and immediately wants to spin it up, you know exactly what I’m talking about.
You tell yourself you’re “evaluating.” You’re “staying current.” You’re “investing in your workflow.” And sometimes that’s true. But sometimes you’re just avoiding the thing you were supposed to be doing by setting up a prettier environment to do it in.
I’ve lost entire weekends to this. Migrated note-taking apps three times in a year. Set up monitoring dashboards for services that didn’t need monitoring. Built automation for tasks I do once a month.
The tinkering itself isn’t the problem. The problem is when you can’t tell the difference between tinkering that makes you faster and tinkering that just feels productive.
My Framework (Such As It Is)#
I don’t have a rigid system. Rigid systems are what tinkerers build instead of doing their work. What I have is a set of questions I ask myself before I go down a rabbit hole.
1. What am I replacing, and why?#
If I can’t name the specific tool this replaces and the specific thing that tool does poorly, I’m not evaluating. I’m shopping. There’s a difference.
“Cursor is slow on large files” is a reason to look at alternatives. “I saw someone on Twitter using something that looked cool” is not.
2. Does this solve a problem I have right now?#
Not a problem I might have. Not a problem I had six months ago. Right now. If the answer is “well, not exactly, but it could be useful for…” then I bookmark it and move on.
[YOUR EXAMPLE: A specific tool you bookmarked and came back to later when you actually needed it]
3. What’s the switching cost?#
Every tool has a tax. Migration time, learning curve, broken integrations, muscle memory that needs retraining. The new thing has to be meaningfully better to justify that tax, not just different.
I think people underestimate this. You get good at your current tools in ways you don’t even notice until you switch and suddenly everything takes 20% longer for a month.
4. Can I test it without committing?#
This is why I love self-hosting and containerized stuff. Spin it up, poke at it for an hour, tear it down. No account creation, no data migration, no “free trial” that auto-converts. If I can’t evaluate a tool in an afternoon without restructuring my life, it better be solving a serious problem.
5. Am I the target user?#
A lot of tools are built for teams, or for beginners, or for a workflow that isn’t mine. Something can be excellent and still not be for me. I’ve wasted time trying to make things work that were never designed for how I operate.
The Stack (April 2026)#
This is a snapshot. Some of this will change. That’s the point. The tools rotate, but the categories don’t.
[YOUR CONTENT: Fill in your actual current stack. Below is a suggested structure.]
Thinking and Notes#
[YOUR TOOLS: e.g., Obsidian, how you use it, what you’ve tried before]
Reading and Research#
[YOUR TOOLS: e.g., Readwise Reader, RSS setup, how you filter signal from noise]
Coding#
[YOUR TOOLS: e.g., Claude Code, Cursor, VS Code, terminal setup, what you use when]
AI (the Layer on Top of Everything)#
[YOUR TOOLS: e.g., Claude, ChatGPT, local models, when you use which]
Infrastructure and Homelab#
[YOUR TOOLS: e.g., Synology, Docker, what you self-host and why]
Task Management and Shipping#
[YOUR TOOLS: e.g., Linear, GitHub Issues, whatever you use to track what actually needs to get done]
What Stays, What Goes#
The tools that survive in my stack share a few things:
They don’t fight me. If I’m constantly working around a tool’s opinions about how I should work, it’s gone. Good tools bend to your workflow. Bad tools make you bend to theirs.
They compose. The best tools in my stack talk to each other without requiring me to build elaborate bridges. A tool that’s incredible in isolation but can’t touch anything else is a liability.
They’re boring when they need to be. I don’t need my task manager to be exciting. I need it to show me what to do next. Excitement is for the work, not the tool.
I actually use them. This sounds obvious but it’s the one that catches me most. I’ll set something up, use it for three days, and then forget it exists. If I haven’t touched it in two weeks and it’s not infrastructure, it’s not part of my stack. It’s a hobby project I’m lying to myself about.
The Tinkering Budget#
Here’s the thing I’ve landed on that actually works: I give myself explicit tinkering time. Not “I’ll try this real quick” (that’s always a lie). Dedicated time where the goal is exploration, not output.
For me that’s usually a weekend morning or a Friday afternoon. During that time, I can spin up whatever I want, try whatever I want, break whatever I want. But when that time is over, I go back to the stack that works.
This does two things. It satisfies the itch (which is real and valid, tinkering is how you find better tools). And it puts a fence around it so it doesn’t bleed into Tuesday afternoon when you’re supposed to be writing a blog post but instead you’re configuring a new terminal emulator.
The Uncomfortable Truth#
Most of your productivity gains won’t come from better tools. They’ll come from using the tools you have more deliberately. The person who knows Vim deeply will outpace the person who switches editors every quarter, every time.
I know this. I still try new things constantly. The difference is that I’ve stopped pretending every new thing I try is an investment. Sometimes it’s just fun. And that’s fine, as long as you’re honest about it.
The tools don’t matter as much as you think they do. Your system for choosing them matters more. And the work you do with them matters most.
