Another Login, Another Invoice: A Buyer's Framework for UK Software Stacks
Photo: TheAHL, CC BY 2.0, via Wikimedia Commons
Every quarter brings the same meeting. A vendor has demonstrated something genuinely impressive, the team that wants it is enthusiastic, and the quote is small enough to approve without a board paper. Six months later the licence sits alongside three tools doing broadly similar work, the integration project has stalled, and nobody can say who owns the data inside it.
This is stack creep, and in UK mid-market businesses it is rarely the result of bad judgement. It is the result of good decisions made in isolation. The framework below is designed to be applied in a single session, before a pilot is signed off or a renewal is waved through, and it is deliberately blunt.
Stack creep is a budget problem before it is a technology problem
Software spending rarely spikes. It ratchets. Each tool arrives with a plausible business case attached, and each one adds a line to the finance system that nobody later feels responsible for removing. Research from the major SaaS management vendors has consistently put the share of unused licences somewhere between a quarter and a third of total seats, and UK organisations are not an exception.
The more corrosive cost is not the subscription. It is the fragmentation of process. When a customer query can be answered from four different systems, the answer depends on who picks up the ticket. When a report has to be stitched together from three exports, it arrives late and gets trusted less.
Question one: which two tools does this replace?
If the answer is none, treat that as a warning rather than a justification. Genuine net-new categories do exist, but they are rarer than the pitch decks suggest. Ask the sponsor to name the incumbent systems whose usage will fall, and ask for the number of seats that will be surrendered at the next renewal.
A useful discipline is the overlap audit: take the five workflows the new tool touches and list every existing system already involved in each one. If a workflow already has four tools in it, adding a fifth is unlikely to be the constraint the business is actually feeling.
Question two: who actually owns the data?
Procurement teams are now reasonably good at asking about data processing agreements and sub-processors. They are less consistent about asking who holds the master record. If the new platform becomes the system of record for customer contact details, contract dates or pricing, that is a material commitment and it should be documented as such.
Two practical tests apply. First, can the data be exported in a structured format, on demand, without a professional services engagement? Second, if the contract ends in eighteen months, what does the business look like on the day after termination? Any answer involving the phrase 'we would work something out' should be treated as a no.
Question three: what will integration really cost?
The subscription is the visible number. The integration is the one that breaks the business case. Ask for the specific named systems the tool must connect to, who builds each connection, and whether that work is included or chargeable.
Be equally direct about maintenance. APIs change, authentication methods are retired, and middleware licences expire. A tool that requires a bespoke connector to the finance system carries an ongoing liability, not a one-off cost.
Question four: what is the price of one more login?
Context switching is difficult to cost but easy to observe. Count how many separate systems a typical employee in the affected team signs into on a normal day. If the number is already above ten, the marginal tool is competing for attention rather than adding capacity.
Single sign-on and directory integration reduce friction, but they do not remove it. A tool behind SSO is still another interface, another notification stream and another place where work can hide. Where possible, favour tools that surface inside the environment people already occupy rather than requiring a deliberate visit.
Question five: how do we leave?
Exit terms are negotiated at the point of maximum leverage, which is before signature. Insist on a defined notice period, a documented offboarding process and deletion certification. For anything holding personal data, map the obligation against UK GDPR requirements, including the Article 28 processor terms and the retention schedule agreed with your data protection lead.
A scoring sheet you can use in the meeting
Score each criterion from one to five, multiply by the weight, and total. Below roughly 55 out of 100, the proposal should return to the sponsor rather than proceed to pilot.
| Criterion | Weight | What a five looks like |
|---|---|---|
| Overlap clarity | 20 | Two named incumbents lose seats at renewal |
| Data ownership | 20 | Full export, clear deletion terms, documented record status |
| Integration burden | 20 | Standard connectors, no bespoke build, maintenance included |
| User friction | 15 | SSO plus in-workflow surfacing |
| Exit route | 15 | Reasonable notice, tested offboarding, deletion certificate |
| Total commercial value | 10 | Payback inside twelve months, evidenced |
Running the test without slowing the business
The objection to frameworks of this kind is always pace. In practice, the five questions take less than an hour to answer if the sponsor has prepared properly, and the preparation itself is clarifying.
It also changes the conversation with vendors. Suppliers who can answer the overlap question and the exit question without hesitation tend to be the ones worth keeping. Those who cannot have told you something useful before the pilot begins.