M.K.
I build at the intersection of med-tech, research, and content — less portfolio, more field notes from someone who reads signal traces for fun.
This page is M.K.: my story, the nerdy metadata, and how I actually operate. Jump below if you only have thirty seconds.
// edit this block with your real story when ready
draft.voice
I think in systems, prototype in code, and explain in public — med-tech because the stakes are real, content because teaching is how I learn, research because rigor is the only moat that compounds.
Chapters
Five beats — scroll through, or jump here if you already know the headline.
01 — Origin
I didn't set out to work in med-tech. I set out to understand systems — biological, technical, organizational — and kept finding myself at the intersection where those systems fail people.
Early on, I learned that the gap between what medicine promises and what infrastructure delivers is not a knowledge problem. It's a build problem.
02 — Going Deep
I went deep on the hard parts: signal processing, data pipelines, validation workflows, the unglamorous infrastructure that makes clinical tools trustworthy.
Code was never the destination. It was the instrument — a way to test hypotheses, ship prototypes, and learn faster than reading alone allows.
03 — Building in the Open
Entrepreneurship, for me, is not about startups as identity. It's about seeing a process that's painful when it doesn't have to be, and choosing to fix it.
I've worked across stealth builds, open-source tools, and research collaborations — always with the same filter: does this make the next person’s work easier or harder?
04 — Med-Tech Lens
Med-tech sits at the edge of what's possible and what's regulated, what's humane and what's scalable. That tension is where I do my best work.
I'm drawn to problems where a wrong abstraction costs more than a delayed launch — where rigor isn't optional and creativity isn't decorative.
05 — Now
Today I'm focused on research-grade tooling, clinical signal infrastructure, and the connective tissue between lab bench and real-world deployment.
This site is where I document that work — not as a personal diary, but as field notes for anyone building in the same direction.
Resume
Patents and publications from Google Scholar — experience and skills are yours to extend in mk-page.ts.
scholar.profile
The Bronx High School of Science / Neuroscience Dept, Columbia University / NIURA
sourced from Google Scholar · in-ear EEG / neurotech
Charging and processing case for wireless earbuds with in-the-ear electroencephalography implementation
R Ahmed, S Huda, A Das, S Rajapaksha, M Shrestha, A Karim, C Kan, …
US patent application · US Patent App. 18/459,379 · 2023
Earbud apparatus with integration of real time in-the-ear electroencephalography and electrode port that can simultaneously play audio via speaker housing
RF Ahmed, S Huda, A Das, S Rajapaksha, M Shrestha, A Karim, C Kan, …
US patent application · US Patent App. 18/452,526 · 2024
Electrode system for rubber ear tips with conductivity from n-doped silicone or conductive filaments in mixture for electroencephalography
RF Ahmed, S Huda, A Das, S Rajapaksha, M Shrestha, A Karim, C Kan, …
US patent application · US Patent App. 18/454,063 · 2023
In-ear electroencephalography electrodes with multi-parameter vitals monitor connectivity
RF Ahmed, S Huda, A Das, S Rajapaksha, M Shrestha, A Karim, C Kan, …
US patent application · US Patent App. 18/452,561 · 2024
Research & prototyping
NIURA · in-ear EEG · —
Co-inventor on wireless earbud EEG patent family (see Scholar). Add titles, dates, and impact metrics here.
The Bronx High School of Science
Per Google Scholar affiliation
Columbia University
Neuroscience Dept (affiliation on Scholar)
// fill in — edit src/data/mk-page.ts
Nerd sheet
The stuff I'd put in a README about myself if READMEs were allowed to be weird.
~/nerd_sheet.json
Operate
In med-tech, a wrong abstraction costs more than a delayed launch. I optimize for correctness first, then velocity.
Code is an instrument for testing hypotheses. I ship prototypes to understand problems, not to perform building.
Every tool, doc, and system should reduce friction for whoever comes after — including future me.
Spec
Block diagram — the nerdy footer for this page.
status = "online"
mode = "luxe"
cursor_tracking = "enabled"
scroll_chapters = "6"
last_build = "local"