I have been a mobile engineer for twelve years. Android, then Kotlin Multiplatform, then native Rust modules for the parts where the platform SDKs are not fast enough. I have shipped apps used by millions at Sky, MGM, WWE and BritBox, and I teach this work to 20,000+ students on Udemy. By most measures, I am established in my field.
So this is the post where I admit I am starting over, in public, in a discipline where I am a beginner: machine learning.
This is the first part of a series I am calling From Mobile to AI/ML. It is a learning log, not a tutorial series from an expert. I am writing it for two reasons. First, writing is how I learn, and committing to publish is how I keep going. Second, there are a lot of mobile engineers right now wondering whether the move into AI is worth it, how to do it without throwing away what they already know, and what it actually looks like day to day. I am one of them, and I would rather show the work than sell a course on it.
This post is the hub of the From Mobile to AI/ML learning-log series(new parts as I go):
Why not just stay in mobile?
Mobile is not going away. Every AI feature eventually has to run on a phone, a watch, or a TV, and the engineers who can ship it there are scarce. I am not leaving mobile. I am extending it.
The honest version is that the interesting problems have moved. Five years ago the hard part of my job was keeping a streaming app alive across Android fragmentation and a fragile media stack. Today the hard part, for me, is the AI layer: what runs on the device, what runs in the cloud, how you keep a model inside a battery and thermal budget, and how you ship an LLM feature that does not bankrupt the company on the first day of traffic.
I already build production LLM features for companies. Tool calling, retrieval-augmented generation, cost control, evals. That work taught me the applied end of AI, the engineering around models. What I have not done, and what this series is about, is the core: training, fine-tuning, the maths underneath it, and the full MLOps stack. That is the gap I am closing.
Why a mobile background is an asset, not a restart
There is a tempting story that moving into ML means starting from zero. It is wrong, and believing it is the fastest way to quit.
The things I already know well are the things that make AI features fail in production, and that most ML engineers have to learn the hard way:
- Latency and memory budgets. A model that runs in 200ms on a laptop can take 4 seconds on a mid-range Android phone and drain the battery doing it. I have spent a decade profiling exactly this.
- Cross-platform shared logic. The same inference often has to run on Android and iOS. Kotlin Multiplatform and Rust are how I already solve “one implementation, two platforms.”
- Shipping under constraint. Regulated betting apps do not get to ship a feature that is 80% correct. I know what it costs to ship something that has to hold up.
The part I do not know is the ML itself. The calculus, the model architectures, the training loops, the evals that are not just vibes. That is what the roadmap below is for.
The roadmap
I am following six phases. They are sequential, not pick-and-mix, because the foundations are what let you debug everything above them. I am marking them honestly: what I have done, what I am doing now, and what comes next. The full version with resources lives on the AI/ML journey page.
Phase 0, Foundations (in progress). Linear algebra, calculus, and probability, the parts you actually need, not a four-year maths degree. Python, NumPy, and a reproducible setup. This is the unglamorous part and it is where I am spending the most time right now, because everything later assumes it.
Phase 1, Classical ML. scikit-learn, regression and classification, feature engineering, cross-validation. The goal is to build intuition for what a model is doing before touching a neural network.
Phase 2, Deep learning. PyTorch, tensors and autograd, CNNs and transformers. Fast.ai and the Deep Learning Specialisation. This is where the maths from Phase 0 pays off.
Phase 3, LLMs and applied AI. Transformers in detail, fine-tuning, RAG, tool use, and the engineering around the major APIs. I am partly here already from production work, but I want the fundamentals, not just the API calls.
Phase 4, On-device and edge ML. This is my edge. TensorFlow Lite and Core ML on Android and iOS, on-device inference with Rust and Kotlin Multiplatform, quantisation and model compression. The intersection of everything I already know with everything I am learning.
Phase 5, MLOps and shipping. Model serving, monitoring, drift, CI/CD for ML, experiment tracking. Closing the loop by shipping an AI feature end to end.
What to expect from this series
One post per phase milestone, roughly. Not a fixed cadence, because learning is not fixed cadence, but I will publish when I have something real to show: a project that ran, a concept that clicked, or a place I got badly stuck and how I got out.
I am not going to pretend the early posts are impressive. The first real project will be a scikit-learn model on a Kaggle dataset, and I will write about it honestly, including the parts that felt obvious in hindsight and were not at the time. If that is not useful to you yet, the Rust + NDK on Android series is still running, and the on-device ML posts later in this series are where the two tracks meet.
If you are a mobile engineer thinking about the same move, the mentoring page is open, and I will add a dedicated AI/ML track once I am further along. For now, the best way to follow is the RSS feed or YouTube.
The next post will be from Phase 0: the maths I actually needed, and the parts I skipped.
Loading comments…