The pitch was simple. One platform for everything. Scheduling, projects, customers, billing, all in one place. No more spreadsheets.
A year later, the platform is still there, still getting paid for every month. And around it, a little village has grown. A spreadsheet for the thing the platform doesn’t quite do. An email thread for approvals. A Slack channel where the real status updates happen. A whiteboard in the office. A notebook the owner keeps. Somebody re-typing data into the accounting system every Friday.
Six workarounds. Maybe more. And the owner is wondering if it’s time to switch.
What the owner thinks is wrong
“We picked the wrong software.” Maybe. Sometimes that’s exactly right. But a tool can be good and still be wrong for your business, and a tool can be right for your business and still fail because the setup was never finished.
Switching platforms is expensive in money, time and team patience. I’d want to know which situation we’re in before recommending that.
What I’d investigate
I’d list every workaround. Each spreadsheet, side channel, manual re-entry, and “oh, we just do that by hand.” For each one, three questions:
- What job is this workaround doing? Be specific.
- Why does it exist? Who started it, and what were they trying to solve?
- Can the platform do this job? Not “is there a feature with a similar name.” Can it actually do what the business needs here?
What’s probably underneath it
The workarounds tend to fall into three piles:
- Setup gaps. The platform can do it. It was never configured, or it was configured for a different way of working. Common after a rushed implementation.
- Process gaps. Nobody decided how the business does this thing, so no tool could hold it. People invented their own way, and their own way lives in a spreadsheet.
- Real product gaps. The platform genuinely can’t do something the business needs.
Usually the first two piles are usually bigger than the third. That matters, because if you switch platforms, piles one and two come with you.
What I’d change
I’d fix the setup gaps and the process gaps first, starting with the workarounds that cost the most time or create the most errors. Then I’d look at what’s left.
If what’s left is small and stable, keep the platform. If what’s left is large, central to how the business makes money, and truly can’t be done in the current tool, now you have a real case for switching, and a clear list of what the next platform must do.
That list is valuable either way. The right tool depends on what must work, what can’t break, what people will use, what it replaces, and what it connects to.
What I’d leave alone
Not every workaround is bad. A simple spreadsheet that one person uses, that doesn’t feed anything else and doesn’t break, can stay. I’m not trying to eliminate every outside tool. I’m trying to eliminate the ones that cause double entry, confusion, or missing information.
A useful gut check on each workaround: if the person who built it left tomorrow, would anyone know it existed? Workarounds that only one person understands are the riskiest ones, whatever pile they land in.
The tradeoff
Fixing the implementation means living with the current platform longer, including the parts you’re tired of. Replacing it means another migration, more training, and a period where things are messier before they’re better. Neither option is free. The point is to pick on purpose.
The pattern
Software rarely fails all at once. It gets surrounded. Every time it doesn’t quite fit, someone builds a little bridge around it, and after a while the bridges are the system.
The tool is not the system. The system is the tool plus the decisions about how you use it.
So before you book another round of demos, count the workarounds. Write each one down and mark it setup, process, or product. That list will tell you more than any demo will.
If you want a second set of eyes on the list, bring it to a Systems Fit Call.
