I build to understand. Not to delegate.
The fastest way to have a real conversation with an engineer is to have shipped something yourself. The fastest way to earn a clinician's trust is to have treated patients. Most people in AI leadership have one or the other. This lab is part of how I stay current on both.
Projects
Privacy-Preserving Personal Health AI AgentPersonal health · Published on Zenodo · DOI: 10.5281/zenodo.18134985+
Designed and built a local-first AI agent that keeps personal health data entirely on-device. Went hands-on with privacy-preserving architecture, not to read about it, but to understand the tradeoffs from the inside. The patterns directly inform how I think about data sovereignty in clinical AI deployments.
View on Zenodo →Garden WhispererAI garden maintenance tool+
Built a multimodal AI tool that identifies plants, diagnoses problems, and generates location-aware seasonal maintenance plans from a photo. The clinical application is irrelevant. The exercise in multimodal reasoning, context injection, and non-clinical user experience design was not.
Windermere Seismic Home Assessment GPTLocation-specific risk tool+
A GPT that generates seismic risk assessments for residential properties based on location, construction type, and local geological data. Built to make technically dense risk information accessible to people without a geology degree. Same challenge as clinical AI: translating expert knowledge for non-expert decisions.
Scholar AssistSAT prep AI+
An adaptive AI tutoring tool for SAT preparation. Built to get hands-on with personalized learning outside of healthcare, where the stakes are lower and the iteration cycle is faster. Tested prompting strategies that have since shown up in clinician-facing tools.
Small Language Model ExplorationPlatform research+
Hands-on work with small language model architectures, understanding what they can and can't do on constrained clinical tasks, and what deployment looks like outside cloud-dependent infrastructure. Built because the answer wasn't in a paper.
Why This Exists
Staying hands-on is a choice. The further you move into leadership, the easier it is to stop building and start delegating. These projects exist to make sure that doesn't happen, so that every conversation, whether it's with a clinician, an engineer, or a product team, is grounded in something real, not just experience from a few years ago.
Leadership that stays technical doesn't happen by accident. These projects are part of how I stay close to the work, the same instinct behind the solo patents, the published research, and the 0-to-1 builds. Curiosity doesn't stop at the job description.