A founder told me last month that her company does not build software. They sell flowers. They have a website, a few SaaS tools, and a small ops team. No engineers. She was proud of how lean it was.
Then she walked me through how an order actually moves through her business. A customer buys on the storefront. The storefront fires a webhook to a script that pushes the order into a spreadsheet. A scheduled job reads the spreadsheet, checks inventory in a second tool, and emails the warehouse. Another script syncs the customer into the email marketing tool, but only if they ticked a box, and that box logic lives in a fourth place. When something breaks, and it breaks most weeks, one specific person fixes it. Nobody else fully understands it.
She does not build software. Except she does. She has built a fragile, undocumented, business critical system out of webhooks, scripts, and hope. She just never called it that, so it never got a budget, an owner, or a plan.
This is the integration tax. It is the slow, invisible cost of stitching tools together, and it is quietly the biggest engineering project at a surprising number of companies that swear they do not do engineering.
Nobody Decided to Build This
The integration tax is dangerous because no one ever chooses to pay it. It arrives one reasonable decision at a time.
Year one, you pick a great tool for billing. Smart move. Year one, you pick a great tool for support. Also smart. They do not talk to each other, so someone writes a small script to copy data across. Tiny. Harmless. Takes an afternoon.
Year two, you add a CRM. Now the billing tool, the support tool, and the CRM all need to agree on who a customer is. The afternoon script becomes three scripts. Someone adds a tool to schedule them. A spreadsheet appears as the place where the scripts dump things they are not sure about.
Year three, you have eleven tools. Maybe fifteen. Every pair that needs to share data has a little bridge between them. Some bridges are official integrations. Some are paid connectors. Many are scripts that one person wrote and only that person understands. The number of possible connections grows much faster than the number of tools, and your glue grows with it.
At no point did anyone hold a meeting and say "let us build a custom internal platform." But that is exactly what you now run. It just has no name, no diagram, no owner, and no budget. That is what makes it a tax instead of an investment.
What the Tax Actually Costs You
The reason this hides so well is that the cost almost never shows up as a line item. It shows up as friction spread across the whole company, which is much harder to see and much easier to ignore.
Here is where the money and time actually go.
**People time.** Someone spends a few hours every week keeping the bridges alive. A failed sync here, a changed field there, a tool that pushed an update and broke the connector. It rarely feels big in any single week. Add it up across a year and it is often a full salary, spent by people whose job title says something else entirely.
**Slowness.** Every new idea now has to pass through the maze. A simple request like "can we add a field for customer region" becomes a small project, because that field has to travel through four tools and three scripts. The business slows down, and the slowness gets blamed on the idea, not on the plumbing.
**Fragility.** The system works until one vendor changes an API, one script silently fails, or one person leaves. Then orders go missing, customers get billed twice, and the team spends a frantic week firefighting. The cost of a single bad incident can dwarf a year of the quiet weekly cost.
**Key person risk.** There is always one person who understands the glue. When that person is on holiday, change freezes. When that person quits, you do not just lose an employee. You lose the only working documentation of how your business runs.
**Decision drag.** Because the integration layer is invisible, leaders make plans as if it is free. They greenlight a new tool without counting the new bridges it needs. The tax compounds because the people approving spend cannot see the bill.
Add these up and the integration layer is often more expensive than the most expensive single tool in the stack. It is just spread thin enough that no one ever totals it.
Five Signs You Are Already Paying It
You do not need an audit to spot this. The symptoms are specific, and most teams recognize them instantly once someone names them.
**One, there is a spreadsheet in the critical path.** Not a spreadsheet for analysis. A spreadsheet that orders, customers, or money flow through. If a shared sheet broke and your operations would stop, that sheet is load bearing infrastructure, and nobody is treating it that way.
**Two, one person is the integration.** Ask the team what happens to the syncs if a specific named person is unavailable for two weeks. If the honest answer is "we would be in trouble," you have a single point of failure that thinks and sleeps.
**Three, small data changes feel huge.** Adding one new field, or changing how you label a customer, turns into a multi day project that touches several tools. The size of the change does not match the size of the request. That gap is the tax.
**Four, you find out about breakages from customers.** A healthy system tells you when a sync fails. A taxed system tells the customer first, through a missing order or a wrong invoice, and you find out when they complain.
**Five, nobody can draw the system.** Ask three people to sketch how data moves through the company. If you get three different drawings, or three blank faces, then the real system exists only as scattered scripts and tribal memory. That is not a stack. That is a liability.
If you nodded at three or more of these, you are not at risk of an integration problem. You have one. The only open question is whether you manage it on purpose or keep paying it by accident.
Why More Tools Is Not the Fix
The instinct, when the glue hurts, is to buy a tool that manages the glue. An integration platform. A workflow automation product. Another connector service. These tools are real and they have a place, but reaching for one first usually treats the symptom and feeds the disease.
Here is the trap. An automation tool makes it easy to add the next connection, so you add more connections. The tool lowers the cost of one bridge and quietly raises the total number of bridges. Six months later you have the same tangle, now with a monthly bill and a new tool that one person understands.
These platforms shine when the problem is genuinely simple and stable. Move a row from here to there. Send a notification when a deal closes. For glue that is shallow and unlikely to change, they are great, and you should use them without guilt.
They struggle when the logic is the actual business. How an order splits across warehouses. How a refund changes a commission. How a customer in one region gets taxed and routed differently. That is not plumbing. That is your company's rules, and rules that matter belong in something you own, can test, and can explain, not buried inside thirty branching steps in a visual builder that only one person can read.
The honest question is not "which tool moves this data." It is "is this connection trivial glue, or is it secretly the core of how my business works." Those two answers lead to very different places, and confusing them is how the tax gets worse while you feel like you are fixing it.
The Way Out Is a Map, Not a Tool
The fix starts with something unglamorous and almost free. Draw the system. The single most useful hour a leadership team can spend is putting every tool, every script, every spreadsheet, and every connection on one page. Not a polished diagram. A whiteboard photo is fine.
That map almost always produces the same reaction. People are surprised. They did not know that script existed. They thought that sync was official. They forgot that tool was still wired in. The map turns an invisible system into a visible one, and you cannot manage what you cannot see.
Once it is on paper, sort every connection into one of three buckets.
**Trivial and stable.** Simple, rarely changes, low blast radius if it breaks. Leave it on a connector or an automation tool. This is the right home for it. Do not over engineer it.
**Important and changing.** Carries real business logic, changes often, hurts a lot when it breaks. This is the part that deserves to be owned, written as real code, tested, documented, and given a clear owner. Often this is a small custom service that sits in the middle and becomes the one place the rules live.
**Pointless.** A surprising number of connections exist because of a decision nobody remembers, feeding a tool nobody really uses. Delete these. The cheapest integration is the one you switch off. Most maps have at least a few.
You do not need to rebuild everything. You need to move the important and changing parts out of the shadows and into something deliberate, while leaving the trivial parts alone and cutting the dead ones. That is a focused project with a clear edge, not an open ended rewrite.
Build vs Buy, Asked Honestly
This connects to an older question that never goes away. When do you buy a tool, and when do you build your own. The integration tax changes how you should answer it.
The usual build versus buy debate compares the price of a tool against the cost of building a feature. That comparison is incomplete because it ignores the bridge. A cheap tool that needs three fragile syncs to fit your business is not cheap. Its real price is the subscription plus the integration tax it adds forever.
A better question to ask before adding any tool is simple. How many new connections does this create, who will own them, and what happens to the business if they fail. If a tool needs to deeply share data with four systems and carry core logic, the integration tax it brings may cost more than the tool itself, every year, quietly.
Sometimes the right answer is still to buy. Sometimes the right answer is a small custom piece that replaces five tools and ten bridges with one thing you own and understand. The point is not that custom always wins. The point is that you cannot make the call honestly until you count the glue, and almost nobody counts the glue.
If you want a fuller framework for that decision, the [build, buy, or subscribe guide](/blog/build-vs-buy-vs-subscribe-software-decision) walks through it step by step. Pair it with this post and the question gets much clearer, because you stop comparing prices and start comparing total systems.
A Calm Plan, Not a Panic
If this post described your company, resist the urge to call it an emergency and rip everything out. A panicked rebuild is just the integration tax in a different costume. Do this instead.
In the first week, draw the map and take a photo. Get the tools, scripts, sheets, and connections onto one page with the rest of the team, not alone.
In the first month, sort every connection into the three buckets, and turn off everything in the pointless pile. That alone usually removes real risk for zero cost and builds momentum.
In the first quarter, pick the single most important and changing connection, the one that hurts most when it breaks, and give it a real home. Real code, a test, a short doc, a named owner. One connection, done properly, not all of them at once.
After that, repeat the quarterly step. One important connection at a time, moved from tribal memory into something owned. Within a year the scary middle of your stack is deliberate, documented, and survivable, and you got there without a dramatic rewrite or a frozen roadmap.
The companies that handle this well are not the ones with the fewest tools. They are the ones who decided, on purpose, which connections they own and which they rent, and wrote it down. The integration tax does not go away because you bought more software. It goes away when you stop pretending you are not running an engineering project, give it a name, and treat it like one.
You probably did not set out to build an internal system. Most companies do not. But if money and orders flow through scripts and spreadsheets that one person understands, you already built one. The only choice left is whether you keep paying for it by accident, or start managing it on purpose.