Why You Pay for Software Tools You Barely Ever Use
Concept — — by Mahmoud Zalt
Per-seat creep, tier engineering, and the ownership vacuum: the five reasons your software bill grew, and what to do about each one.
Nobody sets out to build a bloated stack. Every single subscription was a reasonable decision on the day it was made, usually solving a real irritation for a real person. Then people changed roles, projects finished, vendors added tiers, and the charges kept arriving as if nothing had happened.
This piece is the diagnosis rather than the cure. If you understand the five forces that grew your bill, you stop treating each subscription as a moral failing and start treating the pattern as a system to fix. That shift matters, because teams that feel guilty about their stack avoid looking at it, and avoidance is exactly what the pricing models are built to reward.
The reason an AI Employee on **Sistava** comes up in this conversation is not that AI is magic. It is that most of the barely-used tools are doing chores, and chores are what a worker absorbs. The tools you genuinely use every day, the ones holding your books and your customers, are not the problem and are not going anywhere.
At a Glance
- 5
- Forces that inflate a software bill
- 2.4x
- Typical ratio of paid seats to daily active users
- 1 in 3
- Tools bought for a single feature
- 0
- Companies under fifteen people that need a spend platform
Why does per-seat pricing cost more than it should?
Because it bills your headcount while your usage stays flat. A tool that three people genuinely need gets bought for the whole team, since adding everyone is easier than explaining who is excluded. Then the team grows, seats are added automatically at onboarding, and the number of people actually opening the app never changes.
The compounding is what hurts. Ten tools at fifteen dollars a seat is 150 dollars per new hire per month, whether or not that hire ever logs into eight of them. Hire four people in a year and you have added 7,200 dollars of annual spend without anyone making a purchasing decision.
Why do you own whole platforms for one feature?
Because vendors bundle, and you had one urgent problem. You needed to send a scheduled report, so you bought an analytics suite. You needed one signature, so you bought a document platform. The feature you wanted was five percent of what you paid for, and the other ninety-five percent has been quietly renewing ever since.
These are the easiest wins in any stack and the hardest to notice, because the tool works. Nothing is broken. You simply have not asked, in two years, whether the one thing you use it for could be done another way now. Usually it can, and usually the other way is a task rather than a platform.
The check is straightforward. Open the tool, write down every feature you have used in the last ninety days, and compare that list against the plan you are on. If the list is one item long, you are not buying software, you are renting a habit.
How do annual plans and tier design inflate the bill?
The annual discount asks you to commit before you know whether the tool works, and it is offered exactly when your enthusiasm peaks, at the end of a good trial. Tier design does the other half: the single feature you need is placed one level above the tier that matches your actual usage, so you pay for a bundle to get one line item.
Neither of these is dishonest. They are rational pricing choices that happen to work against a small team with no procurement function. The defence is equally simple: stay monthly for the first two renewals of anything new, and read the tier table before you accept an upgrade prompt rather than after.
What does the ownership vacuum actually look like?
It looks like a card nobody checks and a spreadsheet nobody updates. When no single person owns the software budget, every charge is somebody else's responsibility, and cancelling anything requires a conversation nobody wants to start. That is the vacuum, and it is worth more to vendors than any pricing trick.
Marcus runs a twelve-person B2B software company in Toronto. When he finally sat down with the statements he found thirty-one active subscriptions totalling 4,300 dollars a month and, more strikingly, sixty-eight paid seats for twelve human beings. Nobody had done anything wrong. There had just never been an owner.
| What Marcus found | The force behind it | Monthly | What he did |
|---|---|---|---|
| 68 seats for 12 people | Per-seat creep at onboarding | $1,180 of that spend | Removed 29 dormant seats, saved $520 |
| Analytics suite used for one weekly report | Whole platform, one feature | $399 | Retired, the report became a recurring task |
| Design platform on the top tier for brand fonts | Tier engineering | $180 | Dropped two tiers, saved $120 |
| Three annual plans from a good trial | Annual lock-in at peak enthusiasm | $610 equivalent | Diarised the renewal dates, two will lapse |
| Two tools doing the same job in two teams | No owner, so nobody compared | $245 | Standardised on one, saved $110 |
| Accounting, payments, code host, CRM database | None, these are systems of record | $1,690 | Untouched, and staying untouched |
The single biggest line was the dormant seats, which nobody had ever defended because nobody had ever been asked. The second was the analytics suite, which he replaced with one recurring task that pulls the same numbers and writes the same weekly summary. His records layer, at 1,690 dollars, did not move by a dollar and he never considered moving it.
Which of these can AI actually fix?
Two of the five, directly. It fixes the single-feature purchase, because a chore that lives inside a big platform can usually move to a recurring task instead. And it fixes part of per-seat creep, because tools bought so everyone can occasionally produce something become tools one worker uses on request.
It does not fix the other three, and pretending otherwise would be dishonest. Annual lock-in is a calendar problem. Tier engineering is a reading problem. The ownership vacuum is a management problem, and it is the one that undoes every saving you make if you leave it alone. Put a name against the software card before you change anything else.
It also will not replace the tools you actually use every day. Your accounting software, your payment processor, your customer database, your code host, and your document storage are not sprawl. They are the spine, and the entire point of trimming the rest is so the spine is easier to see.
Fix each force in the right order
- Name an owner for the software card — One person, publicly. Without this, every other step reverses within two quarters. It costs nothing and it is the step people skip.
- Kill dormant seats this week — Sort every per-seat tool by last login and remove anyone quiet for thirty days. This is the biggest single line in most stacks and nobody will defend it.
- List what you actually use in each big platform — Ninety days of real usage per tool. Anything where the list is one item long is a candidate for becoming a recurring task instead of a subscription.
- Diarise every renewal with its amount — Annual plans do not get cancelled, they get allowed to lapse. That only works if the date shows up somewhere you look.
- Move the chores, keep the records — Hand the repeat work to one AI Employee, starting from 50, and leave your ledger, processor, and databases exactly where they are.
Frequently asked questions
FAQ
How many seats does a typical small team overpay for?
Two to three times the number of daily users is common. Twelve people can easily carry fifty or more paid seats, because seats get added at onboarding and never removed when a project ends or someone changes role.
Is it worth negotiating with vendors instead of cancelling?
Often, and it is underused. Ask for a lower tier that keeps the one feature you need, or a seat reduction at renewal. Vendors would rather keep a smaller account than lose it, and the ask costs you one email.
Why do teams keep tools they admit they do not use?
Because cancelling requires someone to accept the risk of being wrong, and nobody owns that risk. The moment one person owns the software budget, the same cancellations that stalled for a year happen in an afternoon.
Should I avoid annual plans entirely?
Not entirely, but stay monthly for the first two renewals of anything new. Once a tool has proven itself over six months, an annual discount on it is a genuine saving rather than a bet placed at the peak of a trial.
Does consolidating into fewer tools create risk?
It creates a different risk, not a bigger one. Fewer tools means one outage affects more work, so keep your systems of record separate and only consolidate the work layer. That way an interruption delays chores rather than blocking your books or your payments.
What is the single most common wasted subscription?
A collaboration or project tool bought during one busy quarter, still billing per seat for a team that moved back to a simpler way of working. It is rarely expensive per seat, which is exactly why it survives every review.