Too many tools on a small team: the cost is not the subscription

Someone asks in standup whether the login bug is being worked on. Two people say yes. One is reading the tracker, where it is assigned and in progress. The other is reading the shared to-do list, where it is unassigned under This week. Both are right about the tool in front of them. One bug, two answers.

That is what the last app you added actually cost, and it never appeared on a card statement.

We sell an app, so read this accordingly

We make an issue tracker. An essay arguing that small teams should be slower to add tools is a strange thing for us to publish, so the honest version has to include us: everything below applies to Kevta, and the end of this post is the case for not adding it.

The argument, plainly. A tool's price is the least interesting thing about it. The cost that compounds is the number of places a fact about your work can live.

Two tools do not split the work, they duplicate the question

Adding a second place that holds "who is working on this" does not halve anything. Both places accept an answer, nothing reconciles them, and the divergence is silent — two records drifting apart until someone reads the wrong one out loud.

This is not a flaw in any particular product. It is the direction every one of them sensibly grows. Slack lists ship with four task-tracking fields by default — Completion, Name, Assignee and Due Date (slack.com). In Notion, "tasks have properties for the assignee, due date and status" (notion.com), and a GitHub project is "an adaptable table, board, and roadmap" over your issues and pull requests (docs.github.com). Each is a good feature built for a real reason. Put three of them in one eight-person company and all three will cheerfully tell you who owns the login bug.

Sprawl is not really about spend. It is about ambiguity of authority.

What too many tools costs a small team

The same task exists twice. Filed in the tracker on Monday, written again on Tuesday in the to-do app where someone plans their week. One gets closed. The other becomes a small permanent lie.

The roadmap disagrees with the board. The doc was written in a planning week and was accurate for nine days. The board is what people actually do. Nobody updates the doc, because updating it is not how work gets done — and then someone quotes it to a customer.

Notifications arrive in four places, so people mute the ones that matter. Four inboxes get triaged by volume rather than importance, and the loudest tool gets muted first — often the tracker. Muting is not laziness; it is the only available response.

Onboarding means explaining which tool is true. A new hire gets six invitations and one conversation that starts "so the board is where we really track things, but the spec is in the doc, and the decisions are usually in the channel". If you cannot say that sentence cleanly, the team has no answer — only a habit the existing people have memorised.

Nobody cancels anything. One person set up a trial that never ended. It renews because cancelling requires being sure nobody depends on it, and nobody is sure.

Only the last of those is about money, and it is the cheapest one.

Consolidation is not free either

The version of this essay that ends with "so consolidate" is not worth reading. Consolidation has real costs, and they are paid in capability.

The all-in-one that replaces five tools is normally worse at each of the five. Best-of-breed exists for a reason: focused tools are better because the people building them only had one problem to solve. A tracker is worse at documents than a documents tool, and a documents tool is worse at tracking. One thing that does both means the weaker version of both, permanently.

Cutting a tool your team likes to satisfy a tidiness instinct is also a bad trade. "How many tools do we pay for" is a metric that improves easily and means very little. And the end state of one tool for everything is that somebody administers a platform — spaces, templates, permissions, custom fields — the job you were trying to avoid, relocated.

So the goal is not fewer tools.

The test: one authoritative place per fact

Write down the facts your team relies on: what is being worked on now, what is next, why we decided what we decided, what the customer asked for, what state the deploy is in.

For each one, name the place that is authoritative — the one that wins when two of them disagree. Not the best place, not the nicest interface. The one that wins.

Then look for collisions. Where two tools claim the same fact, one has to lose, and losing has to mean something concrete: nobody assigns work there any more, the status field comes off, the view gets deleted, or the tool keeps doing what it is best at and stops holding that fact.

Most teams can keep nearly every tool they have. What has to go is the second claim, not the subscription — and that removes more confusion than cancelling subscriptions does.

It also gives you a question to ask before adding anything: which fact will this own, and what holds it today? If the answer is "it will also track what we are working on, alongside the tracker", the tool is not adding capability. It is adding a second answer. Same failure as a chat channel becoming the record — when Slack becomes your project tracker is that argument in detail.

Where we sit in that list

Kevta holds one fact: the state of the work. Issues with stable keys, one owner, one status, full history, and board, list, table and calendar views over the same items. It has no wiki, no messaging and no time tracking. That is a choice, not a gap we are hurrying to close.

The uncomfortable consequence is that Kevta is another tool in the list. It is worth adding only if it takes over the tracker role from something else — the spreadsheet, the chat channel, the project database in your docs tool — rather than sitting beside it. Add it and keep filing work in two places and you have made the problem above slightly worse. We price flat per workspace rather than per seat, for reasons set out in the quiet cost of per-seat pricing — but a pricing model is no reason to add a tool either.

Kevta is in beta. If you run the exercise above and find the tracker slot is genuinely unowned, there is a waitlist.