Somewhere in the next few months a slide will land on your desk with a platform name on it and a number at the bottom that makes your stomach do something interesting. The diagram will be beautiful, the demo flawless, the reference customer delighted. None of it tells you whether to buy, because none of it is about you: a mountain somebody else skied, on a day chosen because the light was good.
The pattern behind almost every expensive platform failure is not a bad product. Most of these products work. Somebody bought a capability and then went looking for a problem to point it at — avalanche kit bought before checking that the only terrain within four hours is a dry slope in Milton Keynes.
The order people buy in, and the order that works
The failing sequence is invisible from inside, because every step in it is reasonable. Somebody credible sees an impressive platform. A workshop, an architecture, a business case assembled around a decision already made. Then, around month five, somebody is asked to find use cases for it.
By the time somebody says “what are we actually going to do with this?”, the right moment to ask was four months and one signature ago.
Invert it. Start with a business question nobody can answer today. Work out what data would answer it, where it lives, who owns it and what state it is in. Decide who may see what, and what you would measure. Only then, when the requirement is uncomfortable in its specificity, ask which architecture serves it and which product implements that.
This is not slower. The work simply sits at the front, where you can see it, rather than at the back where it arrives as delay and an unbudgeted second phase. You choose the run, then the board.
Seven questions, in order
The order matters more than the questions do. Each constrains the next, and the last is the only one most evaluations reach.
| The question | Why it matters | What a bad answer sounds like |
|---|---|---|
| Which business questions can we not answer today? | It is the only test of whether anything needs to change at all | “We want to become data-driven.” |
| What data would answer them? | Turns an ambition into a shopping list you can actually price | “All of it. Bring everything across and we will see.” |
| Where does that data live, and who owns it? | Every source has a human who has to agree, and a system that has to cope | “IT owns the data.” |
| What condition is it in? | Decides whether this is a six-week job or an eighteen-month one | “It is fine, people use it every day.” |
| How should it be governed? | Who may see what, who approves changes, who answers when it is wrong | “We will tidy up permissions after go-live.” |
| What would we measure to know it worked? | The difference between a result and a feeling with a slide behind it | “Adoption. We will report on logins.” |
| What architecture, and then which product? | Last, because everything above it narrows the field for you | “We know which product. We just need the business case.” |
One to four: the question, and the state of the data
A good business question has a decision attached. Not “better visibility of stock”, but “we cannot tell which lines to stop reordering until the quarter closes, so we carry stock we already know is dead” — a decision, a delay and a cost, so it can be priced. Then work backwards to the sources, their owners and their condition, which everyone describes optimistically. That tidying happens whether or not you buy anything: a lake full of raw exports is not a foundation, it is the same mess, centralised.
Five to seven: governance, measurement, then product
Governance asked here is cheap; asked after go-live it is a project. Who may see what, whose approval a new data set needs, what happens when the output is wrong. If you have already had the acceptable use conversation, much of this is done. Then decide in writing what number moves and by how much, and capture it before anything changes, because an unmeasured platform renews on vibes. By question seven, the requirement has ruled out most of the field for you.
How to read a vendor demo
The demo is not dishonest, which is the thing worth understanding about it. It sincerely shows what the product does in perfect conditions, and the conditions are perfect because somebody spent weeks making them so: data clean and joined, definitions agreed, history complete — which yours is not, because at some point you changed how you code something and nobody backfilled it.
The demo shows the product working. It does not show the product working on your data, and the gap between those two is where the entire budget lives.
So change what you ask for. Send an extract of your own data — genuinely ugly, not a tidied sample — and ask them to run the same demo on it. What they had to do to it first, in writing, is your implementation plan. Ask which parts are roadmap, because roadmap should not be priced as present tense.
A pilot proves less than you think
Pilots are good. Run them. Just be precise about what a successful one has proved, because the gap between “it worked” and “we can run this” is where organisations discover they have already committed.
A pilot proves the technology can do the thing, on a narrow slice, with the supplier’s best people in the room and your most enthusiastic staff using it. It almost never tests month-end load, permissions at real headcount, the people who did not volunteer, or the cost curve once usage stops being a controlled experiment — its own expensive surprise.
It is a taster lesson on a nursery slope with an instructor beside you. Passing says you can stand up, not that you are ready to buy the chalet.
So define, before it starts, what result would make you say no. If none exists, you are not piloting. You are onboarding.
The bill after the licence
The quote in front of you is one line of a four-line cost. The other three are absent from it, usually larger than it, and entirely predictable if anyone asks.
- Engineering to build it. Pipelines, models, mappings, the reconciliation logic that makes two systems agree on what a customer is — where the data-condition answer comes back to be paid for.
- Integration into everything else. Every connection is a small product with its own failure modes and its own habit of breaking when the other side is upgraded.
- Running cost that scales with use. Compute, storage, per-user tiers, egress. Success makes this line grow.
- The people who maintain it. The quietest and most expensive of the four: someone has to own it in year two, when the enthusiasm has moved on.
The lift pass is never the cost of the ski trip. It is the flights, the gear, the lessons, the eighteen-euro burger at altitude and the week off work. Everyone knows this about skiing and nobody applies it to software.
Ask for a three-year total including your own people’s time, and hold it against the value of the decision in question one. If the second number is not obviously larger, stop.
How you get back down
Lock-in is not a scandal and is rarely avoidable — depth of integration is what makes a platform valuable. The mistake is accepting it without knowing how much, when you no longer have the leverage to change the terms. Ask these before signature, while you are still interesting to them:
- Where does our data sit, and in what format? Open formats you could read with other tools are a different position entirely from a proprietary store.
- Can we get it all out, in bulk, ourselves? Not “is there an export” — a full extract, on demand, without a professional services engagement.
- What comes out with it? Raw records are the easy half. Transformation logic, semantic definitions, dashboards and access rules are the half that took two years to build.
- What happens when we stop paying, and how may pricing move before then? Retention, deletion, renewal uplift caps, repackaging mid-term.
None of this is aggressive, and a good vendor answers briskly because they have been asked before. The reaction is the signal: you are checking where the way down is before getting on the lift.
You may not need a platform at all
Most evaluation guides skip this, because whoever wrote them has something to sell. So, directly: many organisations asking “which AI platform?” do not have a platform-shaped problem. One core system of record, modest volumes, reports that are late rather than impossible — the honest answer is usually to fix the data quality you already know about, use the automation you have already paid for, and build one narrow assistant on a single source. If that is wrong you have lost a few weeks, not three years and an architecture everything now hangs off.
“Buy nothing yet” is a legitimate output of an evaluation. If your process is structurally incapable of producing it, you were not evaluating.
Which is why it is worth appointing somebody, openly, to argue for doing nothing. Not a cynic — a role. A weak case there proves yours; a strong one has just saved you more than the evaluation cost.
All of which would be smug if the answer were always no. It is not. The signals that your tooling has become the constraint are specific:
- The questions that matter span systems, routinely. Not once a quarter for the board pack — weekly, operationally, by people who then wait days for an answer.
- You need unstructured data alongside the structured record. Contracts, emails, tickets, notes. This is the one that most often makes a genuine platform case, because your existing stack was never designed for it.
- Governance has become the blocker. Permissions do not travel with the data, so the default answer to every access request is no.
Two or three of those, consistently, and you are no longer asking whether to invest but what the smallest architecture is that removes the constraint — question seven, arrived at honestly, with six answers behind it.
Bought in that order, platforms do exactly what they say. Bought in the wrong one, they are the most expensive way yet devised to discover that your item master is a mess. Check the conditions. Pick the run. Then choose the board.
