About

Mohamed Khaled portrait

Product engineer shipping AI 0→1

Ten years building production software, now taking AI products from zero to one — owning the whole arc from “is this worth building?” to a system the business can actually depend on.


Current work

Taking AI products 0→1. The product calls and the engineering calls, same person.

I work across the whole zero-to-one arc: deciding what is worth building and for whom, then making it real — retrieval architecture, evaluation discipline, latency budgets, regulatory fit. Most AI features die in the gap between a demo that impresses in a meeting and a product someone will pay for and rely on. That gap is half product judgment and half engineering, and I treat it as one job rather than two handoffs.


Background

Ten years of software, two-and-counting of AI.

I spent most of the last decade building web and content platforms — work that teaches you why production systems fail in ways no design document predicts, and why the hardest calls are usually about what to build, not how. When GPT-4 landed in 2023, it was obvious LLMs were going to be load-bearing for the next decade of software, so I reorganised my practice around them: reading papers, shipping demos, killing the ones that did not earn their keep. What surprised me was how much of “production AI” is unchanged engineering (observability, evaluation, deployment discipline), how much is product judgment under uncertainty, and how little of the rest you can get from a tutorial.


How I think about AI

A few positions, repeated until people stop arguing.

  • Ship the smallest thing that proves value. The first version exists to answer one question — does anyone actually want this? Everything you build before you have that answer is a bet against yourself. Zero to one is about reaching that answer cheaply, not building the cathedral.
  • The model is not the product. The product is the system around the model: retrieval, evaluation, prompt construction, citation, monitoring — and the user problem it is pointed at. Pick the wrong system, or the wrong problem, and the best model in the world gives the wrong answer.
  • Architects exist because measurement exists. You cannot tune what you cannot evaluate, and you cannot prioritise what you cannot measure. Most AI systems in companies today have neither an eval set nor a usage metric; that is the first thing that needs fixing, not the model choice.
  • Regulation is a forcing function, not a brake. The EU AI Act is real, dated, and enforceable, and equivalents across the US, UK, and APAC are landing on similar timelines. The companies that treat compliance as a parallel workstream lose months. The ones that fold it into product and architecture from day one ship faster.

Writing

Lessons for the engineering. Insights for everything else.

This site is where I work in public. The lessons are the engineering made tangible: each one an interactive, runnable artifact rather than a static article — a tokenizer you can paste into, a chunker you can switch strategies on, a reranker you can run and feel the latency of. The insights are the product side — the 0→1 calls, the cheap experiments, and what shipping actually teaches you that no roadmap predicts. The goal of both is the same: a felt understanding of one real decision, not a vocabulary lesson.


Get in touch

For collaboration, advisory, or 0→1 product conversations: mokhaleddev@gmail.com. LinkedIn for shorter notes, GitHub for anything code-shaped.