The Tools I Stopped Using (And Why)

Every tool you add to your stack is a commitment. Not a one-time cost, but a recurring one: updates, configuration drift, mental overhead, another login, another tab, another monthly charge. Over the past year of building solo, I've added dozens of tools. But the more interesting list is the tools I removed.

Removing a tool is a stronger signal than adopting one. Adoption can be driven by marketing, curiosity, or a slow Tuesday. Removal means you used it enough to understand why it doesn't fit. These are the tools that didn't survive contact with real workflows, and what replaced them.

Notion: The Everything App That Does Nothing Fast

I used Notion for about eight months. Project tracking, client notes, knowledge base, meeting agendas, internal wikis. It handled all of these adequately. None of them well.

The problem with Notion is latency. Not network latency, though that's real too. Conceptual latency. The distance between having a thought and capturing it. You open Notion, wait for it to load, navigate to the right workspace, find the right database, create a new entry, fill in the properties, then write. By the time you're typing, the sharp version of the thought is gone. You're writing a softer, less precise version because the tool made you wait.

Notion's flexibility is its weakness. Because it can be anything, it demands that you decide what it should be. Every new project starts with a meta-question: how do I structure this in Notion? That question is work. It feels productive because you're clicking around and making things look organized, but it produces zero output.

I replaced Notion with two things: plain Markdown files in a directory structure, and Postgres for anything that needs to be queried. Markdown loads instantly in any editor. It's searchable with grep. It version-controls with git. It doesn't require an internet connection. And Postgres handles the structured data that Notion's databases were pretending to manage, except with actual query performance and real relational integrity.

The migration took an afternoon. I exported everything, ran a script to convert the relevant pages to Markdown, and dumped the database entries into Postgres tables. Three months later I haven't opened Notion once. The things I used it for either didn't need a tool at all or needed a better one.

Zapier: Paying for Plumbing

Zapier is the duct tape of the SaaS world. It connects things to other things, and for a while that felt indispensable. New form submission triggers a Slack message triggers a CRM entry triggers a follow-up email. Elegant, in theory.

Two problems. First, cost. Zapier's pricing scales with usage, which means it gets expensive exactly when your business grows. I was paying ~$50/month for automations that ran maybe 200 times. That's $0.25 per trigger for something that amounts to moving data from one API to another. Not complex transformations. Not AI processing. Moving JSON from point A to point B.

Second, debugging. When a Zap fails, you get an error message that's somewhere between cryptic and useless. You're debugging a workflow you built six months ago through a visual interface that shows you one step at a time. There's no version control. There's no way to test a change without running it live. There's no grep.

I replaced Zapier with two things: n8n for the workflows that genuinely need a visual builder (complex multi-branch automations with error handling), and shell scripts for everything else. Most of my "automations" turned out to be five-line bash scripts triggered by cron. A curl call, a jq transformation, another curl call. Total cost: $0. Total debugging time when something breaks: about thirty seconds, because I can read the script.

n8n is self-hosted, so the marginal cost of adding a new workflow is zero. And because it runs on my own hardware, there's no data leaving my environment for simple routing tasks. The entire Zapier bill vanished and the automations got more reliable.

VS Code: The Editor I Outgrew

This one will be controversial. VS Code is a good editor. It's probably the best general-purpose code editor available. I used it for years and recommended it to everyone.

I stopped using it because my workflow moved to the terminal and never came back.

The shift happened gradually. I started using AI coding tools that operate in the terminal. My file editing became less about navigating a visual tree and more about describing changes. My debugging moved from clicking through UI panels to reading logs in a shell. My git workflow was already terminal-based. At some point I realized I was opening VS Code, ignoring the sidebar, ignoring the extensions, ignoring the file explorer, and using the integrated terminal. I was paying the memory cost of a full Electron application to get a terminal with extra steps.

I switched to Neovim with a minimal configuration. Not because Neovim is objectively better, but because it matches how I actually work. When I need to edit a file, I open it directly. When I need to search across a project, I use grep. When I need to run something, I'm already in the shell. The context-switching cost of moving between editor and terminal dropped to zero because they're the same thing.

VS Code's RAM usage sat around 400-800MB depending on the project and extensions. Neovim uses ~30MB. On a machine running local models, containers, and databases, that headroom matters.

The honest caveat: if your workflow is GUI-centric, VS Code is still the right choice. If you rely on visual debugging, integrated git GUIs, or specific extensions that have no terminal equivalent, switching would make you slower. This isn't a universal prescription. It's a report on what happened when one specific workflow outgrew one specific tool.

The Pattern Behind the Cuts

Looking at these three together, the pattern is clear. Each tool I dropped shared the same characteristics:

• Generalization over speed: They tried to serve every use case and ended up being mediocre at the specific ones I cared about.
• Abstraction over transparency: They hid the underlying operations behind visual interfaces, which felt helpful until something broke and I needed to understand what was actually happening.
• Subscription over ownership: They charged monthly for functionality that, once I understood it, could run on my own hardware for free.
• Vendor dependency over portability: My data and workflows lived inside their systems. Moving away meant an export process, and exports are never complete.

The tools that survived and thrived in my stack are the ones that do the opposite. They do one thing well. They're transparent about what they're doing. They run locally. My data stays mine.

What Stayed

Not everything got replaced. Some tools earned their place permanently:

• Postgres: The database that handles everything from client data to knowledge retrieval to workflow state. Fourteen years of battle-tested reliability.
• OrbStack: Replaced Docker Desktop and immediately justified itself with lower RAM usage and faster container starts.
• Ollama: Local model inference at zero marginal cost. Runs enrichment pipelines, classification tasks, and draft generation without sending data anywhere.
• Cloudflare Tunnel: Free, no port forwarding, handles the networking problem that used to require a static IP and a prayer.

The surviving tools share a trait: they solve a hard problem that I genuinely cannot solve better with a shell script. Postgres is better at relational queries than anything I could write. OrbStack is better at container management than raw Docker commands. Ollama is better at model serving than manually loading weights. These tools add capability I don't have, rather than adding convenience for capability I already possess.

The Cost of Carrying Tools

Solo builders talk a lot about the tools they use. The stack posts, the setup guides, the "tools I can't live without" lists. Less discussed is the cost of carrying tools you don't need.

Every tool in your stack is a surface area for failure. An API changes, a pricing tier shifts, an update breaks a workflow, a service goes down. When you're solo, every outage is your outage. Every broken integration is your Saturday afternoon. The fewer tools you depend on, the fewer Saturdays you lose.

There's also a cognitive cost. Each tool has its own mental model, its own terminology, its own way of organizing information. Switching between Notion's blocks and Postgres's tables and Zapier's steps and VS Code's panels means context-switching between four different conceptual frameworks. Consolidating down means fewer frameworks, less switching, more time in flow.

The instinct when hitting a limitation is to add a tool. The better instinct is to ask whether an existing tool, or no tool at all, already handles it. A forty-line Python script that runs on cron will outlast most SaaS products. It won't pivot, won't get acquired, won't change its pricing, and won't email you about its new AI features.

Subtract before you add. The leanest stack is the one that's hardest to break.