Blog

The hidden cost of vendor-led advice

---

An agency that builds websites will tend to find that you need a website.

I want to be careful about how that lands, because it is not an accusation. It is a description of how expertise works. People recommend what they know how to do, and they know how to do it because they have done it many times, and they have done it many times because they are good at it. The recommendation is usually sincere.

It is also, structurally, not independent. And the gap between those two things is where a great deal of money goes.

I spent two decades running a digital agency, so I have given this kind of advice as well as received it. I do not remember a single occasion on which anybody set out to mislead a client. I remember plenty where the answer we gave was shaped by the shape of the business giving it.

Where the cost actually sits

The obvious version is the unnecessary project. Somebody buys a rebuild when they needed a fix. That happens, and it is expensive, but it is not the largest cost.

The larger costs are quieter.

The question that never got asked. A supplier engaged to solve a problem will solve that problem. They are much less likely to ask whether the problem is worth solving, whether it is a symptom of something upstream, or whether the organisation would be better off doing nothing this year. Those questions do not sit naturally with anybody whose revenue depends on the answer.

The option that was never on the table. You get a choice between the three things the supplier does. The fourth thing, which might have been the right answer, was never mentioned because they do not do it. You cannot evaluate an option you were not shown.

The scope that grew because nobody was measuring it. Over a long enough contract, in a relationship where one party knows the craft and the other does not, effort drifts upward. Not through bad faith. It happens because nobody on either side has a reason to interrogate it, and because everyone stays perfectly friendly throughout.

The dependency nobody priced. This is the big one, and it is getting bigger.

Why AI has made this sharper

Every organisation signing an AI contract this year is making a portability decision, and most of them do not know it.

Traditional software lock-in was about data. Painful, but broadly understood, and there was usually an export button somewhere. What is happening now is different in kind. Your team's accumulated knowledge, your processes, your customer history and increasingly your institutional memory end up inside one supplier's system, in a form that only makes sense inside that system.

At that point the question stops being whether the tool is any good. It becomes what your negotiating position looks like in three years when the pricing changes and you have nowhere to go.

The advice you get about this will almost always come from somebody selling one of the tools. That is not a conspiracy. It is simply where the expertise currently sits, and it is why the question needs asking by somebody outside the transaction.

So ask before you sign. What exactly can we take with us, in what format, and has anybody actually tested that the export works? The third part matters. I have seen more than one export function that technically existed and produced something unusable.

The test I would apply to any recommendation

Not a process. One question, asked quietly, about whoever is giving you advice.

What would this person have to say for you to know they were being straight with you against their own interest?

If the honest answer is that no such sentence exists in their commercial position, you are not receiving advice. You are receiving a proposal, which is a different and perfectly legitimate thing, but it should be evaluated as one.

A good supplier can pass this test. Some of the best people I worked with in agency life would tell a client to spend less, or to wait, or to fix the thing themselves. It cost us revenue and won us relationships that lasted years. But it was a choice they made against the grain of the business, and you cannot build a governance process on the assumption that every supplier will make it.

What this does not mean

It does not mean suppliers are the problem. Most of the good work I have seen delivered was delivered by agencies and vendors who knew their craft far better than the client ever would. Doing everything in-house is usually worse and always slower.

It does not mean you need an independent adviser for every decision. Most decisions are small enough that the cost of scrutiny exceeds the risk.

And it does not mean independence is a personality trait. It is a structural condition, and it can be checked. Does this person sell software. Do they hold reseller agreements. Do they take commission from a platform. Do they have an implementation team that needs filling next quarter. Those are factual questions with factual answers, and anybody who bristles at being asked them has told you something.

Where I sit

I have no software to sell, no reseller agreements, no platform commissions and no delivery team that has to be kept occupied. That is deliberate and it is the whole basis of how I work.

I do sometimes deliver focused pieces of work, which means the obvious question applies to me too. So I hold to a rule: I will not automatically accept delivery work that follows from a recommendation I was paid to make. If it goes ahead, the client has been shown reasonable alternatives, the distinction between advice and delivery is explicit, they understand the potential conflict, they choose, and the decision is recorded in writing.

That rule exists because the alternative is exactly the structure I have spent this article describing. It is easy to be independent in principle. The test is what happens when there is a delivery contract sitting on the table at the end of a piece of advice you were paid to give.

---

If you are relying on a supplier for advice about that supplier's own work, an independent supplier review gives you an objective view of what you are getting and what it is worth.

---