A senior person at a mid-market services business spends thirty minutes on a Tuesday afternoon trying to figure out why the company’s contact information for one of its larger clients is different in three systems. The CRM says the office is at 1411 South Wabash. The ticketing system says 1410. The billing exporter has an address that has not existed for six years. The senior person is not paid to reconcile addresses. They are paid to think about strategy and win the next account. Tuesday afternoon goes to the address question. By Wednesday, somebody finally remembers that the CRM record is the correct one. A change request goes in. It will not be done by Friday.
This is the coordination tax. It rarely appears as a line item, which is part of what makes it expensive. Nobody invoices the company. The money is paid in time, in errors, in missed work, and in the senior person’s growing suspicion that nothing in the stack is exactly right. It is paid every day, by exactly the people the business needs paying attention to bigger problems.
How the tax got here
Twenty years ago, the alternative to a fragmented stack was a single suite from one vendor. The trade-off was clear and brutal: a complete answer to the team’s tools problem, and a complete answer to nobody’s individual feature questions. The CRM was acceptable. The email marketer was mediocre. The HR module had the wrong fields and could not be customized without a consultant.
So the market split. Best-of-breed won the feature wars. The CRM that focused on relationships beat the CRM that came with the email marketing tool. The team that bought ten best-of-breed tools got ten products excellent at their job. The team that bought one suite got a slightly worse version of every category in exchange for a single login.
The bet of the best-of-breed era was that integration would get solved later. What emerged was the integration market: a tier of products whose job was to talk to the other ten and keep the data flowing between them. The integration tier added its own audit log, its own admin console, its own outage modes, and its own staffing requirement. The integration tax was the new line item nobody had budgeted for, because it had not existed before the best-of-breed era arrived to charge it.
Where the tax shows up
In the Tuesday-afternoon address reconciliation, of course. But also in the deal that stalled because the proposal got lost in the gap between the sales tool and the e-sign tool. In the compliance officer who knows the policy in the document library, the policy in the training system, and the policy on the public portal are three different versions.
It shows up in the audit. The auditor asks for evidence. The team produces three versions from three systems. The auditor wants to know which is canonical. The team is not sure. The audit finishes with a reconciliation requirement that nobody on the team is paid to execute. This year’s reconciliation work is next year’s audit prep work.
It shows up in onboarding. A new senior hire spends their first month figuring out which of the eight systems they have access to is the one their team actually uses for what. The systems map no longer fits on a whiteboard.
It shows up in the customer’s experience. The customer receives a contract document themed in one brand, a follow-up email themed in a slightly different brand, and a portal login that opens to the vendor’s brand instead of the customer’s own. The customer has not been told the company is using ten tools to serve them. They figure it out, and they quietly update their internal note on the company to reflect a level of operational maturity below the one the company believed it was projecting.
Why the existing answers do not work
The existing answers fall into two patterns.
The first is to add another product. An integration platform. A master data management tool. A customer data platform. The new product enters the stack as the eleventh tool that promises to fix the previous ten. The tax does not go down. It becomes “the eleventh tool, plus the cost of integrating it with the other ten.”
The second is to commission a custom build. The build ships. The development partner moves on. The internal team rotates. Two years later, the build is a load-bearing dependency that nobody wants to touch. The cost of rebuilding is the cost of writing it the first time, plus the cost of migrating off the brittle layer.
Both patterns share an unspoken assumption: that the tools are correct in principle, and the only problem is connecting them. That assumption holds up only if audit trails, brand kits, relationship graphs, and the intelligence layer are features individual tools can own. They are not. They are platform concerns. They have to exist at a layer the tools share, or they do not get shared. A tool that owns its own audit trail does not produce an audit trail the rest of the stack can read. A tool that owns its own brand kit forces the marketing team to re-enter the brand kit nine more times.
Platform concerns cannot be retrofitted onto a federation of tools after the fact. That is not a technology limitation. It is a definition. Sharing happens at the layer beneath the tools, not in the integration tier above them.
What the right answer looks like
The right answer is a platform built from the start to share the things a federation cannot share. Authentication. Encryption. The brand kit registry. The relationship graph. The intelligence layer. The audit log. The isolation boundary.
What that gets the customer is the absence of the coordination tax. The senior person does not spend Tuesday afternoon reconciling addresses because the address is not in three systems. It is in one, partitioned for clarity, never reconciled. The auditor’s request for evidence is a query, not a manual export from nine places. The new hire learns the system map in a day.
That answer is not free. Building a platform with shared concerns in the shared kernel is a longer engineering road than building a tool with a thin integration. The bet is that the customer who has paid the coordination tax for a decade is willing to pay a one-time switching cost to stop paying it indefinitely.
The coordination tax is the problem. The platform is the answer. The Field Notes that follow this one work through how the platform is built and why it works the way it does.
[Request Early Access]