The real cost of a tool
The subscription is the smallest part.
Every tool adds a login to provision and revoke, a place a fact can live, a notification stream, an integration that will break, and a version of the truth someone has to reconcile against the others. That last one dominates, and it is never on the invoice.
The rule this article follows
Count handoffs, not licences. A tool that removes a handoff pays for itself. A tool that adds one costs far more than its price, because someone now maintains two records of the same thing forever.
This is why "we only pay for five tools" is a misleading way to describe a stack. What matters is how many times a day a person copies information from one place to another, which is what a time audit surfaces.
Evaluating one properly
Name what it replaces, before anything else
If the honest answer is nothing, you are adding a surface rather than solving a problem. Sometimes that is right, and it should be a deliberate decision.
Write the sentence down: "this replaces the spreadsheet Priya maintains and the three reminders in my calendar". If you cannot write it, do not buy yet.
The first questionCheck what happens at the boundaries
What has to leave this tool and go somewhere else, and who moves it. That crossing point is where the real cost lives.
A tool with excellent features and no route out of it creates a silo, and the person who becomes its human integration layer is doing invisible work forever.
Boundaries beat featuresAsk who will own it
One named person, responsible for configuration, access, and deciding whether it is still earning its place.
Tools without owners drift. Nobody removes stale users, nobody notices when the integration breaks, and nobody can answer whether it is still needed.
Name them before buyingFind out how you get your data out
Before you put anything in. A tool with no meaningful export is one you cannot leave, which means every future negotiation happens with no leverage.
Test the export during the trial rather than trusting the documentation.
Test it, do not read about itPrice it per person at your size in two years
Per-seat pricing that is trivial at five people is a meaningful line at twenty five. Check what happens at the tier boundaries.
Also check what is gated behind the enterprise tier. Features that move out of reach as you grow are a common and expensive surprise.
Model it at 5x your size
Running a trial that tells you something
Most trials evaluate the wrong thing, because they happen in a clean sandbox with sample data.
Use real work with real consequences. Move one genuine workflow into it for two to four weeks and let people depend on the output. A trial nobody relies on tests the interface, not the fit.
Include the person who will use it most, not the person who found it. Enthusiasm from an evaluator is not evidence. The daily user's opinion after three weeks is.
Deliberately try the awkward case. The customer with two addresses, the deal that goes backwards, the person who works part time. Tools are pleasant in the happy path and reveal themselves in the exceptions.
Write down what success would look like before you start. Otherwise the trial concludes with a general impression, and general impressions favour whatever is newest.
When and how to cut one
Two signals mean it is time. Nobody has opened it in a month, or it duplicates something you already have and people are inconsistently using both. The second is worse than the first, because it creates disagreement about which record is true.
Cutting is mostly a nerve problem rather than a technical one.
Announce a date. Two to four weeks out, publicly.
Export the data and put it somewhere findable. Most of the resistance to cutting a tool is fear of losing history, and a clean export removes it.
Revoke access on the date. Leaving it running "just in case" means it never dies and you keep paying for a system with no owner.
Do not wait for consensus. The person who championed a tool will always want more time. Cut it and see whether anything actually breaks, which is the same logic as cancelling a recurring meeting for two weeks to see who asks for it back.
The quarterly review
Twenty minutes, once a quarter, with the list of everything you pay for.
| Question | Action if the answer is bad |
|---|---|
| Who owns it? | No owner means assign one or cut it |
| When was it last opened, by how many people? | Under half the team means investigate |
| What would break if it stopped tomorrow? | Nothing means cut it |
| Does anything else store the same information? | Pick one and retire the other |
| Has the price changed? | Renegotiate or re-evaluate |
| Who still has access who should not? | Revoke, especially for people who have left |
The last row is the one most often skipped and the one with the most risk attached. Departed employees retaining access to systems is common in small companies precisely because nobody owns the tool list.
The broader principle is that a stack should shrink as often as it grows. Most teams have a mechanism for adding tools, which is that someone finds one and buys it, and no mechanism at all for removing them. Where the review keeps concluding that the same customer or task lives in three systems, that is not a discipline problem, it is a structural one. Siela exists to reduce that specific cost by keeping CRM, meetings, tasks, and team work on one shared context layer, so the boundaries where information usually gets copied by hand are not there to cross.
Frequently asked questions
- How many tools should a small team have?
- Fewer than you think, and the count matters less than the number of places the same fact is stored. Three tools that share data cost less than two that do not.
- What is the biggest hidden cost of adding a tool?
- Reconciliation. Every additional place a customer, task, or decision can live is another place someone has to check, update, and eventually correct. The subscription is usually the smallest line in the total cost.
- How long should a tool trial run?
- Two to four weeks with real work, not a sandbox. A trial where nobody depends on the output tells you about the interface and nothing about whether it fits how you actually operate.
- How do you kill a tool nobody uses?
- Announce a date, export the data, revoke access. Waiting for consensus keeps it alive indefinitely, because the person who championed it will always want more time.
- Should you buy best-of-breed tools or one platform?
- It depends on how much your work crosses between them. If a meeting outcome needs to become a task and a customer record, separate tools mean a human carries it across every time. If the areas are genuinely independent, best-of-breed is fine.