We Left a Tool We Still Liked, Because Liking It Was Not the Question

Most writing about switching tools assumes the current one is bad. In my experience that situation is rare and it is easy — when something is actively failing, the decision makes itself. The hard case, and the common one, is a tool that works, that nobody complains about, and that is nonetheless the wrong thing to keep paying for. We left one this spring and it took me four months to be willing to.

The tool was a client proofing and approval product. It did its job. In three years it had never lost anything, never gone down at a bad moment, and had a support team that answered in hours. I liked it. What changed was that our newer design tool had grown its own commenting and approval flow, and we were now asking clients to comment in two places, which meant approvals were split across two records and twice a year somebody approved something in the wrong one.

The reason I stalled for four months is worth naming because I think it is universal. Leaving something that works requires you to accept a certain, immediate cost — migration effort, most of it unscheduled, retraining clients, a period of things being worse — in exchange for an uncertain, diffuse benefit. Staying requires you to accept nothing today. Any decision shaped like that gets deferred by default, and the deferral does not feel like a decision, which is precisely the problem.

What broke the stall was reframing the question. Instead of “is this tool good,” which is answerable and irrelevant, I asked “if we did not have this, would we buy it today at this price, given everything else we now own.” That version was answerable too, and the answer was clearly no, and it took about ten seconds once phrased that way; it is the same test the quarterly stack audit applies to every line. The three years of good service were not evidence about the future; they were the reason I had stopped asking.

The second thing that helped was pricing the duplication rather than the tool. The subscription was $32 a month, which is easy to justify. The duplication cost was two client approval mix-ups a year, each of which took me roughly half a day to untangle and one of which involved a genuinely awkward conversation. Priced at my rate, that is more than the subscription, and it is the number that had never appeared in any of my reviews because it did not arrive as an invoice.

We gave clients six weeks of notice, ran both in parallel for two projects, and turned the old one off. Two clients said they preferred the old flow. Both were still working normally within a project. That is the actual scale of the disruption I had spent four months avoiding, and I want to record it honestly because my anticipation of it was wildly out of proportion.

The general rule I have taken from this: a tool that overlaps another tool by more than about half is a decision you have already made and not yet executed. The overlap does not resolve on its own — products grow toward each other, not apart — and every month you carry both, you pay twice and you fragment one record into two.

The corollary, which I try to apply now at purchase rather than at renewal: before adopting anything, ask what it overlaps with — alongside the pre-trial pricing audit — and whether that overlap is likely to grow. If it is, you are not buying a tool. You are scheduling a migration for some point in the next two years and choosing to pay for two things until then.