I started running a company remotely in 2005, well before it was trendy, and I care about this subject not because I’m enthusiastic about software. It is that a distributed company with tools that do not connect is simply a slower company, and I found that out the expensive way.
Rory Valen put it better than I could: automation is to your time what compound interest is to your money. I have been quoting him for years, because the comparison is exact — including the part people miss: the returns are trivial at first and only become interesting if you leave it alone long enough.
What the mess actually looked like
At one point I was running twenty-one domains and roughly thirty addresses, checked through a desktop mail client that lived on one machine. Each was a separate configuration; none of it was available anywhere else, and nothing knew about anything else. It wasn’t exactly a tooling problem. It was thirty small tooling problems solved individually, which is the usual way a company gets here.
Consolidating it onto one platform, at a few dollars a head, removed more friction than any single productivity decision I have made since. Not because the platform was remarkable, but because it put everything in one place.
The criterion that matters
There are thousands of applications in any of the big marketplaces — accounting, customer records, project management, all of them competent. Most people choose based on features, and that is the wrong axis.
The question to ask is: what does this connect to, and what does it make me type twice?
Entering a contact once and having it appear everywhere it is needed sounds like a small convenience. Across a team, across a year, the difference between that and re-entering it in four systems is somewhere around half the administrative effort, and it is effort that produces nothing. A slightly worse tool that integrates beats a better one that does not, every time, and it is not close.
Two failure modes
The first is the company that has bought nine excellent tools and has nine separate records of the same customer, none of which agree. The second is the company that refuses to adopt anything and runs on spreadsheets and memory. The second is more common in small businesses, and the first becomes more common as they grow, usually because everyone was allowed to solve their own problem.
The fix for both is the same, and it is organizational rather than technical: somebody has to own the question of what connects to what, and that person has to be able to say no.
And when they will not connect
Sometimes two things you genuinely need simply do not speak to each other. A whole category of middleware exists for exactly this, and it is worth the subscription—but only after you have checked that the integration you want doesn’t already exist natively, which, in my experience, it does about half the time.