A decade ago, a small business ran on two or three software systems and a spreadsheet, and the owner could name every one. Today that same business has a CRM feeding a marketing tool feeding a billing platform feeding a support desk, with a scheduling app and an e-signature tool bolted on the side. None of it talks to the others without help. That help has a name on the invoice, an hour count in someone's week, and a failure mode nobody planned for.
The connective tissue between the tools, not the tools themselves, becomes the single most expensive system the company owns. This piece walks through the shapes that integration tax takes inside a small business, and when the math starts to favor building over buying.
The Invisible Line Item on Every SaaS Invoice
The subscription bill is the visible cost. The hidden one is the code and configuration holding the tools together. A well-known Google research paper on hidden technical debt made the point plainly: the glue code between systems eats a disproportionate share of engineering effort, and rarely gets refactored because it never feels urgent.
It usually works today, right up until it doesn't. For a small business, that glue is a mix of iPaaS workflows, a few Zapier or Make automations, a webhook or two, and a handful of CSV exports someone runs on Fridays. Before the next renewal cycle, it's worth reading the case for building instead of stacking another subscription, and pricing the alternative against the connectors rather than against the tools themselves.
The Per-Connector Case: Small Stacks, Big Multiplication
Every new tool added to a stack doesn't add one new connection. It adds a connection to every other tool it needs to share data with. Ten tools that each need to talk to three others means thirty relationships to build, monitor, and eventually fix.
For a small operation, this is where the integration tax first becomes visible without being counted. It shows up as:
- Duplicate data entry. Someone in operations keys the same customer into two systems because the sync only runs overnight, or breaks on records with an apostrophe in the name.
- Reconciliation work. A bookkeeper spends part of every week matching what the billing tool says against what the CRM says, because the two disagree in ways nobody has traced.
- The Friday export. A recurring manual job to move data from one platform to another because the native integration doesn't cover the fields anyone actually cares about.
Someone Owns the Maintenance, Even If Nobody Was Told
Vendor APIs change. Fields get deprecated. Authentication tokens expire on a schedule that made sense to somebody at the vendor and nobody at the customer. When a connector breaks before the workday starts, someone has to fix it, usually the operations lead or the one technical person on staff, on top of their real job.
The cost of that labor is the part founders consistently underestimate. It doesn't show up as a subscription. It shows up as the reason a launch slipped, a report went out late, or a new hire spent their first month troubleshooting instead of onboarding.
The Cases That Do and Don't Justify a Build
Not every integration tax is a signal to commission software. Some are the ordinary friction of running a business on modern tools. A few are the real tell. Consider commissioning something custom when:
- The workflow is the product. If the specific way your business moves an order from quote to fulfillment is the reason customers choose you, gluing generic tools together tends to fit awkwardly. A tool built around that workflow removes the seams.
- Three or more subscriptions overlap. When you're paying for pieces of the same job across a CRM, a project tool, and a billing platform, a single system that handles the overlap usually costs less to run than the connectors between the three.
- The integration is the failure mode. If your worst outages and slowest weeks trace back to a connector rather than a vendor, the connector has become the system. Manage it like one.
- The data is a competitive asset. If the value lives in the pattern across your customer, operations, and financial data, keeping it fragmented across vendors leaves that value stranded.
A build is the wrong move for a commodity function every business does the same way (payroll, email delivery, calendar), a workflow you're still figuring out and expect to redesign, or a problem that's really about process rather than software. Building doesn't fix a workflow no one has agreed on.
The integration tax is real, and it grows without anyone tracking it. The point isn't to rip out the stack. Notice when the glue between the tools has become the most expensive system in the business, and price the alternative before the next renewal cycle locks the number in for another year.
