A trained model in a Jupyter notebook and a working product are two different things that get talked about like they're the same thing. The notebook proves the idea works. Everything after that, the part nobody puts in a portfolio screenshot, is where most of the actual engineering happens.
I learned this building SymptoCare, a disease prediction app that takes a user's reported symptoms and returns likely conditions, with a path to talk to an actual doctor if needed. The model itself, a Random Forest classifier, was the easy part in hindsight. Getting it into something a real person could safely use was the project.
The model needs a home that isn't your laptop
A pickled model file sitting on your machine helps no one. It needs to be served somewhere reachable, which means wrapping it in an API. I used FastAPI for this, hosted on Hugging Face Spaces, with the trained model itself stored on Google Drive and loaded at runtime. This sounds simple in a sentence and wasn't simple in practice, model loading time, memory limits on free-tier hosting, and making sure the API stayed responsive under real requests all needed actual attention, not just a working predict function.
Predictions without context are dangerous
A model that spits out "72% likely to be condition X" without any framing is a liability in a healthcare context, not a feature. Part of the build was making sure predictions came with enough context that a user wouldn't mistake a probability for a diagnosis. This is also why the "Talk to a Doctor" tab exists at all. A prediction is a starting point for a conversation with a professional, not a replacement for one, and the product needed to make that boundary obvious rather than implied.
Authentication is not optional for health data
Anything touching personal health information needs real access control, not an afterthought bolted on before launch. JWT-based authentication, paired with a proper database, meant user data and prediction history stayed tied to actual authenticated sessions rather than floating around unsecured. It's the least exciting part of the build and the part you cannot skip.
A chatbot is a UX decision, not a gimmick
Adding an AI-powered chatbot wasn't about ticking a feature box. Symptom description is awkward through a rigid form, most people don't think in structured fields, they think in sentences like "my stomach's hurt since yesterday and I feel dizzy." A conversational layer that can turn that into structured input for the prediction model closes the gap between how people actually describe how they feel and what a model needs to make a prediction.
The real takeaway
Every one of these pieces, hosting, authentication, UX for input, framing for output, existed because a raw prediction isn't a product. The model accuracy number is what gets discussed in a portfolio review. The parts that actually determine whether real people can use the thing safely are everywhere else.