$ loadingLoading
$ loadingLoading
about
I work across models, backends, desktop and mobile — and I care most about the part everyone skips: getting the thing to run somewhere real, on the hardware that is actually available.

I build systems end to end. That means the model, the service that carries it, and the interface someone actually opens — PyTorch through to ONNX, an API in front of it, then a Flutter build on a phone or an Electron app on a desktop. Projects tend to break at the seams between those layers, so I made a point of being useful on both sides of every seam.
What I optimise for is deployment, not the leaderboard. A model that needs a stable connection, a spare GPU and its author in the room has not really shipped. So the constraints go in first: run offline, fit the device, fail in a way a person can read, and stay simple enough for someone else to maintain.
I am in the final year of a BSc in Computer Science at St. Joseph University in Tanzania, graduating in 2026. The degree gave me the fundamentals. The rest came from building things that had to survive being used by someone who did not write them.
Since March 2025 I have been a machine learning intern at the Emerging Technologies for Healthcare (ETH) Lab at Muhimbili University of Health and Allied Sciences, here in Dar es Salaam. Healthcare is an unforgiving place to learn deployment: clinics lose connectivity, a prediction has to be explainable to the clinician reading it, and data arrives from several institutions in several shapes. The work there covers imaging classifiers, explainability, and the preprocessing pipelines underneath them.
Outside the lab the problems look nothing like that, which is the point. My own projects include a desktop tutor that runs on whichever model you bring it — hosted or local — and an agent that diagnoses a broken machine and knows exactly where to stop and hand over to a person. Different domains, same question every time: what happens to this once it leaves my machine?
I work from Dar es Salaam, in English and Swahili. I work remotely with teams in any timezone, and I am open to relocating for the right role. The problems that interest me are the ones where the constraint is the interesting part — small hardware, no network, a decision that has to be defensible to whoever it lands on.
// 01how i work
Not a methodology. Just the decisions that separate a system that survives contact with the field from one that only ever ran on a laptop.
A result that only reproduces on my own machine is a draft, not a system. I take it the rest of the way — export, service, interface — because the last stretch is where the real constraints show up.
Connectivity is a dependency like any other, and it is usually the first one to fail. Where it matters I move inference onto the device, so the tool keeps working when the network does not.
A system allowed to do anything will eventually do the wrong thing. I define the scope an agent may act inside as part of the architecture, and route everything beyond it to a human.
The first version always fits the problem it was written for. I keep data, model and interface separable, so the next case is a swap rather than a rewrite.
the short version
The CV covers the same ground in a single sheet — the degree, the internship, the stack. If you would rather just ask, the contact page reaches me directly.
PDF · Isaack_Joshua_Lukumay_CV.pdf