A competition project is judged on method, novelty, and reasoning. A deployed tool is judged on whether a stranger can use it without help. These are different standards, and clearing the first does not imply anything about the second.
What a research prototype can assume
Clean input data. A knowledgeable operator. A controlled evaluation. Failure modes that can be explained rather than handled. Every one of those assumptions collapses on contact with real users.
What deployment demands
Input validation, because people enter unexpected values. Graceful degradation, because data sources go offline. Onboarding, because nobody reads documentation. Localization, error messages, accessibility, and a plan for the moment the model has no confident answer.
None of this work is novel research, and it consumes more time than the research did.
The honest framing
Our simulation results and our field-validated results are different claims, and we try to say which is which. Overstating readiness is a common failure in student work, partly because competitions reward ambition. Describing exactly what has been demonstrated and what has not is more useful and, ultimately, more persuasive.
The gap is not a flaw in student research. It is the ordinary distance between a result and a product, and naming it is the first step to crossing it.