When to quit a tool

The half-life essay covers the long arc — years of drift before a tool becomes a burden. But sometimes the signal arrives fast. Here are the three that tell me to quit before the essay-length version has time to develop.

You're maintaining the integration more than using the tool. The ratio flips quietly. One day you're using a tool; the next, you're keeping the tool alive — updating connectors, massaging exports, patching the glue code between it and everything else. If the maintenance is the work, the tool has become the problem.

You know the workaround before you know the feature. I've used tools where, when a new teammate asks "how do I do X," my first thought is the workaround, not the native path. That's a sign I've stopped trusting the tool to solve the problem and started solving the tool instead. When the workaround is your first reflex, you've already left — you just haven't made it official.

The upgrade changelog reads like a threat. A well-fit tool improves in the directions you wanted it to go. You read the release notes and feel mild relief. When a tool has drifted from your context, the changelog is a list of someone else's priorities colliding with yours. You start pinning versions. You skip releases. That's not caution — that's estrangement.

The sunk cost is real and it isn't relevant. A month of learning doesn't obligate you to a year of bad fit. The exit is expensive once; staying is expensive forever.

STUDIO