Nobody consciously chose three systems. They accumulated - each one solved a problem and added a new one. How the typical software stack comes about, where context leaks out of it, and what can be done without a big bang.
Ask the owner of any fifty-person company why they use that particular combination of tools. You almost never hear an answer that starts with “we decided”. You hear a history.
The CRM arrived when the company hired a second salesperson. The project tool arrived when it became clear delivery couldn't be run out of email. The accounting package was always there. The spreadsheet for money appeared because neither of the others could work out margin. And the group chat arrived on its own.
Every one of those steps was right at the time. The sum is the problem.
How the stack comes about
The sequence repeats itself almost word for word:
Year 1. Jobs in a spreadsheet, communication in email. It works, because the company is small.
Year 2. A CRM arrives. It fixes sales - enquiries stop falling through the cracks. It also creates the first boundary: sales knows, delivery doesn't.
Year 3. A project tool arrives. It fixes delivery. A second boundary appears, and with it the first manual retyping: what the salesperson promised has to be copied into the project.
Year 4. Nobody knows what the jobs earn. A spreadsheet appears, into which numbers are pulled by hand from both systems. Third boundary.
Year 5. Somebody proposes connecting it all up. It turns out integration costs time and money and still doesn't cover everything.
Nobody chose this. It accumulated.
Each tool solved one problem and created one boundary. The work that happens on those boundaries appears on no invoice.
Where the context actually leaks
The loss isn't the data. The data exists - just not together. What's lost is the connections:
Sales doesn't know the project is on fire. They call the client with an upsell at exactly the moment delivery is slipping. The information exists, in a different tool.
Delivery doesn't know what was promised. A detail from the sales conversation stayed in a CRM note and never made it into the brief. The client is then surprised.
Nobody knows whether it was worth it. The invoice is in accounting, the hours in the project tool, the costs in a spreadsheet. The answer exists, but it costs half a day.
A new colleague learns three tools. And six months in, still doesn't know where things are kept.
The cost nobody invoices
| Where it arises | What it really is | Estimate for a 20-person firm |
|---|---|---|
| Retyping between systems | The same data entered two or three times | 10–20 h/month |
| Hunting | “Where's that contract?”, “What did we charge them?” | 8–15 h/month |
| Month-end close | Reconciling numbers by hand | 4–8 h/month |
| Extra licences | Three subscriptions instead of one | €600–1,600/year |
| Errors from mismatches | Forgotten invoicing, wrong date | Irregular, but expensive |
The table deliberately avoids precise figures - they come out differently for every company. What's worth doing is writing your own estimate; the act of writing it down is usually the surprising part.
Integration isn't a fix, it's a plaster
Connecting three systems with connectors shrinks the problem without removing it. Data still moves, it can still drift apart, and you've added a fourth thing to maintain. This is covered in detail in Are Zapier and Make dead?
What one data foundation looks like
The alternative isn't “one tool that does everything” - that's a marketing phrase. The alternative is one data foundation with different views on top of it.
In practice: there is one client database. A deal points at it. A job points at the deal. A timesheet entry points at the job. An invoice is generated from the job.
Sales sees a pipeline. Delivery sees a kanban or a calendar. The owner sees profitability. Everyone is looking at the same data through a different lens. Nothing moves anywhere, because there's nowhere to move it from or to.
That removes an entire category of work - not because someone does it faster, but because it stops existing.
What to do when you're in the middle of it
Nobody can switch off three systems on a Monday. A sensible route has three steps:
1. Find the boundary that hurts most. Almost always it's between sales and delivery, or between delivery and money. Start there.
2. Build a shared foundation for that one boundary. Clients and jobs in one place. Leave the rest alone.
3. Expand based on what proves itself. Most companies find after two or three months that one of the original tools has stopped being opened - and only then switch it off.
What fragmented tools cost is covered in detail in What fragmented tools cost a company. What a connected workspace looks like in practice is in Connecting documents, databases and chat. Specific comparisons are on the Apexloop vs. Raynet and Apexloop vs. Freelo pages. The full route to consolidation, from decision to running it, is in the guide to a custom business system.
Common questions about consolidating systems
Do we really have to abandon all our current tools?
No. The accounting package usually stays - it has its own reasons and legal obligations attached. Consolidation makes sense for operational data: clients, jobs, deadlines, timesheets, documents.
Won't one system for everything be a compromise at everything?
It's a real risk and worth naming. What decides it is whether you can shape the data model yourself. If you can, it isn't a compromise between industries - it's a system built around you.
How long does a move like this take?
The first boundary is usually days to a couple of weeks. A full move for a twenty-person company typically takes one to three months - not because the technology is slow, but because people adjust gradually.