A demo that works on curated examples is a very different artefact from a feature thousands of people depend on. The gap between them is where most AI budgets are spent and most AI projects quietly stop.
Four things that kill AI features after the demo
Latency
A model that takes four seconds is fine in a notebook and unusable inside a form. Production usually means quantising, caching, or accepting a smaller model that is good enough and fast.
Cost per call
Per-request cost that looks trivial in testing becomes the largest line in your infrastructure bill at volume. This needs modelling before you commit to an architecture, not after.
Failure modes
Every model is wrong sometimes. The question is what happens then. A wrong suggestion the user can ignore is fine. A wrong value silently written to a record is a data integrity problem you will be unpicking for months. Design the interface so mistakes are visible and recoverable.
Trust
Users abandon a feature that has embarrassed them. Confidence indicators, an obvious correction path, and conservative defaults early on buy the goodwill you need while accuracy improves.
Ask whether it needs ML at all
A surprising number of problems presented as machine learning are better served by rules. Rules are explainable, testable, cheap to run and easy to correct. If a domain expert can write down the logic, write down the logic.
Machine learning earns its place when the rules are genuinely unknown, when they change faster than you can maintain them, or when the input is unstructured — images, audio, free text.
Ship the smallest useful version
Put a narrow, well-scoped model in front of real users early. Real usage reveals the edge cases that no test set contains, and it tells you whether the feature is wanted before you have spent the whole budget proving it works.