Nobody sits down and chooses five technology suppliers. It happens one problem at a time. The website came from whoever built it in 2019. The till came with the shop. The accountant recommended the bookkeeping package. Someone's cousin does the marketing. The IT support number is written on a card by the router. Each decision was sensible on the day it was made, and none of them was made with the others in view.
The cost of that arrangement is rarely in any single invoice. It sits in the seams.
The seams, described
A seam is any point where one supplier's work has to meet another's. The shop takes an order and the accounts package needs it. A customer changes an address and three systems hold a copy. A price changes and the till, the site and the delivery platforms each need telling.
Seams fail in a particular way. Each supplier will explain, accurately, that the part they are responsible for is working correctly. The gap belongs to you, and it gets patched by a person in your business, usually with a spreadsheet, usually on a Tuesday.
Count your own. Every export you run by hand, every figure you retype, every change you have to announce to more than one supplier is a seam. Write the list on one sheet of paper. The same items tend to reappear month after month, which is what makes them worth costing.
The seams also explain why small changes take so long. A request that touches one supplier moves at that supplier's pace. A request that touches three moves at the pace of scheduling, because each one has its own queue, its own approvals and its own definition of done. The work itself might be two days. The calendar does the rest, and by the time it lands the reason for the change has often moved on.
Three ledgers a supplier sits on
Money is the ledger everyone tracks. Two more matter as much and get no reporting at all.
The accountability ledger
Here is the claim: every supplier you add is a contract you own. UK data protection law makes this concrete. The ICO's guidance is that whenever a controller uses a processor to handle personal data there must be a written contract binding that processor, and that the controller stays responsible for compliance regardless of what the contract says. Article 28 requires you to use processors that can provide sufficient guarantees about their expertise, resources and reliability.
Read plainly, that means five suppliers touching customer data is five contracts to hold, five sets of guarantees to assess, and one organisation carrying the responsibility for all of it. Yours.
Security follows the same shape. The government's Cyber Security Breaches Survey 2025/2026, published on 30 April 2026 by the Department for Science, Innovation and Technology and the Home Office, found that 15 per cent of businesses had reviewed the cyber security risks posed by their immediate suppliers, and 6 per cent had looked at the wider supply chain. Among small businesses the figure for immediate suppliers was 22 per cent. Most supplier relationships are running without anyone having checked the supplier.
The attention ledger
Every supplier consumes a slice of somebody's week: the briefing, the chase, the invoice query, the renewal, the annual review that never quite happens. Five relationships is five sets of context to keep in your head and five people who each know a quarter of the story.
That cost lands on the owner or the office manager, who is also the person you would rather had time to think about the business. It never appears in a budget, and it is usually the real reason a needed change keeps slipping down the list.
There is a knowledge cost inside it. Context lives in the supplier who built the thing, and when that relationship ends the context leaves with it. Businesses running several suppliers over several years accumulate systems that nobody currently working with them fully understands, which is how a small change becomes an exploratory project.
The money ledger, read properly
The invoices are only part of it. Add the duplicate subscriptions two suppliers each bring, the integration work commissioned twice because neither party would own the middle, and the hours your team spends on the patches. That total is the honest cost of the arrangement.
What one partner actually changes
The mechanism is shared context. When the same team holds the shop, the till, the automation and the support, a decision made in one place reaches the others without being retold. A change to the checkout reaches the reporting. A new product type reaches the delivery menus. Nobody has to translate.
The second change is a single accountable line. When something breaks in a seam, there is one number to call and no route by which the problem can be described as somebody else's scope. It removes the day spent establishing whose fault it is.
The third is sequencing. One partner can put the work in an order that makes sense, because the same people know that the reporting depends on the till migration, which depends on the product data being cleaned. Separate suppliers each optimise their own piece and the dependencies get discovered late.
The fourth is compounding. Work done by a team that already holds your context starts closer to the answer each time. The second project reuses the data model from the first, the third reuses the integration from the second, and the estimates come down for a reason you can point at. Estates spread across suppliers rebuild the same understanding repeatedly, and pay for it each time.
Where the argument stops
Consolidation concentrates risk, and the honest version of this case says so. You gain a single point of failure, in both the commercial sense and the operational one. That risk is manageable, and the way to manage it is ownership of everything the work runs on.
Every domain, hosting account, repository, cloud tenant and platform account should be registered in your name, with your billing details, with your people holding administrative access. Documentation should arrive with each piece of work, as it is delivered. The contract should name what you receive on exit and how quickly you receive it.
There are also jobs a generalist partner should decline. Deep specialisms, regulated work with its own accreditation, and anything where a niche vendor's product is decisively better belong elsewhere. A partner willing to say so is more useful across the rest of the estate than one that says yes to everything.
If you consolidate, do it in this order
Moving five relationships at once is how consolidation earns its bad reputation. Sequence it.
Start with the estate you can see. Have the new partner build an inventory: domains, hosting, accounts, licences, repositories, integrations, and who currently holds administrative access to each. Nothing moves in month one. The document is the deliverable, and it is worth having whatever you decide next.
Second, move the seam that hurts most. One integration, one workaround retired, one person's Tuesday given back. A first piece with a visible result tells you more about how a partner works than any amount of reference-checking, and it is small enough to reverse.
Third, move the thing with the clearest boundary. Managed IT and hosting usually qualify, because the handover is well defined and the previous supplier's involvement ends cleanly. Save the systems that are mid-project for later, and never move anything during your trading peak.
Fourth, review at six months against the seams list you started with. How many are closed. How many remain. What new ones appeared, because consolidation creates its own. That review is also the natural point to decide whether the arrangement deserves the rest of the estate.
Leave the incumbent relationships in good order as you go. Suppliers who exit politely answer questions six months later when something undocumented surfaces, and something undocumented always surfaces.
How to test a partner before you consolidate
Take the three largest pieces of work you expect to do in the next twelve months. Ask each candidate how they would deliver each one, who specifically would do it, how the three relate to each other, and what you own at the end. The answers separate breadth from a brochure quickly.
Then ask about the seams you already have. A partner who asks to see the Tuesday spreadsheet before quoting is describing the work you actually need. Then check the leaving terms, because a relationship you can exit cleanly is one you can commit to comfortably.
About DataDove
DataDove is a London technology partner for growing businesses. The company is DataDove LTD on the Companies House register, number 14989072, incorporated on 7 July 2023. We work across Automation and AI Solutions, the Agentic Legal System and the Agentic Marketing System, Software, Web and Apps, E-Commerce Systems, All-in-One Food EPOS, Branding and Growth, and IT Managed Services, and we build our own products alongside client work, including the Try-On Tool for WooCommerce stores.
The reason those sit together is the seams. Automation is the centre of the arrangement, and each of the other services plugs into it. One partner, fewer moving parts, is a description of that structure, and it is the shape the work takes when the same team holds every piece.
If you are holding five relationships and patching the gaps yourself, start by writing the seams down. Whichever way you go afterwards, that list is the most useful document in the conversation.