Here is something nobody tells you when you start building ML tools for healthcare: the model is the easy part. You can get a classifier to 95% accuracy in a weekend. Getting a nurse to open your app on a Monday morning — that takes months. And if you are building in a setting where the dataset is small, the internet drops out twice a day, and there is no regulatory template to tell you how to handle a photo of a child's back, then every layer of the stack becomes a design decision that most tutorials never cover. This talk is about those decisions. I built a Python-based platform that screens for adolescent scoliosis :a spinal condition that affects 2–3% of adolescents worldwide and goes largely undetected in countries without routine school screening. The spine is the domain. But the talk is really about the engineering: how do you build clinical ML tools in Python when the usual assumptions about data, infrastructure, and user trust do not apply? Training on small data When your labelled dataset is measured in hundreds, not millions, end-to-end deep learning is not your friend. I paired a DenseNet121 feature extractor with a classical SVM classifier and it consistently outperformed the fully end-to-end alternatives. I will walk through why, show the PyTorch code, and offer a simple decision framework for choosing between deep features plus classical ML and pure deep learning so you can make that call on your own project without guessing. Learning to measure what clinicians measure Screening is a yes-or-no question. Measurement is harder. A ResNet50 with a regression head predicts Cobb angles the standard way clinicians quantify how much a spine curves to within 3.4 degrees of error. That is inside the range where two radiologists looking at the same X-ray will disagree with each other. I will cover the loss function, the augmentation choices that actually helped, and the ones that just added noise. Designing for infrastructure that fights you The monitoring component runs on an ESP32 microcontroller with an MPU-6050 accelerometer, programmed in MicroPython, pushing posture data over MQTT to a FastAPI backend. That sentence sounds clean. The reality is not. I will talk about what offline-first design actually looks like when your device loses signal for hours, reconnects with a backlog, and the server needs to make sense of it all without dropping data or duplicating it. Privacy when there is no playbook The platform processes images of children's backs. Those images never touch disk — they are held in memory, analysed, and discarded. I will show the FastAPI patterns that enforce this and talk about the harder question behind them: how do you make privacy-by-design decisions when there is no local regulatory framework telling you what the right answer is? Earning trust, not just accuracy This is the section I wish someone had given me a talk about before I started. A model can be accurate and still be useless if the person on the other end does not trust it. I will share what it actually took to get clinicians to engage with the system — and why pydantic for data validation, pytest for regression testing, and MLflow for experiment tracking turned out to matter more to adoption than the model architecture ever did. Who this talk is for You are an intermediate Python developer. You have trained a model in a notebook. You have written a FastAPI endpoint or two. Now you are trying to turn that into something a real person will rely on — and you are starting to realize that the gap between a working model and a working product is wider than anyone warned you. If on top of that, you are building in a setting where data, infrastructure, or institutional trust cannot be taken for granted, then this talk was written for you. What you will leave with A practical decision framework for choosing between classical ML on deep features and end-to-end deep learning when labelled data is scarce. A reference architecture for privacy-sensitive, offline-capable clinical tools in Python — from model training through deployment. A set of concrete engineering practices around data contracts, testing, and experiment tracking that proved more important to real-world adoption than model performance. An honest picture of what it takes to move from a notebook to a setting where someone's health depends on your code. Outline with time estimates Content 0:00 – 3:00 Opening The gap between tutorial-world and the real world. What this talk covers and why. 3:00 – 6:00 The problem Scoliosis, the screening gap, and why this is a tooling problem disguised as a medical one. 6:00 – 12:00 Small dataDenseNet121 + SVM. The hybrid decision framework. Code walkthrough. 12:00 – 17:00 MeasurementCobb angle regression. Loss design, augmentation, clinical-grade accuracy. 17:00 – 21:00 Infrastructure and privacy Offline-first IoT. In-memory image processing. Building without a regulatory template. 21:00 – 25:00 Trust The tooling that mattered. What getting a clinician to use the system actually looked like. 25:00 – 28:00 Takeaways Four lessons that transfer beyond healthcare and beyond the spine. 28:00 – 30:00 Close and Q&AWhere this work goes next. Questions. Why this matters at PyCon Africa Most clinical ML talks at Python conferences come from well-resourced labs with large datasets and stable infrastructure. The engineering constraints in African healthcare settings are different smaller data, unreliable connectivity, clinicians using ML tools for the first time, and privacy norms still being written. Those constraints force different design choices. Those choices deserve a stage. PyCon Africa is that stage.