How this was built

Rejeesh Menon is an academic internal medicine physician and clinical assistant professor, not a trained software engineer. This site, and the clinical software described on it, were built solo with Claude Code CLI and other AI coding agents, no other engineers involved. The AI writes code, from prompts he writes himself. The clinical logic, the architecture decisions, the safety boundaries, and the compliance calls are his, and he can defend every one of them under questioning.

Back to the CV · This site's source on GitHub

Decisions I'd defend

Three real calls, in the format a technical evaluator would actually want: the decision, the alternative considered, and the consequence.

Deploy on Cloudflare Workers, not Cloudflare Pages

Context. The original build brief specified Cloudflare Pages. Partway through the build, the current major version of the Astro Cloudflare adapter turned out to have dropped Pages support entirely, targeting Workers with static assets instead.

Alternative considered. Pin to an older adapter version to match the original brief exactly, or upgrade the plan to the adapter's current target.

Decision and why. Moved to Workers. Pinning an old major version of a dependency to satisfy a spec written before that dependency changed is exactly the kind of technical debt a careful engineer avoids creating on day one. The cost was small (different CLI commands, same free tier, same custom-domain flow) and is documented in the design spec committed alongside the code, not silently absorbed.

SuperHuman's autonomy boundary

Context. A clinical-intelligence tool that consolidates labs, wearable data and prescription history has to decide what it can act on and what it can only suggest.

Decision. Author of the clinical logic and the autonomy boundary, meaning what the tool decides on its own and what requires physician sign-off.

Consequence. Compliance decisions: BAA-covered data boundary, synthetic-data development, and a decision-support design built to meet the FDA's non-device clinical decision support criteria, not an autonomous diagnostic device.

Priya's escalation rules

Context. An automated WhatsApp/Instagram responder handling real patient messages across seven clinics needs a hard boundary on what it will and won't say on its own.

Decision. Designed the automated responder "Priya", including forbidden clinical topics and red-flag escalation rules, with live log review each release.

A real bug, from building this site

The multi-agent design review that shaped this page's own layout (see the site's repository for the full review) recommended a focus trap and an Escape handler for the floating chat panel, since neither existed before. Adding them introduced a real regression.

The panel's close button removed the visible chat element from the page, but left an empty wrapper element behind. The code that decides whether to open a new panel or reuse an existing one checks for that wrapper first, found it still there, and silently did nothing on every attempt to reopen the chat after the first close. No error, no console warning; the button just stopped working.

Found it by writing an actual open-close-reopen test against a running local build, not by inspection. Fixed by removing the whole wrapper on close, not just the visible content inside it. It shipped in the same commit as the fix that caused it, verified against the real bug before being called done, not assumed correct because the code looked right.

How I actually work with the tool

Each system was specified, built and shipped solo, with AI-assisted development (Claude Code CLI and agentic tooling) and no other engineers. Rejeesh writes the prompts and owns the clinical logic, the autonomy boundaries and the compliance decisions.

Query this CV the way I query systems

Reading this page is one way to get these facts. Here is another: this site runs a real, spec-current (2026-07-28, stateless Streamable HTTP) Model Context Protocol server, so an MCP client you already use can query it directly, the same way it would query any other tool.

Every tool here is a direct read of the same source file that generates this page, cv.yaml — nothing is a second copy that could drift out of sync. The one tool that generates text, why_fit_for_role, reuses the exact grounding prompt the on-page chat uses, so the two surfaces can never answer the same question differently.

Add it with Claude Code

claude mcp add --transport http menon-md https://menon.md/api/mcp

Or add it to Claude Desktop's config

{
  "mcpServers": {
    "menon-md": {
      "url": "https://menon.md/api/mcp"
    }
  }
}

Tools available

get_profile — identity, current title, employer, target roles
search_experience(query) — full-text search across clinical, entrepreneurship, research and teaching
get_projects() / get_project(id) — the four software projects, including the safety-claims disclosure
get_publications() — publications with DOI/PMID and citation metrics
get_verifiable_credentials() — board certification, licenses, education, honors
why_fit_for_role(role_description) — the one generative tool, grounded only on the CV

Public, read-only, no authentication, rate-limited. Built to demonstrate real fluency with the protocol this audience ships for a living, not to perform novelty for its own sake.

Last updated 2026-09-21.