A cart owner’s worst day is not a slow one. It is the day the queue forms at 3pm and the thing everyone wants ran out at 2:40. The information needed to avoid that is already sitting in the order history — Kadaikodi’s ambition is to read it forward instead of only backward.
The designed experience is a forecast for the next windows of trade: which hours are likely to spike, which offerings are likely to carry that spike, and roughly how much to prep and staff for. Today the merchant analytics view shows the same shape of truth in the rear-view mirror — peak hours, peak days, daily order trends, top and least sellers — so the forecast is not starting from nothing; it is the same signal projected forward.
Two design commitments are non-negotiable in the specification. First, explainability: a forecast has to be able to say what it is leaning on — “these were your last four Tuesdays” — because an unexplained number is one a shopkeeper will rightly ignore. Second, honest cold-start behaviour: a brand-new cart with eleven orders does not get a confident forecast dressed up as insight; it falls back to plain defaults and says so.
The intended sequence matters too. Forecasts land in the merchant analytics surface and the inventory surface — the two places an owner already goes to make prep and stock decisions — rather than in a separate “AI” tab nobody opens. And they advise; they never quietly reprice or reorder on their own.
Status, stated plainly: this is roadmap. There is no forecast field in the Kadaikodi API today and no model behind it. It is part of the commerce decision engine on the Kadaikodi backlog, which itself waits on the shared multi-model AI runtime the Burdenoff platform is building. What exists today is the historical analytics it will learn from.
Roadmap / target-experience scenario, labelled as such so the vision and the current product are never confused.
Ready to make this your story?
