How much of the software you pay for every month do you actually use? In most places that call me in, the answer is a sliver. Someone set it up years ago, and the staff built their whole routine around doing by hand the exact work the software was bought to do. When I ask why, they always say their situation is special and needs a human touch. It almost never is. The workaround becomes the only thing holding the place together, and everyone mistakes it for the rule. There is rarely a clear number to point to either, so nobody can see what the habit is costing every month, or what it is costing the mission.
The worst version I have seen was an organization running a powerful system with its tracking switched off across the board. It had been that way for at least a decade, maybe longer. The teams that brought in the money were flying blind, waiting on a handful of fixed reports one person built by hand that answered none of the questions they had. The feature that automatically sent customers what they had already paid for was turned off too, so one employee was tasked with sending it all out by hand, on the belief that the automation could not be set to their timing. It could. And worse, there was no test environment at all, so every change went straight onto the live system that ran the whole place.
All of it was defended with reasons that did not survive a second question. I checked with the software’s own developers and its support team, and they confirmed it: those features were built to do exactly those jobs, and turning them off was a mistake, not a special case. Knowing is not the same as fixing. Some organizations would rather not look, and that refusal ends up costing more than the misconfiguration ever did.
That extreme is rare. The everyday version is everywhere, and it hides better. Most organizations do not need more software. They need the one they already pay for set up for how they actually work.
The quiet version looks like this. An organization buys a tool that solves a real problem. Someone gets it running in an afternoon, and that is where it stays. The tool is not failing. It is doing exactly what it was configured to do, which is not much.
I have built the systems organizations run on for more than twenty years. Web and application development first and longest, then the CRM, booking, reporting, and the integration code that ties one tool to the next. I have worked deep inside the all-in-one platform that arts and cultural organizations run on. I built its mobile ticket templates. And when its own reporting could not reliably tell me what had happened in past years, I went straight into the database and wrote the queries by hand to get numbers people could trust. I worked across every part of that system, and the same gaps ran through all of it. That work is why I can open a piece of software an organization is frustrated with and usually find that the problem is not the tool. It is the configuration nobody finished.
The same hidden misconfigurations repeat across every kind of business. Decades of duplicate records across the system, so no count of members, donors or buyers can be trusted. A booking system built around one department’s convenience, leaving every other team, and the mission, running blind. The wrong tool bought for the job, then forced to fit, so no amount of setup could make it work. A monitoring tool that shipped with the system, never switched on, that nobody thought to look for until a small glitch at the busiest moment sent the staff into a panic.
Why does this happen so often? Software is sold on a demo where everything is already configured, and bought by people who are busy running the organization, not administering a tool. In a mission-driven place it is worse, because every spare hour goes to the work and the people it serves, not to a settings screen. So it gets set up by whoever had the time, the person who did it moves on, and the reasoning leaves with them. Defaults are built for an average customer who does not exist, and nobody goes back to change them once the thing is technically working. The gap between technically working and actually working stays invisible, and it compounds quietly, a little more each year, until it has been running that way far longer than anyone realizes.
And it does cost something, every month. You pay the same subscription whether the tool does its whole job or a fraction of it. Capability you already bought sits switched off or misconfigured. When I find one of these, the owner or director is usually relieved, because the fix is not a purchase. It is an afternoon of configuration on something the budget already covers. That is as close to found money as this work gets, and for a mission-driven organization it is money that goes back to the work instead of another line the board has to approve. When budgets are tightening, the money hiding in what you already pay for is the first place to look.
So before I recommend buying anything, I look at what is already paid for. I take the tool the organization is unhappy with, find out what it was meant to do, and compare that to what it is actually doing. Most of the time the answer to “we need a better tool” is that the current one was never asked to do its job. And it is not only small shops. I find the same inside large organizations that should know better, where a bigger budget and more staff just mean more settings nobody owns.
I learned to distrust the surface reading where a wrong setting was not a small inconvenience. The costliest are the all-in-one systems where everything runs off one core, so a single setting left wrong does not stay put. It quietly breaks what depends on it, and a team fighting a problem in one place is often losing to a setting left wrong somewhere upstream. The instinct came from harder places, where a wrong setting showed up fast. Point-of-sale counters, venue networks, equipment out in the field. A system that looks like it is running while it is misconfigured is worse than one that is plainly broken, because nobody goes looking until the loss finally shows up. The setup that runs is not the setup that works.
If a tool you pay for is disappointing you, there is a good chance it was never set up for your business in the first place. That is worth checking before you replace it, because replacing it means paying again to reach the same starting line, and the new tool will need the same careful setup the last one never got. The tool probably is not broken. It was never finished. And unfinished is a much cheaper problem than broken.