When to Fire a Tool: Sunk Cost in the Software Stack

Businesses review employees annually and never review software. My firing criteria, the sunk-cost traps vendors build on purpose, and the quarterly process I use to decide what stays in the stack.

Key takeaways

• Most businesses review every employee annually and review their software never — the stack only gets audited when something breaks or a renewal invoice stings, which means the vendor controls the timing.
• Five firing criteria do the work: the tool caps a workflow you care about, maintenance outgrew value, the category genuinely moved on, adoption never happened, or the vendor's roadmap diverged from yours — and 'something shinier launched' is deliberately not on the list.
• Price the exit honestly (export, retraining, parallel running) and compare it against the compound cost of keeping the wrong tool — then budget roughly one meaningful stack change per quarter, because switching capacity is a real resource.

The five firing criteria

The sunk-cost traps, named

The firing process

Two from my own scrap bin

When not to fire

Here's a discipline gap I see in almost every company I look inside, including my own in the early years: we review every employee at least annually — goals, performance, a decision about the future — and we review our software never. Tools get hired with more ceremony than they'll ever see again. After the onboarding project ends, the only performance review most software ever receives is a renewal invoice, and the only feedback mechanism is whether someone complains loudly enough in the week it auto-renews.

That asymmetry isn't an accident of busyness. It's sunk cost doing what sunk cost does, plus a set of traps that vendors — rationally, I'd do the same in their chair — build on purpose. I run three companies and audit client stacks for a living, which means I've fired a lot of tools, kept a few I should have fired sooner, and watched businesses pay for software the way you pay for a gym membership in March: out of guilt, momentum, and the vague sense that cancelling means admitting something.

This post is the discipline I use instead. It's the operational sibling of my layer-by-layer tech stack guide — that post covers what to build; this one covers the harder skill of what to remove. And it expands the paragraph at the bottom of my Builder Notes workshop tour that readers keep asking about: the one on when to switch.

A tool gets fired from my stack when at least one of these holds. Not vibes, not launch videos — one of these five.

1. The tool caps a workflow I care about. This is the cleanest signal and the one I weight most. Every tool has a ceiling; the question is whether the ceiling sits above or below where your workflow is heading. A CRM that can't expose an API caps every automation you'll ever want to build on customer data. A scheduling product that can't handle your second location caps the second location. When you find your team designing around a tool — exporting to spreadsheets to do what the tool should do, keeping a shadow process because the official one can't flex — the tool isn't supporting the workflow anymore. It's governing it.

2. Maintenance outgrew value. Every tool costs attention: updates, breakage, the integration that needs re-authing, the one person who knows how to fix it when it sulks. That cost is fine while the value is bigger. But value tends to be a step function — the tool does its job or it doesn't — while maintenance creeps. At some point the line crosses, and you're running a small IT project whose deliverable is keeping a mediocre product alive. I've watched teams spend more hours babysitting a reporting tool than it would take to rebuild the reports somewhere sane. Nobody decided that; it accreted.

3. The category genuinely moved. This is the criterion that requires the most discipline, because it has a counterfeit version. "The category moved" means the baseline capability of the whole product class shifted under your tool — what was best-in-class table stakes three years ago is now the floor, and your tool didn't come along. Anyone maintaining a stack through the last few years of AI has felt this: entire categories of my 2026 tools stack would have been unrecognizable in 2023. The counterfeit is "something shinier launched." A competitor shipping a beautiful demo is not category movement; it's marketing. My test: has the work changed, or just the ads? If your team's actual output would materially improve, the category moved. If you'd be trading a known tool for a newer logo and a re-onboarding project, it's shine.

4. Adoption never happened — and that is the data. The most quietly fired tools in my history are the ones nobody used. Here's the reframe that matters: when a tool gets a real rollout — training, champions, leadership actually using it — and six months later the team has still routed around it, that's not a failed rollout to be re-attempted with more enthusiasm. That's the organization telling you the tool doesn't fit how the work actually happens. You can override that signal maybe once, for a tool that's strategically load-bearing. But mostly, non-adoption is the cheapest, most honest product review you will ever receive, and the correct response is to believe it.

5. The vendor's roadmap diverged from mine. Tools are bets on companies, not just products. When your vendor pivots upmarket and every release note is about enterprise features you'll never touch; when the SMB tier stops getting attention; when the founder-led product you bought becomes a private-equity-owned renewal machine — the product you're using is fine today and abandoned tomorrow. Roadmap divergence is a leading indicator, which makes it the criterion that lets you fire a tool before it fails you, on your timeline instead of during an emergency.

Knowing the criteria is the easy half. The hard half is that four specific traps keep operators — smart ones — paying for tools the criteria already condemned.

Annual prepay guilt. You prepaid the year for the discount, so leaving in month five feels like burning seven months of money. But the seven months are spent whether you use the tool or not — that's what sunk means. The only live question is whether the team's time for the next seven months goes into a tool you've already decided is wrong. Prepay discounts are priced by people who understand this psychology better than their customers do. Take the discount when you're confident; just don't let it vote in the exit decision it was designed to influence.

Migration dread — the moat the vendor dug on purpose. Hard exports, proprietary formats, data that comes out as a PDF of itself — some switching friction is natural, and some is engineered. Vendors know the fear of migration keeps more customers than the product does, and the ones who make leaving hardest tend, not coincidentally, to be the ones most worth leaving. I saw the strongest version of this in a decade of healthcare IT, where practice-software vendors have turned data custody into a retention strategy — part of why my healthcare MSP lessons lean so hard on papering the exit before you sign the entrance. The counter is simple and almost never done: test the export before you buy, and again once a year. A tool whose data you can't leave with is a tool you don't own; it owns you.

"But we've customized it so much." This one deserves its costume ripped off: heavy customization is lock-in wearing an achievement costume. The hundreds of hours of custom fields, workflows, and integrations feel like an asset — look how deeply it's ours now! — and they are exactly the switching cost the platform's pricing team is counting on when renewal comes with a 30% increase. Real customization on top of a tool that still clears the five criteria: great, that's compounding. Customization as the main reason a failing tool survives review: that's not an investment, it's a hostage situation you built yourself.

The champion who left. Tools get adopted by people, and people leave. The ops manager who loved that platform, configured it, evangelized it — gone eighteen months ago, and the tool has been coasting on her enthusiasm ever since, half-maintained, understood by no one. Orphaned tools deserve a fresh hearing on the merits, because "we use this" often turns out to mean "someone used to."

Criteria plus traps still isn't a system. Here's the process, and it's deliberately boring.

Score it in the quarterly review. Once a quarter, every paid tool in the stack gets a line: what workflow it serves, who owns it, what it costs (subscription and attention), and a pass/fail against the five criteria. This takes an afternoon for a typical SMB stack and it converts firing decisions from emotional events into routine ones. The point isn't to churn tools — most quarters, most tools pass in thirty seconds. The point is that the review exists, so no tool gets tenure by default and no renewal date ambushes you.

Price the exit honestly. When something fails review, resist both failure modes: rage-quitting into a migration you didn't scope, and sighing and renewing. Instead, price the exit like a small project, because it is one: data export and cleanup, retraining the team on the replacement, and — the line everyone forgets — a parallel-running period where you pay for both while the new tool proves itself on real work. That number is usually bigger than optimists hope and smaller than the dread suggested.

Then compare it against the compound cost of staying. This is the step that changes decisions. The exit cost is paid once. The cost of keeping the wrong tool is paid monthly, forever: the fee, plus the workflow drag, plus every future automation designed around the tool's limitations, plus the widening gap as the category moves without you. A painful $15,000 migration against a tool quietly costing you a few thousand a month in fee-plus-friction isn't a hard call — it just looks like one, because the exit cost arrives as a number on a quote and the staying cost never gets invoiced. Sunk cost looks backward at money you can't recover; this comparison looks forward at money you're still choosing to spend. Only the second one is a decision.

Budget one meaningful change per quarter. Switching capacity is a real, finite resource — your team can absorb about one significant tool transition per quarter before change fatigue sets in and every migration after that gets the resentful, half-hearted adoption that makes the new tool fail criterion four. So the quarterly review produces a ranked list, not a purge. Worst offender goes first; the rest wait their turn. Some tools sit on my own "fire eventually" list for a year, and that's the system working, not failing.

Same policy as the Builder Notes scrap bin: categories, not vendor names — my sample size is my companies, not a lab, and the patterns transfer better than the logos anyway.

The project-management platform we'd customized into a monument. Years of use, deeply configured, and it failed criterion one the day our delivery workflow changed shape and the tool couldn't follow. What kept it alive an extra year was pure trap three: the customization felt like equity. When I finally priced the exit, the migration cost less than two quarters of the friction we'd been tolerating — and the replacement, kept deliberately vanilla this time, got adopted faster precisely because there was less cleverness to learn. The monument was the problem.

The reporting tool the category ran past. Genuinely good when we adopted it; three years later, the capability that justified its price was table stakes in tools we already paid for elsewhere in the stack. No single dramatic failure — it just became a second subscription for a first capability. That's criterion three in its quietest form: nothing broke except the reason to keep paying. It got thirty minutes in a quarterly review and a calm exit at renewal. That's what a good firing looks like: undramatic, scheduled, and about a year later than it should have been, which I note because even with a system, the bias survives — the system just caps how much it costs you.

A firing framework in the wrong hands becomes churn, so the counterweight matters as much as the criteria. My stack philosophy is boring core, sharp edges: the load-bearing layer — identity, email, files, backups, phones, accounting — should be mature, dull, and very hard to fire, because at the core, stability is the feature. A marginal upgrade in capability never justifies a migration on a layer where the failure mode is losing customers instead of losing an afternoon. The five criteria still apply down there, but the bar for "caps a workflow" or "category moved" should be dramatically higher, and "everyone else is switching" should count for nothing at all. Where the framework earns its keep is the edges — the AI layer, the automation tools, the fast-moving categories at the top of the stack — where categories actually do move yearly and loyalty to last year's pick is just sunk cost with a friendly face.

The uncomfortable summary: your stack is full of employees who never get reviewed, and a few of them stopped showing up years ago. Schedule the review. Score honestly. Price the exit against the compound cost of staying. And fire slowly enough that the team can absorb it — one meaningful change a quarter, worst offender first.

I write these from the operator's seat — I've paid for every trap on this page at least once across three companies, which is cheaper than a certification and stings more. This is a spoke of my operator's guide to the SMB tech stack; more on the blog, or get in touch.