Build one use case before you talk about a platform

Imagine an owner who lays out the list at the first meeting: a company AI platform with a knowledge base, automatic quotations, a customer-service bot, management reports and contract review — ideally all live within six months.

Every item on the list makes sense. Together they make a high-risk project. Our advice is usually the same: pick one use case, finish it properly, and only then talk about a platform.

Three traps of the big platform

The requirements are imagined. A team that has never used an AI system finds it hard to say precisely what it needs. The longer the list, the more of it is "others have it, so we should too". Only once the first use case is running does anyone learn which features get used every day and which merely sounded good.

By the time you see anything, it's too late. A six-month platform often produces its first usable version in month four or five. If the direction was wrong from the start, that is when you find out — and when changing course costs the most.

The team is asked to change too much at once. Replace the way you quote, the way you answer customers and the way you report in the same month, and the one thing the front line learns is how to complain. The new system loses its users before it has had a chance to prove itself.

How to choose the first use case

Choosing the first use case matters more than choosing features. We look for four things:

• it happens every day, not once a month;
• it hurts but can't kill — mistakes can be caught and fixed by hand;
• one named person is responsible and willing to spend fifteen minutes a week on the results;
• the result can be counted: time, number of errors, speed of reply — any one will do.

Imagine an interior design firm where a designer spends half a day compiling the materials list for every proposal. It happens daily, errors can be checked by hand, the design lead is willing to own it, and the time can be measured. That makes it a good place to start — far better than "a knowledge base for the whole company".

What "finished" means

Plenty of projects open five features at once and take each to seventy per cent. Progress looks healthy; in practice none of them can be relied on.

A use case is finished when four things are true together: it works end to end, from input to output; someone uses it every day, not just in demos; when it goes wrong, everyone knows who deals with it; and there's a number showing it was worth doing. Miss one, and it isn't finished.

Platforms grow

A finished first use case leaves behind some unglamorous things: cleaned-up data, sorted-out permissions, a habit of people reviewing what the AI produces. The second use case reuses all of it and comes together much faster; the third, faster still.

A real platform usually takes shape on its own after the third or fourth use case — and its shape is rarely the one drawn on day one, because by then the requirements come from use rather than imagination.

Phasing protects you, too

Whoever builds it, we'd suggest cutting the project into stages, with a point at the end of each where you can decide to stop: what did this stage achieve, and is the next one worth doing? It isn't a matter of distrust. It makes sure every dollar you put in rests on the actual results of the stage before, not on what everyone imagined on day one.

Build one use case first. The platform will grow once you've used your way to its shape.