When I sit down with someone running a growing business, there’s a frustration that comes up again and again, even though they rarely describe it as a technology problem. It usually surfaces as a small, nagging thing. They ask a simple question, like what’s the profit on this product, how much of the budget is left or did that customer actually pay, and suddenly it isn’t simple at all. Not without opening three different apps, exporting a couple of spreadsheets, and squinting at numbers that don’t quite agree with each other.
It often shows up as one of these issues:
- They are using too many bits of software, and they’re feeling tired of all of them.
- They’re not sure where to look for a particular piece of information.
- The same number lives in two places, and the two places disagree.
- They keep wishing the team would just use one tool properly (often Trello or Slack) as the thing that holds everything together.
- Someone is always locked out of something.
It feels like a problem with the tools (buy a better platform or app) or a discipline problem (if only people followed the process). In my experience, it’s often neither of these. So I want to lay out a calmer way of thinking about what’s happening and how to decide what to do about it, including recognising when the right answer is to do nothing for now.
The numbers that don’t agree are a real problem
Let me start by agreeing with something the technically minded people around you might be saying. When the same piece of data lives in two systems, and they don’t match, that’s a genuine operational problem. It isn’t fussiness, nor is it just a feeling. A business that can’t trust its own numbers makes worse decisions, time and time again. So the urge to fix it is a good one.
What’s usually wrong is the diagnosis. The disagreeing numbers are a symptom. The underlying cause, nearly every time, is that nobody has decided which system is to be trusted and which is allowed to be wrong.
The real problem isn't the software. It's that nobody has decided how it's all meant to fit together.
The enterprise software world has a name for this: “data silos” — every team and every tool sitting on its own copy of the information, none of them talking to each other. It’s the same thing you feel as the same number living in two places. The large vendors describe it in almost exactly the words you’d use yourself: spreadsheets everywhere, disconnected apps, every team with its own system. They’ve understood the problem perfectly well. They’re just selling the answer to a five-thousand-person company, not to you.
If “data silos” is the name for the problem, “single source of truth” is the name for the goal: one home for each piece of information, so there’s never a question about which copy is correct. It’s a software development phrase that sounds grand, but on your terms, it’s quite simple. For every important number, someone has decided where the trustworthy version lives. That’s a strategic decision, not a tactical one. You don’t fix the disagreeing numbers by wiring every tool to every other tool. You fix them by deciding where the truth is allowed to live in the first place.
That decision is exactly what I mean by a technical strategy. Not an impenetrable document, but a choice about how the technology is meant to serve the business. The tools-that-don’t-talk problem is almost always that decision never having been made.
Why “just connect them up” is the wrong instinct
When you notice these issues, the natural instinct is to start joining software systems together — after all, the symptom is that they’re disconnected, so connecting them looks like the obvious cure. I tend to see three versions of it. The first is to coordinate everything by hand, often with the help of a master spreadsheet kept up to date by copy-and-paste. The second is to glue the tools together with something like Zapier. The third is to lay down strict rules and hope the team sticks to them.
Any of these can be the right move in the right place. The trouble comes from reaching for them automatically, because the connections they create tend to be fragile. They assume the world stays exactly the same shape as it was on the day you set them up, rather than accepting the ever-changing reality. Logins expire. A tool changes something about its behaviour, and the connection breaks without anyone being told. These connections are hard to inspect and hard to hand over. In many cases, only one person really understands how the whole arrangement hangs together, or worse, a few people each understand a different bit of it.
The bigger issue is that each little connection is a small permanent debt that isn’t being tracked. Nobody sends you an invoice for it, so it feels free. It isn’t. The cost is just invisible, which isn’t the same thing.
So the shift I’d encourage is small in wording but large in practice. Stop trying to wire the tools together, and start deciding how they ought to work together, on purpose, as a managed part of running the business.
The fix is a ladder, not a single leap
The mistake I see most often is treating this as a straight choice: limp along with the mess, or commit to a big, expensive build. It very rarely is. It’s more like a ladder, and you only climb to the next rung when the pain of staying where you are justifies it. The important thing to understand is that no rung is a destination you’re obliged to reach. Each one is a perfectly good place to stop and stay, sometimes for years. Most businesses should settle fairly low down and stay there quite happily. You move up only when your current rung stops paying its way, never simply because a higher rung exists.
The first rung is to reduce. Fewer tools, chosen deliberately. A surprising number of “our systems don’t talk to each other” problems turn out, on closer inspection, to be a case of “three different tools are doing two jobs”, and removing a tool is often the cheapest and calmest fix available.
The second rung is to use the right tool for each job and to let people knowingly carry information between them. You accept that a person moves a piece of data from one system to another, on purpose, as a known and bounded task, rather than by accident. For most small businesses, this is a perfectly good place to rest, and I’d treat it as a success rather than a failure. The bit of duplication you put up with here is a cost you’ve chosen with your eyes open, not a mess you’ve ignored.
The third rung is a few managed connections. A small number of deliberate, properly owned integrations, built only for the joins that genuinely hurt. Owned rather than glued, and chosen rather than left to sprawl.
The fourth rung is to own a core system of your own, replacing a whole category of tools with something built for you. This is real, but it’s the last rung, and in my experience, it almost never arrives as a dramatic, all-at-once build. More often, it starts as a small increment on the third rung: an integration that gets moved into an in-house system, and then gets enhanced with your particular way of working. Over time, it may grow and become the heart of the business. Plenty of businesses never need to get here at all, and plenty of integrations should stay exactly what they are for good.
Whenever building an in-house system comes up, there are three questions I’d suggest asking first, before any work starts, rather than after. Who is going to build it? What, precisely, is it for (and be quite ruthless about keeping that small)? And how will it be kept running once it exists? Being ready isn’t only a question of whether you’re big enough. It’s whether you can answer those three questions. A small business that can answer them might well be ready, and a large one that can’t, isn’t. When the honest answer is that you’d need help to build it and look after it, that’s the point at which bringing in someone to lead the technology earns its keep, and not a moment sooner.
The economics of it
Underneath all of this, there’s a simpler question about money, and it’s worth saying plainly. Renting tools and gluing them together is cheap to begin with, and gets steadily more expensive as you grow: more seats, more connections, more friction, more fragility, and eventually a chunk of someone’s week spent just keeping the whole thing standing up. Owning a system you’ve had built is the other way round. It’s expensive to begin with, and then it flattens out, because the cost is largely fixed and tends to scale with you much better.
The two curves cross over at some point, and almost the whole decision comes down to working out which side of that crossover you’re on. Before it, building your own is really an indulgence, and renting is the sensible, grown-up choice, so I wouldn’t let anyone make you feel amateurish for staying there. After it, carrying on gluing things together becomes the expensive and fragile option, even though it still feels cheap, because no invoice ever actually lands on your desk. That’s the point where owning starts to make proper sense.
I’ll say one thing about AI here (because everyone asks now). AI lowers the up-front cost of building, which moves that crossover point earlier, so more businesses can sensibly own something sooner than they could a few years ago. But it doesn’t move it to zero. The cost AI can’t take away is ownership: who actually understands the thing, who can change it when something breaks, who monitors it to spot when it stops working, and who’s accountable when it doesn’t behave. Code nobody fully understands is fragile, whoever wrote it.
What this costs you in the end
A cost nobody is tracking doesn’t stay hidden forever. It just gets to choose its own moment to appear, and that moment is rarely a convenient one.
Somewhere in all those tools is something carrying real business weight. The system your orders run through, the place your customer list really lives, the integration that keeps your website and your stock in step. It works, so you stop thinking about it. The uncomfortable question is what happens on the day it needs to be thought about. If the one person who understood how it all hangs together has left the company, what do you do? And if the login sits with a supplier or a freelancer you’ve half forgotten about, who actually holds the keys to your own business?
When something important has been running on knowledge and access that sit outside the business, and nobody explicitly decided it should be that way, it will probably hurt at some point.
It was easier at the time, and then it was never anyone’s job to change. It surfaces at the worst moments: it can be when a system you interact with changes, or when your online shopfront goes down (a true story I once encountered). It can also be when a buyer or investor hires someone technical to take a good look under the hood before they acquire you or put money in, and they ask where all of this actually lives and who controls it. When the answer is a tangle of tools nobody fully controls and one person nobody can replace, that directly lowers what your business is worth. The glue that felt free for years turns out to have had a price all along, and you don’t get to choose when the bill lands.
The honest answer
So when someone tells me their software systems don’t talk to each other, my honest answer is that it usually isn’t a new tool they need, and it isn’t necessarily a big build either. Sometimes the right move is one fewer tool, used deliberately. Sometimes it’s a person bridging a gap on purpose. Sometimes, eventually, it really is building something of your own. What it always comes down to is deciding, deliberately, how these tools are meant to work together, and being honest about which rung of the ladder you’re actually standing on. That isn’t a software problem. It’s a decision waiting to be made, calmly, by the person running the business.