Integration Debt in SMB Software: Spotting Fragile Connections Before They Break
Most small teams do not choose their software stack in one go. They add a CRM here, a payments tool there, then connect them with a no-code automation or a quick API key handed over by a developer who has since left. Each link feels small. Together they form a web of dependencies that nobody has drawn, documented, or tested. This is integration debt: the accumulated cost of connections that work today but are poorly understood, hard to change, and quietly load-bearing. For UK founders and operators, it is worth treating integrations as a distinct asset class with their own review cycle, separate from the tools themselves. This article sets out how to find them, what to examine, and which questions to put to vendors. It makes no assumptions about any particular product's capabilities; the aim is to give you a method you can apply to whatever is already running in your business.
What counts as an integration
An integration is any mechanism that moves data or triggers an action between two systems without a person doing it manually. That includes native connectors built into a vendor's product, third-party automation platforms that sit between tools, scheduled exports and imports, webhooks, and direct API connections written by a developer. It also includes less obvious links such as a spreadsheet that pulls from a sales tool every morning, or an email rule that forwards invoices into an accounts folder.
The easiest way to start is a simple inventory. List every tool your business uses, then for each one ask: what does it send out, what does it receive, and what runs in the background? Your team will usually know about the obvious connections. The gaps tend to sit with whoever set things up originally. Ask them directly, and check the admin panels of each tool for connected apps, authorised applications and API keys. Many SaaS products list these under security or developer settings, and the list is often longer than anyone expected.
Mapping data flows, not just tools
Once you have the connections, draw them. A simple diagram with tools as boxes and arrows showing what data moves, in which direction, and how often is enough. Label each arrow with the data type: customer contact details, invoice values, employee records, support tickets. This matters because the risk of a connection depends on what it carries, not on how important the tool feels.
Pay particular attention to any flow that carries personal data, since UK organisations have obligations around how personal data is handled and where it goes. A diagram lets you see whether personal data is leaving your core systems and landing in tools that were never assessed for that purpose. It also reveals duplicate flows, where the same data is copied into three places and updated in only one.
Signs of a fragile connection
Some connections are more likely to cause trouble than others. Watch for these patterns:
Connections owned by a single person. If only one individual knows how a flow works, or holds the login used to authorise it, that is a single point of failure. Record who set it up, where its credentials are kept, and who else can reconfigure it.
Credentials tied to personal accounts. An integration authorised with an individual's login will often stop working when that person leaves or changes role. Prefer service accounts or shared administrative identities that the business controls, and document where they are held.
Silent failure. Some flows fail without notifying anyone. If you cannot tell from the tool's interface whether a sync ran successfully on its last scheduled attempt, treat that flow as unmonitored.
Undocumented transformations. A flow that renames fields, merges records or filters rows is making decisions on your behalf. If those rules exist only in someone's head or inside a configuration nobody reads, they are a hidden risk.
Unused but still active. Integrations left running after a tool is cancelled, or after a process changes, keep moving data into places nobody watches.
Questions to ask vendors before connecting
Before you enable a new native connector or approve a third-party integration, put these questions to the vendor or read their documentation for answers. Where the answer is not clear from public material, ask for it in writing.
What data does this connection read, and what can it write? Ask for the specific scopes or permissions requested, and whether you can limit them. Broad read-and-write access granted for a narrow task is a common source of unintended changes.
How is the connection authenticated, and how are credentials stored and rotated? Find out whether you can revoke access centrally without relying on the individual who authorised it.
What happens when the connection fails? Ask how failures are surfaced to you, whether there are logs you can review, and whether a failed sync can be retried without duplicating records.
How are changes to the upstream or downstream tool's API handled? Connections break when vendors change their interfaces. Ask whether the vendor gives notice of breaking changes and how long a deprecated version remains available.
Where is the data processed and stored? For UK businesses this is often a question about international transfers. Get the answer from the vendor's published documentation rather than assuming.
Some of these questions will return vague answers. That itself is useful information when you are choosing between options.
A practical integration review routine
Integration debt grows quietly, so it needs a recurring slot. A workable routine has four parts, run once a quarter or whenever you add or remove a major tool.
First, refresh the inventory and diagram. Compare the current admin-panel lists with your earlier map and note new or missing connections. Second, check ownership and credentials: confirm every integration has a named owner and that its credentials belong to the business, not a departed employee. Third, test a sample flow end to end, confirming that data arrived correctly and that failures would be noticed. Fourth, decide for each connection whether to keep, restrict, document or retire it.
Keep a short log of decisions. When someone asks in six months why a flow exists or why a permission was reduced, the log answers the question without archaeology. The effort is modest, and it turns a tangle of invisible dependencies into something your team can reason about and change safely.