When a tool in your revenue stack is not worth maintaining
Alexandra-Emily Kokova
Published 3 November 2026 - 5 min read
A tool is worth keeping while the hours it saves exceed the hours it takes to keep honest, and a quarterly count shows which side is winning.
A tool earns its place while the hours it saves are greater than the hours spent on its owner, fixes, retraining, broken integrations and licence. Count that once a quarter with five questions, write the answer down, and if you retire a tool, export, redirect, tell people and record why.
On this page
A tool earns its place while it saves more hours than it costs to keep honest
A tool is worth keeping while the hours it saves are greater than the hours it takes to keep it honest. Honest here means the data inside it is right, the integrations feeding it still run, and the people meant to use it do. The usual intuition is that a tool should go when its upkeep takes more time than it saves. The intuition is sound. What it lacks is a number, and without a number a tool stays because nobody has the evidence to argue it out.
Upkeep rarely arrives with a price attached. The licence is on an invoice, so it gets noticed. The Tuesday afternoon someone spends re-mapping a field after a sync broke is on no invoice at all, so the week absorbs it. Over a year those afternoons can add up to more than the licence, and nobody sees the total because nobody added it. Counting once a quarter is what brings it into view.
Our guide to the SaaS GTM stack by funding stage covers which tools a company tends to run at each stage. This article covers the other direction: how to decide that one of them should go.
Upkeep has five parts, and the licence is only one of them
When we count the cost of keeping a tool, we write down five lines, in hours per month wherever hours apply.
- An owner: the person who answers when it misbehaves, even if that is thirty minutes a week.
- Fixes: the field that stopped syncing, the duplicate records it created, the report that needs rebuilding after a rename.
- Retraining: every new hire who has to be shown how it works, plus the refresher when a process changes.
- Integrations: each connection to the CRM, the forms, the billing system or another tool is a thing that can break, and each one needs someone to notice when it does.
- The licence, including the seats nobody has logged into for months.
Convert the hours to money with a rough hourly rate for the people involved. Rough is fine. The point is to put both sides of the comparison in the same unit.
The savings side needs the same treatment. Pick the task the tool replaced, estimate how long it took by hand, and multiply by how often it happens. For example, a lead-routing tool might save a sales ops person six hours a month. If it also needs two hours of admin, an hour of repair each time the CRM sync misfires, and a short session for each new rep, the margin is thinner than the six hours suggest. Those figures are invented for illustration; yours will differ, and that is the reason to measure them.
Five questions to ask about each tool once a quarter
The check below fits on one page per tool and takes about twenty minutes when the answers are already to hand. Run it in the same week each quarter so it becomes routine instead of an event.
- Who owns this tool today, by name? If the answer is "whoever notices," the upkeep is being paid by people who never agreed to it.
- How many hours did keeping it running take last quarter, and how many hours did it save? Use the five lines above.
- How often did an integration or automation around it fail, and what stopped working when it did?
- Who used it in the last sixty days? Take this from login or activity data, not from the number of seats on the invoice.
- If we switched it off tomorrow, what would we do instead, and would that cost less time?
Write the answers down, date them, and keep them where the next person can find them. A single quarter where upkeep beats savings can be a bad quarter, perhaps a migration or a staffing gap. Two in a row, or a tool that nobody can name an owner for, is a reasonable trigger to plan its retirement. Tools without owners tend to turn into furniture: still in the room, used by no one, and expensive to move.
Dropping a tool is a short project with four steps
Retiring a tool means exporting what it holds, redirecting what depends on it, telling the people who used it, and recording why. Cancelling the licence comes last, and it is the smallest part of the work.
First, export everything worth keeping: records and their history, notes, attachments, and the configuration too, such as workflows, field mappings and saved views. Check the vendor's data retention terms before cancelling, since access to an account after cancellation varies from one vendor to the next.
Second, list every integration that reads from or writes to the tool. Forms, webhooks, automations, reports and other apps all count. Repoint each one or switch it off on purpose. A connection left dangling usually fails without any error message, and the first sign is a dashboard that stops moving.
Third, tell the people who used it before the date, with what replaces it and where to ask questions. Even a tool that few people like has one person who relies on it for a report you did not know existed.
Fourth, keep a short record: the date, the hours figures from the quarterly check, who agreed, and where the export lives. A year from now someone will suggest buying the same tool again, and the record is what lets that conversation start from facts instead of memory. Then cancel the licence, and put the renewal notice date in the calendar so it does not roll over while the project is still open.
Some tools are worth keeping even when the count looks poor
The hours test has gaps, and it is better to know them. A tool used once a quarter for a board report or a compliance export may save few hours and still prevent a very bad week. A tool in the middle of a rollout will look expensive until people are trained. In both cases the better question is whether the upkeep can be cut: fewer integrations, a named owner, a smaller set of fields.
Upkeep also tends to be high where nobody owns the shape of the system, a pattern we describe in nobody owns the shape of the system. In that case the tool may not be the problem, and replacing it would move the same cost somewhere new. When the licence is the part that stings, our piece on whether HubSpot is too expensive looks at the tier question separately from the upkeep question.
Running this check is routine work for a fractional RevOps engagement, and it is part of what we cover under our services. Whoever runs it, the written answer is what you point to when the same tool comes up for renewal next year.