Sort your AI feature list before anyone quotes a launch date

Somebody has written you a feature list with AI on it. Automatic summaries. A chatbot. Recommendations. Detection of the customers about to leave. Predictions of who will do well and who will struggle.

It reads as one list, so it gets quoted as one timeline. It is not one list. It is two, and they behave nothing like each other.

The split

Some AI features can be tried from the start, because the model already arrives with most of what they need. It has read enough invoices to attempt pulling a total off yours. It has read enough French and English to move between them. It has seen enough writing to summarise a meeting, draft a reply, or sort incoming messages into three buckets from a handful of examples. None of that needs months of your own data. It still needs testing: run it on a few hundred of your real documents, in your languages, check the fields you depend on, and work out what it costs per document before you promise it at launch.

The rest need something no model has: your history. A recommender trained on how your customers behave has to see how they behaved before. A churn score has to know which of your customers actually left. Spotting the account heading for trouble means knowing what trouble looked like the last ten times. The model has read most of the internet and has never seen a single one of your customers.

Not every version of those features needs that. A first recommender can work from your catalogue and the preferences a customer states when they sign up. And if an older system already holds usable history, the second list may be shorter than it looks. The question is whether the approach you choose has the data it needs, not whether the new platform has already run for months.

Earlier this year we scoped a platform whose brief carried nine distinct AI features, some from the first group and some from the second, all presented as launch features. The note we wrote for ourselves before responding was blunt about the predictions, such as which students would struggle and how they would perform: those are not interface features, they are models that need historical usage data which does not exist until the platform has run for a while. The phasing we proposed put them last, gated on the earlier phases producing enough real usage to learn from. The client accepted that phasing on the call.

The test to run on your own list

Take each AI feature and ask one question. What must this have seen before, in order to be right?

If the answer is "examples of this kind of thing in general", it is a candidate for launch, once it passes a test on your own material. Invoices, contracts, messages, photographs of receipts: the world is full of those and the model has already read them.

If the answer is "what happened to us, and how it turned out", it is not. Notice the second half of that sentence, because it is the half that gets missed. Recording that something happened is not enough. You need to have recorded how it ended.

Most systems log events. A delivery was assigned. An invoice was sent. A student booked a lesson. Check whether yours also stores the outcome beside the event: the delivery arrived forty minutes late, the invoice was never paid, the student stopped coming in week three. A model that predicts outcomes can only learn from outcomes. Log events alone and you can run for two years and still have nothing to train on.

What to do with the two lists

1. Sort the list before anyone quotes a date. Do it with whoever is building. Every feature that needs history you do not have yet leaves the launch scope now, unless a simpler first version can run on the data you do have. Better now than in month seven, when someone opens the table and finds it empty.
2. Start with the features that do not need your history. Test them on your own inputs, check quality and cost, then ship the ones that pass. They are what gets the product used, which is what produces the history the others need.
3. Record outcomes from the first day. This is the cheapest item here and the one that cannot be done later. For every decision the system makes, store what it decided, when, and what happened afterwards. Designing outcome capture in from the start is usually far easier than reconstructing it later. A year of history you did not keep cannot be bought back.
4. Set the trigger as a number, not a date. "Revisit when we hold 5,000 completed orders with outcomes" is a plan. "Phase 3, second quarter" is a guess about a calendar.
5. Budget the running cost. A model call is charged every time it runs, for as long as the feature exists. It is not a one-off build cost, and it grows with how well the product does. For work that runs constantly, it can pay to keep the routine volume on a model you host yourself and send only the hard cases to a paid API, if the local model's quality, running effort and total cost hold up when you measure them. We run a local model on our own hardware for internal work for this reason.
6. Decide what the feature does when the model is unreachable. We built an internal tool that checks text for sensitive data before it leaves the browser. Plain pattern matching catches emails, card numbers and API keys. It cannot reliably catch a person's name, so that one step asks a model we host ourselves. When that model cannot be reached, the tool says so in plain words. It never returns a clean result, because "I could not check" and "there was nothing to find" look identical on screen and only one of them is safe to act on.

There is a quieter version of the same problem waiting on the second list, and it is not about data at all. A recommendation engine with nothing to recommend is not a cold model, it is an empty shelf. A marketplace that opens with no sellers is a dead demo with or without AI on top of it.

What this does not fix

Sorting the list does not make the second group cheaper or certain. A year of recorded outcomes can still turn out too thin, or kept in a shape nobody can use, and you usually discover that at the moment you try. Phasing buys you an honest launch date and a fair chance at the rest. It does not guarantee the rest.

What it does prevent is the ordinary failure: every feature quoted on one timeline, the ones that need history found out late, and nothing recorded in the meantime to make them possible even then.