Skip to content
Technology strategy 22 July 2026 2 min read

Before you buy the platform, write the requirement

Vendors demonstrate against their own strengths. Without a written statement of what the system has to do, procurement becomes a contest of presentations rather than of fit.

By MambaTech

A firm decides it needs a new system. Three vendors are invited in. Each demonstrates well, because each is demonstrating the part of its product it is proudest of, against a scenario it chose. The team forms preferences. The decision gets made on which presentation was most convincing, and the requirement, if it is ever written down, is written afterwards to justify the choice.

This is not anybody behaving badly. It is what happens when the buyer has not said, in advance and in writing, what the system has to do.

Write it before you look

The document does not need to be long. It needs to be specific, and it needs to exist before the first demonstration.

  • The outputs. What must come out of this system, in what form, for whom, and how often. Reports a regulator expects. Documents a customer receives. Figures the board reads.
  • The inputs it must accept. What you already hold, in the format you already hold it. This is where migrations get expensive, and it is almost never covered in a quote.
  • The rules that cannot bend. Where data may be stored. Who may see what. What must be logged, and for how long it must be kept.
  • The volumes. Not this year’s, next year’s. A system sized for the average fails at the peak, and the peak is when it matters.
  • What happens when you leave. How the data comes out, in what format, at what cost. Ask before signing, because after signing it is not a negotiation.

Then compare like with like

With the document in hand, evaluation changes. Every vendor answers the same questions. The gaps become visible, because a gap is now a line in a document with no answer beside it, rather than a topic that was never raised.

The comparison also widens beyond licence cost, which is usually the smallest number in the decision. Migration effort, configuration, training, the internal time to run it, and the cost of getting out again are all larger, and all knowable in advance if somebody asks.

The uncomfortable outcome

Sometimes the requirement, once written, turns out to be met by the system the firm already owns and has never fully configured. That is a good result and an awkward conversation, because a project has usually acquired momentum by then.

We take no commission from any vendor, which means we have no stake in that conversation going one way rather than the other. If the answer is to spend nothing, we would rather say so early, while it is still only awkward.

Filed under procurement vendor selection architecture
Related capability

Technology strategy and architecture

Decide what to build, what to buy and what to leave alone, before anyone spends money. The target state written down, with the order of work argued for.

Have this problem?

A diagnostic traces one operational cycle end to end and gives you a written map with the friction ranked by cost. Fixed scope, no obligation to proceed.