Two things that don't usually go together

I grew up in a sport where the difference between winning and losing is usually information. Two players with similar technique meet, and the one who reads the match better wins it. That framing has followed me into everything I have built since.

Squash first

I grew up in Egypt's squash system and competed as a junior at the top of the international game: three-time Egyptian junior national champion, British Junior Open U13 champion, and eventually top 9 in the world junior rankings. I represented Egypt internationally, including at the World Junior Team Championships, where the Egyptian team finished first in the world.

I later moved to the United States and played collegiate squash at Trinity College — CSA All-American, First Team All-NESCAC, and winner of the Molloy Division at the CSA Individual Championships — and went on to compete professionally.

What that decade actually taught me had less to do with squash than it appears. Elite sport is an unusually honest feedback system. You form a hypothesis about an opponent, you test it in a rally, and the result arrives immediately and without flattery. You learn to hold ideas loosely, to notice patterns before you can articulate them, and to care about the small margins that compound across a match.

It also taught me how elite players actually analyse performance — positioning, patterns, shot selection, movement, pressure, tactical decisions, and the details that decide matches long before the score reflects them.

Then engineering

I studied Computer Science at Trinity College alongside the squash, and my work moved steadily toward software engineering, machine learning and applied AI. I later pursued graduate study at Boston University, earning a master's degree, and conducted research at MIT — the point at which experimentation stopped being intuition and became method: define the question, build the measurement, believe the result only if it survives it.

Most of my work since has been about the gap between an AI system that demonstrates well and one that can be relied on. Those are different engineering problems. The first needs a good idea. The second needs retrieval you can trace, evaluation that runs continuously, infrastructure that holds under load, and a clear-eyed view of how the system fails.

Where that leaves me now

I'm the Founding AI Engineer at InpharmD, a Y Combinator-backed healthcare technology company, where I build production AI systems for healthcare and pharmacy intelligence. The domain is unforgiving in a useful way: clinical information is dense, contested and consequential, so the systems have to be built for correctness rather than for a demo.

I'm also Co-Founder & CEO of Core Sports AI, an AI performance intelligence platform for squash. I lead technology and product end-to-end.

Core is where the two halves of my background finally met. The questions I used to answer by watching tape — where does this player recover to, what happens to their shot selection under pressure, which patterns keep producing errors — turn out to be tracking, temporal modelling and sequence problems. I spent years asking them as a player. I now spend my time building systems that can ask them at a scale no one can watch by hand.

What I care about in the work

• Systems that are measured, not asserted. If I can't evaluate it, I don't trust it.
• Domains where being wrong matters — healthcare information, and the preparation an athlete stakes a season on.
• Taking things all the way to production. Architecture and experimentation are the interesting half; deployment is the half that decides whether any of it counts.
• Marginal gains. A career in sport makes you comfortable with improvements that look too small to matter until they accumulate.

More detail: work, engineering, research & education, squash.