Why disconnected PM, CRM, and ERP tools quietly cost you more than any single subscription

Most companies never decided to run on eight disconnected tools. It happened one reasonable purchase at a time. Sales needed a pipeline, so you bought a CRM. Delivery needed visibility, so you bought a project tool. Finance already had accounting software nobody wanted to touch. Each one made sense on its own. Together they create a tax that never shows up on a single invoice.

The subscription line items are the small part of the bill. The expensive part is the people work that exists only because your systems can't talk to each other. Rekeying, reconciling, chasing the real number, building the same report three times. That work is invisible in accounting because it's buried in salaries you already pay. Add connector fees and middleware on top, and the stack that looked cheap per seat gets expensive fast.

• Disconnected tools create a permanent labor cost that no subscription line shows.
• Duplicate data entry isn't just slow, it produces two versions of the truth and neither is trusted.
• Middleware and per-connector pricing often cost more than the tool being connected.
• A single system where a job, a customer, and an invoice are one record removes sync entirely.
• Consolidation is the wrong call for commodity functions like payroll and accounting. Keep those.

Nobody sat in a room and designed this. A stack accumulates the same way a garage fills up. Sales picked a CRM in 2019 because the rep was persuasive and the trial was free. Two years later the operations manager got tired of spreadsheets and put the delivery schedule in a project tool. Then somebody added a form builder to capture leads from the website. Then a scheduling app, because the project tool's calendar was awful.

Each purchase solved a real problem for one team. None of them were evaluated against the whole. That's normal, and it isn't a management failure. Software gets bought by the department that feels the pain, and the department that feels the pain doesn't care what finance does with the data afterward.

The trouble starts when the business grows past the point where one person can hold the whole picture in their head. At twelve people, somebody just knows which job is which. At sixty, that person becomes a bottleneck and then they leave.

Watch a new customer move through a disconnected stack. The lead comes in on a web form. Somebody copies it into the CRM. When it closes, somebody creates a project in the PM tool and retypes the customer name, address, and scope. Purchasing enters the same job into the ERP or accounting system to raise a PO. Finance types the invoice details in again at the end. That's the same customer entered four times.

Every one of those hops is a chance to introduce an error. Not a hypothetical chance. A real one, because people fat-finger addresses and abbreviate company names differently. Now "Harbor Point LLC" and "Harbour Pt. LLC" are two customers, and your revenue-by-account report is wrong forever.

Then there's reconciliation, which is the work of finding out which system is lying. Somebody has to compare the project tool's hours against the payroll export. Somebody has to figure out why the CRM says twenty-two open deals and the forecast spreadsheet says nineteen. This work produces nothing. It just restores confidence in numbers you already paid to collect.

Siloed data does something worse than waste hours. It slows down decisions.

Say you want to know your true margin by job type. The revenue lives in accounting. The labor hours live in the project tool. The subcontractor costs live in an inbox and a spreadsheet. To answer one question you need three exports, a lookup formula, and an afternoon. By the time the answer exists, it's describing last month.

So people stop asking. That's the real damage. Questions that take an afternoon to answer just stop getting asked, and the business starts running on instinct and anecdote. The loudest project manager's opinion becomes the strategy, because nobody can produce a number fast enough to argue with it.

There's also the trust problem. When two systems disagree, everyone picks the number that supports what they already wanted. Sales quotes the CRM. Finance quotes the ledger. The meeting becomes a debate about data quality instead of a decision about the business.

The standard answer to disconnection is a connector. Something like Zapier or Make, or a per-integration fee from the vendor. These tools genuinely work, and for small volumes they're a good buy. I've built plenty of automations that saved a client real time for a small monthly fee.

The pricing model is where it turns. Most middleware charges by task or operation, so the cost rises exactly as your business grows. A workflow that fires fifty times a month is trivial. The same workflow at eight thousand times a month moves you up two pricing tiers. Vendors also love charging for the integration itself. A CRM might be modest per user, and then the accounting connector is a flat monthly fee on top, plus the premium plan required to access it.

Then there's the fragility. Automations built one at a time by whoever was available become a web nobody documented. A field gets renamed in the CRM, three automations break silently, and you find out when a customer asks where their invoice went. There's no error dashboard anyone watches, because the person who set it up moved on.

The argument for a custom system isn't that it does more. It's that it deletes whole categories of work.

When the quote, the job, the schedule, the purchase order, and the invoice are all views of one record in one database, there is no sync. Not faster sync. None. The project manager changes the scope and finance sees it instantly, because they're looking at the same row. Duplicate customers can't happen, because there's one customer table. Reconciliation disappears, because there's nothing to reconcile against.

Reporting changes character too. Margin by job type stops being an afternoon project and becomes a screen. Not because the software is clever, but because the numbers were never separated in the first place.

Here's the arithmetic that matters, and you should run it with your own numbers rather than mine. Take your total monthly spend across every operational subscription. Multiply by twelve. Then estimate the hours per week your team spends on re-entry, reconciliation, and report assembly, and multiply by a loaded hourly rate. That second number is usually larger than the first, sometimes by a lot. A custom system is a one-time build against an ongoing sum of both. It has real maintenance cost, and hosting, and it needs an owner. But it doesn't reprice itself every January, and it doesn't charge you more for hiring people.

Picture a sixty-person specialty contractor. Every Tuesday morning, the operations coordinator spends about three hours building the week's job board. She exports open deals from the CRM, cross-checks them against the project tool, pulls material lead times from a purchasing spreadsheet, and emails a PDF to four supervisors. Anything that changes after 10am is wrong by lunchtime.

In a unified system, that job board is a live screen. It builds itself, because closing a deal creates the job, and the purchase order lives on the same record. The coordinator's three hours go back into actually chasing the two suppliers who are late.

That's one person and one recurring task. Multiply it across the estimator who retypes quotes, the bookkeeper who reconciles job costs, and the owner who waits until the eighth of the month to know how the seventh went.

Plenty of tools should stay exactly where they are, and anyone telling you to replace everything is selling.

Don't rebuild accounting. QuickBooks or NetSuite handles tax rules, audit trails, and accountant access that you do not want to own. Don't rebuild payroll. Don't rebuild email, storage, or e-signature. These are commodity problems solved well by vendors who spend more on compliance than your whole IT budget. A custom system should talk to them cleanly and stay out of their way.

Be honest about the migration cost too. Moving twelve years of history out of a hosted tool takes a scripted export, not a copy and paste. Attachments, comment threads, and custom fields rarely come out in usable shape on the first pass. If your customers log into your current portal every day, moving them is a change management project, not a technical one.

And a custom system needs an owner. Not a big team, but someone accountable for hosting, backups, and the small changes the business will want. If nobody inside will hold that, a build becomes another orphaned asset in three years.

Map the path one customer takes through your business, from first contact to final payment. Write down every system the record touches and every point where a human retypes something. Most owners find between four and seven retype points, and two of them are pure duplication that could go away with no new software at all.

Then price the glue. Then price the labor. If the total is uncomfortable, the question isn't whether to renew. It's whether you want to keep renting the workaround.

If you want a second set of eyes on that map, book a free strategy session and we'll walk through it with you.

Isn't buying an all-in-one platform cheaper than building?

Often, yes, and you should check that first. All-in-one suites work well when your process looks like everybody else's. The trouble is that they force you to change how you work, and the bits that make you money are usually the bits that don't fit the template.

How do I know if the rekeying cost is really that big?

Count the events for two weeks, then estimate minutes per event. Multiply by loaded hourly cost, not salary. Most people underestimate by half because they forget the error correction that follows.

Can't we just hire someone to clean up the data instead?

You can, and it'll look fixed for about a quarter. Data quality problems come back when the cause is structural. If two systems both store the customer name, they'll drift apart again.

What happens if we build something custom and then want to change it?

You change it, because you own the code and the database. That's the main practical difference from a subscription. The constraint becomes budget and priorities, not what a vendor decided to put on the roadmap.

Do we have to move everything at once?

No, and you shouldn't. The workable pattern is to build the central record first, connect the existing tools to it, and retire them one by one as the new system proves itself.

Custom software versus off-the-shelf: how to decide without guessing walks through the evaluation in more detail, including when buying genuinely wins.

Related articles

• What it really costs to own custom software after launch
• Integration versus consolidation: picking the right fix for a messy stack
• How to migrate years of data out of a SaaS tool without losing history