How Do You Know You Have Too Much Software?

Owners usually guess the stack is 15 to 20 tools. The accounts-payable exercise finds 40. That gap is real, and we wrote about it in the leaky bucket. It is still not the best diagnostic.

The tell is not the number of logos. It is how many bodies are thrown at a tool to cover for what the application cannot do on its own.

Raphael Bennett, Co-Founder and Principal at REV Global, puts it in operator language. You know you need to innovate. You hire instead.

The tell is not the logos

A painful CRM, a finance system nobody trusts, an inventory tool that requires a weekly export into Excel: those are not "software problems" once they have a person attached. They are process problems wearing a seat license. The application cannot do the job, so someone is paid to finish it by hand.

That person is competent. That is why the company keeps them. It is also why the tool never gets replaced. The workaround works just well enough that nobody wants to move it.

You hire instead of innovating

The pattern repeats.

• The tool is painful.
• Nobody wants to move it.
• Headcount becomes the patch.

Innovation would mean mapping the workflow, deciding what to own, and cutting the babysitting. Hiring feels faster. It also locks the tax in. Next year you still have the tool, plus the person, plus the person who trains the next person.

The cost shows up as payroll

Broken software plus extra people is not a strategy. It is a tax. It does not show up as a subscription line. It shows up as payroll, as delayed close, as a founder who is still the system of record.

Rule of thumb from this series: if the answer to a painful system is "hire another person to babysit it," you have too much software. Map the bodies, not the logos. That is the start of UnSaaSing, and it is what a Stack Audit is for.

UnSaaSing in practice, part 2 of 8. Previous: What Does UnSaaSing Actually Mean? · Next: This Is Not About Canceling Tools