Most conversations about health technology have a clinician on one side and an engineer on the other. I am useful on a stage because I am on both sides at once, and because I have shipped something real to the professionals I am describing.
I have also been teaching for a decade, which is the part that matters for a room. Tutorial master through pharmacy school in the subjects students most often fail, and still teaching now, guiding candidates through licensing examinations across the RxHustle communities. I am used to an audience that did not arrive already convinced.
That is the healthcare half. I also speak on AI, software engineering and what it actually takes to learn to build, to technical audiences with no particular interest in pharmacy. Conferences, universities, company events, student societies and podcasts all work.
These are the areas I speak in rather than a catalogue of set talks. Each one is written for the room it is going into, so the same theme becomes a keynote for a health conference, a developer talk for an engineering audience or a guest lecture for students. Tell me who is in the room and what you want them to leave with, and I will shape it around that.
Why competent engineers and competent clinicians still ship the wrong product, and what changes when one person holds both sides. Worked examples run from an electronic medical record and a laboratory system to a live pharmacy platform: where governance matters more than features, when approved data should stop being editable, and what a requirements document can never carry across the handover.
Where a model earns its place in a real product and where it is theatre. The worked example is adaptive study inside a clinical education product, but the argument does not depend on healthcare, and the talk is written either way: for a clinical room that wants to know what is safe, or a technical room that wants to know what is real.
An honest engineering story: choosing an architecture one or two people can keep running, the decisions that survived contact with real users, and the ones that did not. Flutter, Firebase, PHP and MySQL, two consumer apps on both stores and a health platform serving thousands of pharmacists, all built without a team to hide behind.
What it takes to carry thousands of professionals through a licensing examination: question banks that hold up under scrutiny, timed practice, adaptive study, and the honest limits of gamification when the subject is clinical competence rather than engagement.
Building for unreliable power, expensive data and slow gatekeepers. Systems designed to keep working offline, direct distribution long before a store listing, and what it looks like to arrive on Google Play with four thousand users already waiting.
A practical case for clinicians and other working professionals who did not study computer science: what to learn first, what to ignore, what it genuinely costs, and how to stay in it past the point where most people quit. Drawn from doing it while practising, and from mentoring pharmacists through it now.
Not on the list? Ask anyway. The only subjects I turn down are the ones I have no standing to speak on, and that is a shorter list than this one.
This page lists what I have actually done rather than what would look good. The teaching record is the long one; the conference record is the one that is still growing.