The Tools I Tried and Abandoned (And Why I Don't Regret Them)
Every 'tools I use' post is marketing. Here's the graveyard — the tools that seemed right and weren't, and what they actually taught me.
The tools I use post writes itself. The tools I abandoned is the more honest one.
Twelve years, six products, a lot of tools that made perfect sense when I adopted them and perfect sense when I stopped.
Jira (and Every Jira-Adjacent Thing)
I used Jira for two years. I built the board. I wrote the tickets. I defined the epics. I attended standups with myself.
The problem isn't Jira — it's that Jira is built for teams with enough people that coordination is a real problem. When you're one person, coordination isn't the bottleneck. Thinking is. A tool that adds process on top of that doesn't help; it adds a second job.
I moved to a plain text file. Literally a .md file called TODO.md in the repo root. I've shipped more reliably since.
GraphQL
I built a GraphQL API for Dealery. It was clean. It was well-typed. It was complete overkill.
GraphQL is excellent when you have multiple clients with different data needs — mobile, web, third parties — and you want one API layer to serve all of them efficiently. For a project where I control every client and all the data shapes are known in advance, it's a lot of infrastructure for a problem that doesn't exist. I rewrote the relevant parts in REST. The codebase got smaller and easier to reason about.
I don't regret trying it. I learned how it works well enough to know when to actually use it. That's worth something.
Full Observability Stacks
There was a period where I stood up Datadog on Game Night staging. I set up dashboards. I wrote monitors. I configured alerts for metrics nobody had ever looked at.
The problem: I'm not an SRE team. I'm one person. The cognitive load of maintaining an observability stack — keeping the agent running, updating configurations, triaging noisy alerts — was more expensive than the value I was getting from it.
What I actually needed: crash reporting and a few key metrics. I've been running Sentry for crash reporting and a simple analytics setup for a long time. That's it. The signal-to-noise ratio is dramatically better.
Docker for Everything
Docker is a genuinely useful tool. I use it in specific places. There was a phase where I containerized things that had no reason to be containerized — local dev environments for projects that ran fine with a standard Node version, CI jobs that were adding build time without adding reliability, things that didn't have deployment complexity to justify the overhead.
The forcing question turned out to be simple: does this thing need to run consistently across multiple machines or environments with different configurations? If yes, Docker makes sense. If no, it's probably friction.
The Various "Perfect" CI Setups
I've built CI pipelines from scratch more times than I can count. Full test suites, lint checks, type checks, end-to-end runs, deployment gates. Elaborate YAML files that took days to get right.
Most of them drifted. A test would start failing intermittently. A lint rule would conflict with a new library. The end-to-end tests would require a service that wasn't available in CI. And because fixing the CI was never the most important thing, it would sit broken for weeks while I worked around it manually.
What actually works for a solo shop: the simplest CI that catches the most important failures. Type check, build, deploy. Add more only when you have a specific failure mode you're trying to prevent.
What the Graveyard Actually Taught Me
The pattern isn't that these tools are bad — they're not. The pattern is that they were built for problems I don't have at my scale.
Good tools for teams have a coordination overhead that solo shops don't need. Good tools for large systems have an operational overhead that small systems don't need. The mistake is adopting a tool because it's the right choice for someone doing what you're doing at 10x the scale, rather than asking what's right for the scale you're actually at.
The best tool I've found for most things is the one with the smallest surface area that still solves the problem. I keep having to relearn that.